Author mark.dickinson
Recipients Eli.Stevens, asvetlov, belopolsky, mark.dickinson, mark.wiebe, paulehoffman, pitrou, rhettinger
Date 2016-08-30.16:36:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1472575015.63.0.819506434731.issue11734@psf.upfronthosting.co.za>
In-reply-to
Content
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'
History
Date User Action Args
2016-08-30 16:36:55mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, belopolsky, pitrou, asvetlov, Eli.Stevens, mark.wiebe, paulehoffman
2016-08-30 16:36:55mark.dickinsonsetmessageid: <1472575015.63.0.819506434731.issue11734@psf.upfronthosting.co.za>
2016-08-30 16:36:55mark.dickinsonlinkissue11734 messages
2016-08-30 16:36:55mark.dickinsoncreate