[issue14521] math.copysign(1., float('nan')) returns -1.

[Mark Dickinson]

Mark Dickinson <dickinsm at 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 <report at bugs.python.org>
<http://bugs.python.org/issue14521>
_______________________________________