Mark Dickinson <dicki...@gmail.com> added the comment:
>>> 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.
----------
nosy: +mark.dickinson
resolution: -> invalid
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7660>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
