Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

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

open-accepted
nobody
arrays (15)
5
2012-04-17
2012-01-17
Sylwester Arabas
No

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

Discussion

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

     
  • 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
    2012-04-17

    • status: open --> open-accepted
     
  • Patrik Jonsson
    Patrik Jonsson
    2012-04-17

    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.