Mark Dickinson added the comment:
There's some NaN behaviour that needs fixing in the packing code: packing a NaN
currently creates a signalling NaN rather than a quiet NaN, and the sign of a
NaN isn't respected. (One can make a strong argument that the sign of the NaN
doesn't matter, but we're respecting the sign for '<d' and '<f' formats, so I
think we should do the same for '<e'.)
I'm working on an updated patch, taking into account the above and Antoine and
Raymond's comments.
This is the behaviour with the current patch, on OS X 10.10.5.
>>> '{:064b}'.format(struct.unpack('<Q', struct.pack('<d', math.nan))[0])
'0111111111111000000000000000000000000000000000000000000000000000'
>>> '{:032b}'.format(struct.unpack('<I', struct.pack('<f', math.nan))[0])
'01111111110000000000000000000000'
>>> '{:016b}'.format(struct.unpack('<H', struct.pack('<e', math.nan))[0])
'0111110000000001'
>>> '{:064b}'.format(struct.unpack('<Q', struct.pack('<d', -math.nan))[0])
'1111111111111000000000000000000000000000000000000000000000000000'
>>> '{:032b}'.format(struct.unpack('<I', struct.pack('<f', -math.nan))[0])
'11111111110000000000000000000000'
>>> '{:016b}'.format(struct.unpack('<H', struct.pack('<e', -math.nan))[0])
'0111110000000001'
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue11734>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
