When is min(a, b) != min(b, a)?

[Antoon Pardon]

On 2008-01-24, Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> wrote:
> On Thu, 24 Jan 2008 13:34:56 +0000, Antoon Pardon wrote:
>
>> On 2008-01-21, Steven D'Aprano <steven at REMOVE.THIS.cybersource.com.au>
>> wrote:
>>> On Sun, 20 Jan 2008 21:15:02 -0600, Albert Hopkins wrote:
>>>
>>> According to the IEEE-754 standard the usual trichotomy of "x is less
>>> than y, x is equal to y, or x is greater than y" has to be extended to
>>> include "x and y are unordered". Comparisons with NaNs are unordered,
>>> and so expressions like "x < nan" should signal an exception.
>> 
>> That doesn't follow. The problem is not that x < nan returns False
>> because that is correct since x isn't smaller than nan.
>
> Comparisons between things which are not comparable risk being terribly 
> misleading, and depend very much on how you define "less than" and 
> "greater than". If you insist that everything must have a boolean yes/no 
> answer ("Does the colour red have a better chance of becoming President 
> than a kick to the head?") then False is not an entirely unreasonable 
> result to return.
>
> But if you consider that having "x is not smaller than y" be equivalent 
> to "x is greater than or equal to y" is more important than forcing a 
> boolean answer in the first place, then you need something to signal 
> Undefined, and an exception is the right solution unless you have multi-
> valued logic system (True, False, Maybe, Undefined, ...)

Why should we consider that? The world is full of partial orders. In
python we have sets and a partial order is perfectly mathematically
sound. 

> SANE (Standard Apple Numerics Environment) explicitly states that it 
> signals an exception when doing ordered comparisons against NaNs because 
> to return False would be misleading. Apple went on to use the same rule 
> in their PowerPC Numerics. That's straight out of the Zen: Practicality 
> Beats Purity.

What is misleading and what is not depends on the context. One could
argue that if comparisons against NaN should signal an exception that
the exception comes late and should already have been signaled at the
moment the NaN was produced because producing a NaN is already
misleading. It gives the impression you have a (meaningfull) result
until you later try to do something with it that is illegal for a
NaN but for legal for a float.

If you allow NaN's as a result then you have extended the floats to
a mathematical set that is now only partially ordered. I see nothing
wrong in having the comparion operators give the result that belongs
to such a partial order.

-- 
Antoon Pardon