Rich Comparisons Gotcha
rhamph at gmail.com
Tue Dec 9 05:44:09 CET 2008
On Dec 8, 7:44 pm, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> 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.
I consider it to be mythical because most knowledge of it is
indirect. Few who use floating point have the documents available to
them. Requiring purchase/membership is the cause of this.
> > 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.
Robert Kern already clarified that. My confusion was due to relying
on second-hand knowledge.
More information about the Python-list