Rich Comparisons Gotcha

[acerimusdux]

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.