On 4/28/11 10:02 AM, Alexander Belopolsky wrote:
On Thu, Apr 28, 2011 at 10:22 AM, Mike Graham<mikegraham@gmail.com> wrote:
On Thu, Apr 28, 2011 at 4:52 AM, Alexander Belopolsky <alexander.belopolsky@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