develooper Front page | perl.perl5.porters | Postings from October 2013

Re: [perl #120363] perl-5.18.0 apparently miscalculates the NV 1e-298

Thread Previous | Thread Next
October 25, 2013 12:10
Re: [perl #120363] perl-5.18.0 apparently miscalculates the NV 1e-298
Message ID: wrote:
>Is there a connection ?

They're the same class of problem: libc performs better than Perl at
text->float conversion.

>That looks quite different - I'm not doing any text-float conversion

You gave Perl the text "1e-298" in a context where it was treated as a
floating-point literal, thus calling upon Perl to convert it to a floating
point value, and you looked at the resulting value.  In the same manner,
in [perl #41202] I gave Perl the text "1180591620717411303424.0" as a
floating-point literal.  Same data flow in both cases, and the crucial
operation is a conversion from decimal text to floating point.

>and perl represents the value 2^70 perfectly accurately:

That's the difference between these two tickets.  2**70 can be represented
exactly as an NV, but 10**-298 cannot.  By using an exactly-representable
value, [perl #41202] illustrates that the issue is not merely the
unavoidable rounding that comes from converting a value that can't be
represented exactly.  (The fact that the differences you see with "1e-298"
are of 2 ulp also illustrate that the issue isn't just this rounding.
A single rounding operation being handled differently in different places
could account for 1 ulp.)

Oh, another way to see the "1e-298" difference: compare "1e-298" against
"10**-298".  The latter (computed in Perl) gives me the same result that
you got from the C compiler for "1e-298".  Presumably the floating-point
pow() operation is giving a correctly-rounded result.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About