Rich Comparisons Gotcha

Steven D'Aprano steven at REMOVE.THIS.cybersource.com.au
Tue Dec 9 03:44:43 CET 2008


On Mon, 08 Dec 2008 10:20:56 -0800, Rhamphoryncus wrote:

> On Dec 7, 4:20 pm, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote:
>> > Rasmus Fogh wrote:
>>
>> >> Current behaviour is both inconsistent and counterintuitive, as
>> >> these examples show.
>>
>> >>>>> x = float('NaN')
>> >>>>> x == x
>> >> False
>>
>> > Blame IEEE for that one. Rich comparisons have nothing to do with
>> > that one.
>>
>> There is nothing to blame them for. This is the correct behaviour. NaNs
>> should *not* compare equal to themselves, that's mathematically
>> incoherent.
> 
> Mathematically, NaNs shouldn't be comparable at all.  They should raise
> an exception when compared.  In fact, they should raise an exception
> when *created*.  But that's not what we want.  What we want is a dummy
> value that silently plods through our calculations.  For a dummy value
> it seems a lot more sense to pick an arbitrary yet consistent sort order
> (I suggest just above -Inf), rather than quietly screwing up the sort.
> 
> Regarding the mythical IEEE 754, 

It's hardly mythical.

http://ieeexplore.ieee.org/ISOL/standardstoc.jsp?punumber=4610933


> although it's extremely rare to find
> quotations, I have one on just this subject.  And it does NOT say "x ==
> NaN gives false".  It says it gives *unordered*.


Unordered means that none of the following is true:

x > NaN
x < NaN
x == NaN


It doesn't mean that comparing a NaN with something else is an error.


-- 
Steven



More information about the Python-list mailing list