2008/8/14 Norbert Nemec <[EMAIL PROTECTED]>: > 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion