Message97435
>>> float('nan') == float('nan')
False
>>> float('nan') != float('nan')
True
This is deliberate, though perhaps surprising if you haven't seen it before. There's a long history of nan comparisons behaving this way (that is, x == nan always returns False, x != nan always returns True, even if x is a nan); the behaviour comes from the IEEE 754 specification for floating-point arithmetic.
>>> copysign(1, float('nan'))
-1.0
>>> copysign(1, float('-nan'))
-1.0
This is also as expected: the sign bit of a nan result (either as a result of conversion from string, or the result of an arithmetic operation) is probably best regarded as undefined. The new string -> float conversion algorithms that are used in Python 3.1 (and in the upcoming 2.7) make sure that 'nan' and '-nan' are converted to nans with different signs, but again that's an implementation detail that shouldn't be relied upon. |
|
Date |
User |
Action |
Args |
2010-01-08 19:25:28 | mark.dickinson | set | recipients:
+ mark.dickinson, jmfauth |
2010-01-08 19:25:28 | mark.dickinson | set | messageid: <1262978728.03.0.343268610719.issue7660@psf.upfronthosting.co.za> |
2010-01-08 19:25:26 | mark.dickinson | link | issue7660 messages |
2010-01-08 19:25:26 | mark.dickinson | create | |
|