[Python-ideas] Disallow orderring comparison to NaN

Robert Kern robert.kern at gmail.com
Thu Apr 28 18:46:10 CEST 2011


On 4/28/11 10:02 AM, Alexander Belopolsky wrote:
> On Thu, Apr 28, 2011 at 10:22 AM, Mike Graham<mikegraham at gmail.com>  wrote:
>> On Thu, Apr 28, 2011 at 4:52 AM, Alexander Belopolsky
>> <alexander.belopolsky at gmail.com>  wrote:
> ..
>>>> Since py3k has already made None<  0 an error, it may be reasonable
>>>> for float('nan')<  0 to raise an error as well (probably ValueError
>>>> rather than TypeError).  This will not make lists with nans sortable
>>>> or searchable using binary search, but will make associated bugs
>>>> easier to find.
>>
>> I'm -0 on this -- I really favor having NaNs behave like NaNs.
>
> .. but IEEE 754 specifies that NaNs compare as "unordered".

Not quite, IIRC. I don't have it in front of me, but I do recall that it 
specifies how it behaves in two different situations:

1. Where you have a comparison function that returns the relationship between 
the two operands, IEEE-754 specifies that in addition to GT, LT, and EQ, you 
ought to include "unordered" to use when a NaN is involved.

2. Where you have comparison operators like <, ==, etc. that return bools, NaNs 
will return False for all comparisons.

They may specify whether or not FPE signals should be issued, I don't recall, 
but I suspect that if they are quiet NaNs, they won't issue a SIGFPE. 
Higher-level exceptions were not contemplated by IEEE-754, IIRC.

Python uses the < operator for sorting, not a comparison function, so it's 
current behavior is perfectly in line with the IEEE-754 spec.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco




More information about the Python-ideas mailing list