This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients ahrvoje, eric.smith, mark.dickinson
Date 2016-04-17.21:03:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1460926984.85.0.289649754973.issue26785@psf.upfronthosting.co.za>
In-reply-to
Content
The current behaviour is deliberate, so any change would be an enhancement rather than a bugfix. I'm modifying the versions accordingly.

Unlike the sign of a zero, the sign of a NaN has no useful meaning: IEEE 754 explicitly says "this standard does not interpret the sign of a NaN". Yes, that sign is copied by copysign, but I don't think that in itself means that the sign should be included in the repr, and I'm not aware of any applications where the sign matters in that context.

A NaN also has 51 payload bits (or 52 if you're not distinguishing between quiet and signalling NaNs), but like the sign, those bits are rarely important in applications.

I'm not really seeing a case for representing either the sign or the payload bits in the repr. Do you know of any applications that make use of the sign of a NaN?
History
Date User Action Args
2016-04-17 21:03:04mark.dickinsonsetrecipients: + mark.dickinson, eric.smith, ahrvoje
2016-04-17 21:03:04mark.dickinsonsetmessageid: <1460926984.85.0.289649754973.issue26785@psf.upfronthosting.co.za>
2016-04-17 21:03:04mark.dickinsonlinkissue26785 messages
2016-04-17 21:03:04mark.dickinsoncreate