Front page | perl.perl5.porters |
Postings from October 2013
sisyphus1@optusnet.com.au 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. -zeframThread Previous | Thread Next