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

open-accepted
nobody
arrays (15)
5
2012-04-17
2012-01-17
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

  • 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

    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.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks