Richard E Maine wrote:
> 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.
>
By extension, I infer that maxval() or minval() would produce NaN if any
is present. Likewise, minloc() and maxloc() would point to the first
NaN in the operand. These are not the behaviors of compilers I have
tested. gfortran ignores NaNs, which is a more consistent behavior than
others. While I'm on the subject, do people still avoid depending on
minloc(x(n:1:-1),dim=1) to count downwards from n ? Too many past
compilers treated this as indeterminate.
|