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

[Albert van der Horst]

In article <13pi8fiiqgljdb5 at corp.supernews.com>,
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, ...)
>
>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.

This is the more so, keeping in mind that the original motivation for
Nan's is to avoid exceptions. In principle to keep algorithms clean,
you would like to have exceptions as soon as you divide by zero, or
overflow. This is extremely costly on high efficiency floating point
hardware, (you may have a pipeline stall to allow the point of
exception to be defined, even if the exception doesn't occur)
so IEEE allows to propagate the exception via Nan to occur at
a convenient time, e.g. when the output of a matrix multiplication
is inspected.

Comparisons mark the moment that a decision is made.
Now masking the problem, by taking an invalid hence arbitrary
decision based on an invalid result, is insane. The Nan is
forever gone, something not allowed by IEEE only in code that

[A case can be made however that min and max just propagate a
Nan and don't throw an exception, yet. ]

So python should throw. That is practicality *and* purity.

>--
>Steven

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst