Velocity Reviews > When is min(a, b) != min(b, a)?

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

Mark Dickinson
Guest
Posts: n/a

 01-28-2008
On Jan 28, 6:50 am, Antoon Pardon <(E-Mail Removed)> wrote:
> People who somehow made it clear they know how to work with inf, and
> NaN results, would get silent NaN where no exceptions would be thrown.

One other thing: there's an excellent starting point for considering
how things should work, in the form of the Decimal type. This does
exactly what you suggest: by default, users get Python exceptions
instead of NaNs and/or infinities, but the user can override the
defaults to switch off the various traps (Overflow, Invalid, etc.) and
work directly with NaNs and infinities if (s)he prefers.

Note also that decimal.py runs to over 5000 lines of (Python) code!
And that's without having to deal with the vagaries of the C-compiler/
library/OS/hardware, since everything's implemented directly in
Python. A surprisingly small amount of that code is actually 'real'
mathematics: most of it is devoted to dealing correctly with
infinities, NaNs, signed zeros, subnormals, `ideal' exponents, traps,
flags, etc.

Mark

Albert van der Horst
Guest
Posts: n/a

 02-04-2008
In article <(E-Mail Removed)>,
Steven D'Aprano <(E-Mail Removed)> wrote:
>On Thu, 24 Jan 2008 13:34:56 +0000, Antoon Pardon wrote:
>
>> On 2008-01-21, Steven D'Aprano <(E-Mail Removed)>
>> 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@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst