[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