Front page | perl.perl5.porters |
Postings from October 2013
sisyphus1@optusnet.com.au wrote:
>But on the perl built with nvtype eq 'long double', things are worse
>with 10 ** -298:
Ooh, interesting. OK, I get the same values as you. In summary (via
Data::Float::float_hex()):
+0x1.0be08d0527e1d69cp-990 C source (gcc) 1e-298L, C strtold "1e-298",
C powl(10.0L, -298.0L),
actual closest representable to 10**-298
+0x1.0be08d0527e1d6a0p-990 Perl (source or runtime string coercion) 1e-298
+0x1.0be08d0527e1d786p-990 Perl 10**-298
I'm mystified as to how Perl 10**-298 gets a different result from C
powl(), because pp_pow() clearly uses powl() underneath. Even if it
were using the lower precision pow(), that would lead to the low-order
bits being zero, not the inaccurate bits that we see. Anyway, I reckon
pp_pow giving the wrong answer is a separate bug from the text->float
conversion errors that this ticket started with.
-zefram
Thread Previous
|
Thread Next