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 mark.dickinson, pitrou, steve.dower, tim.golden, zach.ware
Date 2014-10-09.20:13:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1412885613.4.0.342179063713.issue22590@psf.upfronthosting.co.za>
In-reply-to
Content
> we should perhaps produce the right sign bit for each

Perhaps.  But given that signs of NaNs are pretty much meaningless anyway (the IEEE 754 standard explicitly refuses to attach any meaning to NaN sign bits, and the sign bit of a NaN result is not specified for most operations), and that a change *could* conceivably break existing code, I don't see much of a case for changing the behaviour in 2.7.  I'm not particularly *opposed* to such a change; I just don't really see the point.

BTW, I'd expect this report to apply to other platforms in addition to Windows; Intel's "default" NaN has its sign bit set, so a platform that just does the lazy thing and lets the FPU NaN propagate will tend to see an inverted sign bit here.

It's only the 2.7 behaviour you're complaining about, right?  Are things working as expected on 3.4 and Windows?
History
Date User Action Args
2014-10-09 20:13:33mark.dickinsonsetrecipients: + mark.dickinson, pitrou, tim.golden, zach.ware, steve.dower
2014-10-09 20:13:33mark.dickinsonsetmessageid: <1412885613.4.0.342179063713.issue22590@psf.upfronthosting.co.za>
2014-10-09 20:13:33mark.dickinsonlinkissue22590 messages
2014-10-09 20:13:33mark.dickinsoncreate