homepage

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 loewis, mark.dickinson, mattip
Date 2012年04月08日.16:30:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333902659.64.0.93638779542.issue14521@psf.upfronthosting.co.za>
In-reply-to
Content
Hmm. I don't see this as a bug: the sign of a nan isn't really all that meaningful anyway, and this doesn't (AFAIK) contradict any documentation.
On the other hand, given that most other aspects of floating-point are now reasonably portable across platforms (or at least those platforms that support IEEE 754), it may make sense to standardise this too, as a minor improvement for Python 3.3.
The patch does not look correct to me: did you mean 'fabs' rather than 'abs'? Even then, the C standard says nothing (not even in annex F) about how fabs should behave when applied to a NaN.
Instead, if the platform supports IEEE 754 (e.g., if the short float repr code is in use), we could hard-code a NaN bit representation. (Even though there are 2**53-2 distinct bit patterns representing NaNs, there are nevertheless a couple of obvious ones to choose: there are exactly two quiet NaNs that don't arise by silencing a signaling NaN. The one with the sign bit cleared would be an obvious choice; I think it's the negation of the one that Intel uses by default, which does indeed have its sign bit set.)
History
Date User Action Args
2012年04月08日 16:30:59mark.dickinsonsetrecipients: + mark.dickinson, loewis, mattip
2012年04月08日 16:30:59mark.dickinsonsetmessageid: <1333902659.64.0.93638779542.issue14521@psf.upfronthosting.co.za>
2012年04月08日 16:30:58mark.dickinsonlinkissue14521 messages
2012年04月08日 16:30:58mark.dickinsoncreate

AltStyle によって変換されたページ (->オリジナル) /