Re: Past uses of NaN?
> Date: Mon, 08 Nov 2010 10:18:28 -0500
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Re: Past uses of NaN?
>
> Replying to Nick MacLaren, Nate Hayes wrote:
> > In your paper I see you did suggest min and max should be required
> > to percolate NaNs and raise exceptions, just like any other numeric
> > (arithmetic) operation.
>
> At one point IEEE 754R had both min/max and minnum/maxnum, with only
> the former propagating NaNs. I don't remember what discussion led
> to abandoning the distinction and using minnum/maxnum semantics but
> dropping "num" from the names.
>
> Michel.
> ---Sent: 2010-11-08 15:23:53 UTC
Michel is correct.
The history of it is that there were initially two groups of
min/max functions: those that returned a NaN when compared
to other numbers named minnan, maxnan, minabsnan, & maxabsnan;
& those that returned the number rather than the nan named
minnum, maxnum, minabsnum, & maxabsnum.
People that supported the NaN preserving group argued that
these functions should behave as any other dyadic function
& return a NaN when a NaN appeared on input. NaN perserving
functions was considered one of the sacred principles upon
which 754 stood.
People that supported the number preserving group argued that,
of the two arguments, the number was the only one that COULD
be compared for size & should be returned on that basis.
Practically, the path that returned the NaN did something
bogus & so the other path contained the only valid result.
Therefore, much like our 1788 arguments involving intervals
that extend beyond a function's domain, only the valid
results have any meaning.
These two camps were irreconcilable. And the situation
stood with both groups of functions for some years.
But over time we came to realize that NaN preserving was not
so absolute as you might think. It is universal among the
basic +, -, *, / functions but exceptions turned up as we
went through the special cases among the transcendental
functions in section 9.2.
All of the following are true: hypot(+/-inf,NaN) = +inf,
compound(NaN,0) = pown(NaN,0) = pow(NaN,0) = pow(1,NaN) = 1,
(However, powr(x,NaN) = powr(NaN,y) = NaN due to the fact
that powr is based on exp(y*ln(x)).)
Also, in section 9.3, sumSquare & sumAbs return +inf if
there are both infinite & NaN elements to be summed.
The rationale for these exceptions is that some functions
in some portion of their domain are independent of one or
more of their operands. Thus, for example, hypot(x,+/-inf)
is independent of x. When this is the case, such a function
may be written so as not to even READ the other operand as
it is not needed to know the result.
Then it was realized that functions like min & max are
really special selection functions. That is, they are
special cases of f(x,y) = if (condition) then x else y.
Or, to use C notation, f(x,y) = (condition)?x:y;. Selection
functions routinely pay no attention to NaN preservation
when the NaN appears on the path NOT selected. For good &
obvious reasons: the condition likely tested for some
property to determine whether or not a given path was safe
to use in a calculation & the NaN would have come up in the
'not safe' case.
Finally, it was pointed out that one of these functions,
maxabs, is used universally to pick a pivot element in
matrix operations. In this case it is much to be
preferred to pivot on the number rather than the NaN.
The former minimizes the nasty effects of the NaN while
the latter fills the matrix with NaNs & obscures the
location of the original problem.
And, by this time, everyone was tired of having two classes
of these functions.
So eventually it was moved & passed that we eliminate the
NaN preserving class. Then later we dropped the 'num' from
the names as the distinction no longer had any meaning.
That's the history of how the min/max functions came to
be number preserving.
It was a judgement call. I think it was a good one. But
you may differ in that opinion.
That's up to YOUR judgement.
Dan