#35 min([NaN,NaN]) != NaN

arrays (15)
Sylwester Arabas

The following code:

#include <blitz/array.h>
using namespace blitz;
int main()
Array<float, 3> arr(Range(0,10));
arr = quiet_NaN(float(0));
std::cout << "min: " << min(arr) << std::endl;
std::cout << "max: " << max(arr) << std::endl;

... gives the following output:

$ ./a.out
min: 3.40282e+38
max: -3.40282e+38

... which is (arguably) kind of non-intuitive.

In particular, an assertion using isnan(min()) or finite(min())
would not detect presence of NaNs, which is yet more non-intuitive :)


  • Patrik's comment from the mailing list:

    Yeah, that's suboptimal. NaN isn't greater or less than anything, so
    the initial value never gets replaced in the reduction. We can't just
    check if the result is huge, because the result COULD actually be
    huge. We'd need a separate comparison against NaN for all elements
    (but only for T_numtypes that actually have NaN.)

    However, that would change the existing behavior which (I assume) says
    that min([ 1 2 3 NaN]) is 1 and not NaN. What's the desired behavior
    here. It seems reasonable to have the NaN always be captured in the

  • Concerning the behaviour with min([ 1 2 3 NaN]), I'd say that it deserves at least a note in the docs.

  • Patrik Jonsson
    Patrik Jonsson

    • status: open --> open-accepted
  • Patrik Jonsson
    Patrik Jonsson

    Initializing the min/max reductions with the first value as opposed to with huge/neghuge should take care of this. However, I'm having difficulties making that change without breaking stuff.