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 <rep...@bugs.python.org>
<http://bugs.python.org/issue11734>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to