On Sep 15, 2005, at 8:34 AM, Greg Lindahl wrote:
> What's the right thing for the max() function to do when some of
> the inputs are NaNs?
>
> Since comparisons with NaNs are always false, I'm not sure if there is
> a right answer.
I think that NaN is the right answer for 2 reasons.
1. I'd say that "not a right answer" translates pretty closely, at
least in this case, to "not a number", also known as NaN. That's the
kind of reason that some operations, like 0./0., give NaN as a result.
In some sense, the result of 0./0. could be anything, there being no
single right numeric answer. We (well IEEE) give NaN as the result for
that case. Max() seems similar in that regard to me. If one considered
a NaN to be like something that could have any value, then a max()
involving a NaN could also have any value (well, limited by the max of
the non-NaN ones, but that still leaves a lot of values).
2. Most numeric operations with NaNs as operands should produce NaNs as
results. I see nothing particularly unique about max() in this regard.
I don't see that the issue of comparisons directly gives an answer
here. At some level, one can describe max() as being based on
comparisons, but I think that at an even lower level, it is an
arithmetic operation. If its operands are not numbers, then its
operation can't be done numerically, so the result is a NaN.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|