James Stroud wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">Rasmus
Fogh wrote:
Current behaviour is both inconsistent and counterintuitive, as these
examples show.
x = float('NaN')
x == x
False
Perhaps this should raise an exception? I think the problem is not
with comparisons in general but with the fact that nan is type float:
py> type(float('NaN'))
<type 'float'>
No float can be equal to nan, but nan is a float. How can something be
not a number and a float at the same time? The illogicality of nan's
type creates the possibility for the illogical results of comparisons
to nan including comparing nan to itself.
I initially thought that looked like a bug to me. But, this is
apparently standard behavior required for "NaN". I'm only using
Wikipedia as a reference here, but about 80% of the way down, under
"standard operations":
http://en.wikipedia.org/wiki/IEEE_754-1985
"Comparison operations. NaN is treated specially in that NaN=NaN always
returns false."
Presumably since floating point calculations return "NaN" for some
operations, and one "Nan" is usually not equal to another, this is the
required behavior. So not a Python issue (though understandably a bit
confusing).
The array issue seems to be with one 3rd party library, and one can
choose to use or not use their library, to ask them to change it, or
even to decide to override their == operator, if one doesn't like the
way it is designed.
--
http://mail.python.org/mailman/listinfo/python-list
