Home Original page

Rich Comparisons Gotcha

Rhamphoryncus rhamph at gmail.com
Mon Dec 8 18:30:22 EST 2008 
On Dec 8, 2:51 pm, Robert Kern <robert.k... at gmail.com> wrote:
> Rhamphoryncus wrote:
> > "We've always done it that way" is NOT a use case!  Certainly, it's a
> > factor, but it seems quite weak compared to the sort use case.
>
> I didn't say it was. I was explaining that sorting was probably *not* a use case
> for the boolean predicates at the time of writing of the standard. In fact, it
> suggests implementing a Compare() function that returns "greater than", "less
> than", "equal" or "unordered" in addition to the boolean predicates. That Python
> eventually chose to use a generic boolean predicate as the basis of its sorting
> routine many years after the IEEE-754 standard is another matter entirely.

I interpret that to mean IEEE 754's semantics are for different
circumstances and are inapplicable to Python.


> In any case, the standard itself is quite short, and does not spend much time
> justifying itself in any detail.

A pity, as it is often invoked to explain language design.


> > I suppose what I'm hoping for is an small example program (one or a
> > few functions) that needs the "always false" behaviour of NaN.
>
> Steven D'Aprano gave one earlier in the thread.

I see examples of behaviour, but no use cases.


> Additionally, (x!=x) is a simple
> test for NaNs if an IsNaN(x) function is not available.

That's a trick to work around the lack of IsNaN(x).  Again, not a use
case.


> Really, though, the
> result falls out from the way that IEEE-754 constructed the logic of the
> system. It is not defined that (NaN==NaN) should return False, per se. Rather,
> all of the boolean predicates are defined in terms of that Compare(x,y)
> function. If that function returns "unordered", then (x==y) is False. It doesn't
> matter if one or both are NaNs; in either case, the result is "unordered".

And if I arbitrarily dictate that NaN is a single value which is
orderable, sorting just above -Infinity, then all the behaviour makes
a lot more sense AND I fix sort.

So you see the predicament I'm in.  On the one hand we have a problem
and an obvious solution.  On the other hand we've got historical
behaviour which everybody insists *must* remain, reasons unknown.  It
reeks of the Parable of the Monkeys.

I think I should head over to one of the math groups and see if they
can find a reason for it.
More information about the Python-list mailing list