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

[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 :)

[Sylwester Arabas]

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
reduction.

[Sylwester Arabas]

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

[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.

[Sylwester Arabas]

Migrated to: https://github.com/blitzpp/blitz/issues/68