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:40
Re: [perl #120363] perl-5.18.0 apparently miscalculates the NV 1e-298
Message ID:

-----Original Message----- 
From: Zefram via RT
Sent: Friday, October 25, 2013 11:10 PM
Subject: Re: [perl #120363] perl-5.18.0 apparently miscalculates the NV 
1e-298 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.

Ok ... and this has been known about for quite some time ... which leads to 
me ponder that it might be a while before it gets fixed ?


>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.

Yes, on the perl-5.18.0 built with nvtype eq 'double', 10 ** -298 produces 
the C compiler value for me, too.
But on the perl built with nvtype eq 'long double', things are worse with 10 
** -298:

$ perl -le 'print scalar reverse unpack "b64", pack "D", 10 ** -298;'

That differs from the C value for 1e-298 beginning at the 57th bit.


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