Re: Past uses of NaN?
On Nov 8 2010, Dan Zuras Intervals wrote:
Michel is correct.
Nobody was denying that. I don't want to enter into the religious
debate about which was the correct approach, but shall point out some
errors in the logic that led people down the path to C99. The root
cause of the problem is that NaN is being used inconsistently.
Please note that I am not being dogmatic here - I can accept any
reasonable and consistent model, and not just one of the ones used by
conventional mathematics, but it is impossible to analyse and
validate programs properly without SOME consistent and reasonable
mathematical model.
In the original IEEE 754, quiet NaNs were explicitly used for the result
of an invalid calculation, which might or might not be within the real
domain (in the case of sqrt(-1), it isn't). Call this meaning A.
Some people confounded that concept with that of an indeterminate value
(i.e. any value between -infinity and +infinity, inclusive) - call that
meaning B.
Furthermore, because IEEE 754 uses infinities as representations of very
large values as well as infinities, some people went so far as
confounding it with an indeterminate finite value (i.e. NOT including
true infinities) - call that meaning C.
Obviously A >> B >> C.
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,
In mathematics, with meaning A, they are not. The first is true
only for meaning B, and most of the others only for meaning C.
(However, powr(x,NaN) = powr(NaN,y) = NaN due to the fact
that powr is based on exp(y*ln(x)).)
That should be an implementation detail, and not control the
specification.
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.
I accept that writing the obvious code does fill the matrix with NaNs,
but that is arguably the correct behaviour, because those values are now
meaningless. Using the other value DOES improve the diagnosability, but
it does NOT generally "minimize the nasty effects of the NaN", unless
you regard sweeping errors under the carpet as minimising their nasty
effects.
Regards,
Nick Maclaren.