Mark Dickinson <dicki...@gmail.com> added the comment: 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.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14521> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
