Re^3: Math::BigFloat to native double?

Replies are listed 'Best First'.
Re^4: Math::BigFloat to native double? by BrowserUk (Patriarch) on Jul 13, 2015 at 04:22 UTC
Also, you've stretched the requested precision to 17 decimal digits, which might be a contributing factor After anonymonks post above about printf inventing stuff, I explored the possibility, and from what I can tell, if you ask printf for more precision than is available, it just pads with trailing zeros: `printf "dp:%u : %35.f\n", $_, $_, 3.1415926535897932384626433832795 f +or 14 .. 20;; dp:14 : 3.14159265358979 dp:15 : 3.141592653589793 dp:16 : 3.1415926535897931 dp:17 : 3.14159265358979310 dp:18 : 3.141592653589793100 dp:19 : 3.1415926535897931000 dp:20 : 3.14159265358979310000` [download] And: [0] Perl> printf "dp:%u : %.f\n", $_, $_, 123e-308 for 300 .. 320;; dp:300 : 0.000 {300 zeros ellided} 000000000000 dp:301 : 0.000 {300 zeros ellided} 0000000000000 dp:302 : 0.000 {300 zeros ellided} 00000000000000 dp:303 : 0.000 {300 zeros ellided} 000000000000000 dp:304 : 0.000 {300 zeros ellided} 0000000000000000 dp:305 : 0.000 {300 zeros ellided} 00000000000000000 dp:306 : 0.000 {300 zeros ellided} 000000000000000001 dp:307 : 0.000 {300 zeros ellided} 0000000000000000012 dp:308 : 0.000 {300 zeros ellided} 00000000000000000123 dp:309 : 0.000 {300 zeros ellided} 000000000000000001230 dp:310 : 0.000 {300 zeros ellided} 0000000000000000012300 dp:311 : 0.000 {300 zeros ellided} 00000000000000000123000 dp:312 : 0.000 {300 zeros ellided} 000000000000000001230000 dp:313 : 0.000 {300 zeros ellided} 0000000000000000012300000 dp:314 : 0.000 {300 zeros ellided} 00000000000000000123000000 dp:315 : 0.000 {300 zeros ellided} 000000000000000001230000000 dp:316 : 0.000 {300 zeros ellided} 0000000000000000012300000000 dp:317 : 0.000 {300 zeros ellided} 00000000000000000123000000000 dp:318 : 0.000 {300 zeros ellided} 000000000000000001230000000000 dp:319 : 0.000 {300 zeros ellided} 0000000000000000012300000000000 dp:320 : 0.000 {300 zeros ellided} 00000000000000000123000000000000 [download] If you want reliable rounding and accuracy with floating point values, use Math::MPFR. I was actually hoping for simple truncation. I'm only using Math::BigFloat in an attempt to verify my double-double implementation. And what I've realised/discovered is that the mistake is when M::BF translates the double value when performing the subtraction above. If I do the translation myself, I get sensible numbers: `use Math::BigFloat;; $n = Math::BigFloat->new( '3.1415926535897932384626433832795' );; $d = 0 + $n->bstr;; printf "%.17f\n", $d;; 3.14159265358979310 $bfd = Math::BigFloat->new( sprintf "%.17f", $d );; print $bfd;; 3.1415926535897931 $n -= $bfd;; print $n;; 0.0000000000000001384626433832795` [download] Which gives me: `3.14159265358979310 + 0.0000000000000001384626433832795 = 3.1415926535897932384626433832795 == 3.141592653589793238462643383 +2795 (the input)` [download] And that's all I was after. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply] [d/l] [select]
Re^5: Math::BigFloat to native double? by syphilis (Archbishop) on Jul 13, 2015 at 06:47 UTC
And that's all I was after If it matters to you (and it may conceivably not), that seems not quite the same as the split that the hardware double-double implementations produce. On my double-double (PowerPC) box, for your given 32-digit value of 3.1415926535897932384626433832795 the 2 doubles would there round out as 3.14159265358979e+000 and 1.22464679914735e-016 with actual hex representations of 0x1.921fb54442d18p+1 and 0x1.1a62633145c07p-53. Those 2 hex values concatenate to the correct 107-bit representation of the original value: `0.11001001000011111101101010100010001000010110100011000010001101001100 +010011000110011000101000101110000000111E2` [download] Cheers, Rob	[reply] [d/l]
Re^6: Math::BigFloat to native double? by BrowserUk (Patriarch) on Jul 13, 2015 at 07:32 UTC
the 2 doubles would there round out as 3.14159265358979e+000 and 1.22464679914735e-016 But? `3.14159265358979e+000 0.000000000000000122464679914735 3.141592653589790122464679914735` [download] Something is not right. Update: for example: `0.1 1001 0010 0001 1111 1011 0101 0100 0100 0100 0010 1101 0001 1000 + 0 1 0001 1010 0110 0010 0110 0011 0011 0001 0100 0101 1100 0000 0111 + E2 1 9 2 1 f b 5 4 4 4 2 d 1 8 + ? 1 1 a 6 2 6 3 3 1 4 5 c 0 7` [download] With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply] [d/l] [select]
Re^7: Math::BigFloat to native double? by syphilis (Archbishop) on Jul 13, 2015 at 08:12 UTC
Re^8: Math::BigFloat to native double? by syphilis (Archbishop) on Jul 13, 2015 at 10:07 UTC
Some notes below your chosen depth have not been shown here
Re^8: Math::BigFloat to native double? by BrowserUk (Patriarch) on Jul 13, 2015 at 09:19 UTC
Some notes below your chosen depth have not been shown here