[Numpy-discussion] min() of array containing NaN

[Anne Archibald]

2008/8/14 Norbert Nemec <Norbert.Nemec.list at gmx.de>:
> Travis E. Oliphant wrote:
>> NAN's don't play well with comparisons because comparison with them is
>> undefined.    See  numpy.nanmin
>>
> This is not true! Each single comparison with a NaN has a well defined
> outcome. The difficulty is only that certain logical assumptions do not
> hold any more when NaNs are involved (e.g. [A<B] is not equivalent with
> [not(A>=B)]). Assuming an IEEE compliant processor and C compiler, it
> should be possible to code a NaN safe min routine without additional
> overhead.

Sadly, it's not possible without extra overhead. Specifically: the
NaN-ignorant implementation does a single comparison between each
array element and a placeholder, and decides based on the result which
to keep. If you try to rewrite the comparison to do the right thing
when a NaN is involved, you get stuck: any comparison with a NaN on
either side always returns False, so you cannot distinguish between
the temporary being a NaN and the new element being a non-NaN (keep
the temporary) and the temporary being a non-NaN and the new element
being a NaN (replace the temporary). If you're willing to do two
tests, sure, but that's overhead (and probably comparable to an
isnan). If you're willing to do arithmetic you might even be able to
pull it off, since NaNs tend to propagate:
if (new<min) min -= (min-new);
Whether the speed of this is worth its impenetrability I couldn't say.

What do compilers' min builtins do with NaNs? This might well be
faster than an if statement even in the absence of NaNs...

Anne