Message157796
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.) |
|
Date |
User |
Action |
Args |
2012-04-08 16:30:59 | mark.dickinson | set | recipients:
+ mark.dickinson, loewis, mattip |
2012-04-08 16:30:59 | mark.dickinson | set | messageid: <1333902659.64.0.93638779542.issue14521@psf.upfronthosting.co.za> |
2012-04-08 16:30:58 | mark.dickinson | link | issue14521 messages |
2012-04-08 16:30:58 | mark.dickinson | create | |
|