Front page | perl.perl5.porters |
Postings from July 2010
Ben Morrow wrote:
>But that makes number->string->number round-tripping unreliable,
It already is. Insufficiently many digits are emitted:
$ perl -MData::Float=nextdown -lwe '$x = nextdown(8); printf "%s\n%.50f\n", $x, $x'
8
7.99999999999999911182158029987476766109466552734375
And if you fix that, there's also a bug in string->number conversion
(RT#41202):
$ perl -lwe '$x = 2**70; $y = sprintf("%.f", $x); printf "%.f\n%.f\n", $x, $y'
1180591620717411303424
1180591620717411172352
We also, more intentionally than the above, don't preserve the payload
or sign bit of a NaN. I think the sign bit of a zero falls into much
the same logical category as this.
I used to favour perfecting the string<->float conversions for
round-tripping, but on reflection I've concluded that Perl's special
semantics for numeric zeros need to take precedence. Perfect round-trip
encoding of floats is still possible by other (explicit) means.
Actually, if you want round-tripping at all, you're quite likely to
want *cross-platform* round-tripping, for which decimal representation
is quite poor. Emitting sufficient digits to uniquely identify the
value on one platform doesn't necessarily do so for another platform,
so the only way to do cross-platform round-tripping is to output *all*
the digits required to represent the value exactly. In decimal, that's
quite a lot of digits for fractional values. You're better off using hex.
>Unless I've badly understood something, negative zeros should be rare
>and only produced by people who are expecting them.
Wrong on both counts, I'm afraid. Perl's numeric behaviour is often
surprising.
-zefram
Thread Previous
|
Thread Next