[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-porters
Subject:    Re: [perl #76756] PATCH: srand returns the seed
From:       Zefram <zefram () fysh ! org>
Date:       2010-07-30 10:14:57
Message-ID: 20100730101457.GG21668 () lake ! fysh ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]