mismatch between Perl 5.6 and Perl 5.8 in printing high precision values.
in [Perl]
|
Prev: FAQ 8.25 How can I capture STDERR from an external command?
Next: mismatch between Perl 5.6 and Perl 5.8 in printing high precision values.
From: sisyphus on 2 Apr 2008 09:46 On Apr 2, 9:21 pm, vivekanand.n...(a)gmail.com wrote: > printf("%.32g\n",0.99999999976716936); > > Perl 5.6.1 output: > 0.99999999976716936 --> GOOD > > Perl 5.8.6 output: > 0.99999999976716925 --> ERROR > > Any reason for such mismatch ? I believe it's a bug in perl 5.8 (which has been carried through to perl 5.10): C:\_32\pscrpt>perl -e "printf(\"%.32g\n\",0.99999999976716936);" 0.99999999976716925 C:\_32\pscrpt>perl -e "printf(\"%.32g\n\",9.9999999976716936e-1);" 0.99999999976716936 Since 0.99999999976716936 == 9.9999999976716936e-1, I can think of no good reason that that those 2 one-liners should produce different output - and I believe the first one liner produces an incorrect result. I'll submit a bug report about this - unless someone can convince me that it's *not* a bug (or unless someone else wants to submit the report). Cheers, Rob
From: szr on 2 Apr 2008 12:02 sisyphus wrote: > On Apr 2, 9:21 pm, vivekanand.n...(a)gmail.com wrote: >> printf("%.32g\n",0.99999999976716936); >> >> Perl 5.6.1 output: >> 0.99999999976716936 --> GOOD >> >> Perl 5.8.6 output: >> 0.99999999976716925 --> ERROR >> >> Any reason for such mismatch ? > > I believe it's a bug in perl 5.8 (which has been carried through to > perl 5.10): > > C:\_32\pscrpt>perl -e "printf(\"%.32g\n\",0.99999999976716936);" > 0.99999999976716925 > > C:\_32\pscrpt>perl -e "printf(\"%.32g\n\",9.9999999976716936e-1);" > 0.99999999976716936 > > Since 0.99999999976716936 == 9.9999999976716936e-1, I can think of no > good reason that that those 2 one-liners should produce different > output - and I believe the first one liner produces an incorrect > result. > > I'll submit a bug report about this - unless someone can convince me > that it's *not* a bug (or unless someone else wants to submit the > report). > > Cheers, > Rob Interesting, I get these values: $ perlall -e 'printf("%.32g\n",99999999976716936e-1);' <perl5.10.0> 9999999997671693.599609375 <perl5.8.8 > 9999999997671693.599609375 <perl5.8.2 > 9999999997671692 <perl5.8.0 > 9999999997671692 <perl5.6.1 > 9999999997671694 -- szr
From: szr on 2 Apr 2008 12:05 sisyphus wrote: > On Apr 2, 9:21 pm, vivekanand.n...(a)gmail.com wrote: >> printf("%.32g\n",0.99999999976716936); >> >> Perl 5.6.1 output: >> 0.99999999976716936 --> GOOD >> >> Perl 5.8.6 output: >> 0.99999999976716925 --> ERROR >> >> Any reason for such mismatch ? > > I believe it's a bug in perl 5.8 (which has been carried through to > perl 5.10): > > C:\_32\pscrpt>perl -e "printf(\"%.32g\n\",0.99999999976716936);" > 0.99999999976716925 > > C:\_32\pscrpt>perl -e "printf(\"%.32g\n\",9.9999999976716936e-1);" > 0.99999999976716936 > > Since 0.99999999976716936 == 9.9999999976716936e-1, I can think of no > good reason that that those 2 one-liners should produce different > output - and I believe the first one liner produces an incorrect > result. > > I'll submit a bug report about this - unless someone can convince me > that it's *not* a bug (or unless someone else wants to submit the > report). > > Cheers, > Rob Please disregard my previous reply, I made a dump typo. This is what I get: $ perlall -e 'printf("%.32g\n",9.9999999976716936e-1);' <perl5.10.0> 0.99999999976716935997820764892019 <perl5.8.8 > 0.99999999976716935997820764892019 <perl5.8.2 > 0.99999999976716935634613037109375 <perl5.8.0 > 0.99999999976716935634613037109375 <perl5.6.1 > 0.99999999976716935634613037109375 -- szr
From: Ilya Zakharevich on 2 Apr 2008 15:58 [A complimentary Cc of this posting was sent to sisyphus <sisyphus359(a)gmail.com>], who wrote in article <28eff3d6-c1b4-4679-9838-38c295b4da66(a)i7g2000prf.googlegroups.com>: > Since 0.99999999976716936 =3D=3D 9.9999999976716936e-1 Why this would be so? At best, one is 0.99999999976716936, another is 9.9999999976716936/10. I know no axiom of FP arithmetic which would make them equal... (In principle, one could impose a condition on atof() that all strings are first normalized IN DECIMAL to the e00 exponent, THEN translated to binary. But given that, AFAIK, atof() is not documented to satisfy ANY requirement, however reasonable, this is a pipe dream.) [I have, on a backburner, some plans to make Perl use "the best" string-to-FP-to-string conversions (so that a lot of verbiage can be removed from perlnumber.pod). But my improve-perl plans do not get a lot of timeslices recently.] Yours, Ilya
From: sisyphus on 2 Apr 2008 19:41
On Apr 3, 6:58 am, Ilya Zakharevich <nospam-ab...(a)ilyaz.org> wrote: > [A complimentary Cc of this posting was sent to > sisyphus > <sisyphus...(a)gmail.com>], who wrote in article <28eff3d6-c1b4-4679-9838-38c295b4d...(a)i7g2000prf.googlegroups.com>: > > > Since 0.99999999976716936 =3D=3D 9.9999999976716936e-1 > > Why this would be so? At best, one is 0.99999999976716936, another is > 9.9999999976716936/10. I know no axiom of FP arithmetic which would > make them equal... Oh! ... ok. (I was thinking that perl should see the same mantissa in both instances, and therefore store the same value.) The other thing I note is that (with 52 bits of precision, plus the implicit leading "1.") 0.99999999976716936 is represented in base 2 as: 1.1111111111111111111111111111111000000000000000000000e-1 And that converts back to 0.99999999976716936 (in base 10). OTOH, 0.99999999976716925 is represented as: 1.1111111111111111111111111111110111111111111111111111e-1 And that converts back to 0.99999999976716925 (in base 10). For my conversions, I'm using "round to nearest" mode - and I'm using the mpfr C library (version 2.3.1) - which, according to its homepage at http://www.mpfr.org/ provides "correct rounding" and "copies the good ideas from the ANSI/IEEE-754 standard for double-precision floating-point arithmetic (53-bit mantissa)". I've not yet had any cause to take issue with those claims. For me, (the recent versions of)perl are at odds with everything else on my box in (apparently) insisting that 0.99999999976716936 has the internal base 2 representation of: 1.1111111111111111111111111111110111111111111111111111e-1 Everything else uses an internal representation of 1.1111111111111111111111111111111000000000000000000000e-1. Is that still not a perl bug ? (This FP stuff is just so damned tricky, I never know what to think for sure :-) Cheers, Rob |