Mark Dickinson <[email protected]> added the comment:
> The pickle output has the sign-bit set. Ignoring the sign-bit, it is
> unpickled correctly.
Okay, thanks for the clarification. I just wanted to be clear whether there's
a real problem with pickle that should be fixed in 2.7 or not.
Again, I don't see this as a bug: pickle is transferring the sign bit
correctly, so the only issue again is that float('nan') happens to produce a
nan whose sign bit is set (depending on platform, compiler options, etc.). I
don't see it as a problem that one can end up with some 'positive' nans and
some 'negative' nans on a single system. As far as I know, none of this
violates any documentation or standards (IEEE 754 explicitly places no
interpretation on the sign bit of a nan, and makes no guarantees or
recommendations about the sign bit of the result of converting the string
'nan'). So at worst, this is a minor violation of user expectations. Though I
do agree that having float('-nan') having its sign bit unset is especially
surprising.
So while I don't see this as a bug that should be fixed for 2.7, I'm happy to
'fix' this for Python 3.3, partly for the portability improvement, and partly
to avoid having the string-to-float conversions do INF*0 calculations at run
time; that bit's always made me feel uncomfortable.
Thanks for the updated patch; I'll take a look shortly.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue14521>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
