[Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

[Nathaniel Smith]

On Wed, Oct 2, 2013 at 8:19 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
>
> On Wed, Oct 2, 2013 at 12:51 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Wed, Oct 2, 2013 at 2:49 PM,  <josef.pktd at gmail.com> wrote:
>> > On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt <stefan at sun.ac.za>
>> > wrote:
>> >> On 2 Oct 2013 19:14, "Benjamin Root" <ben.root at ou.edu> wrote:
>> >>>
>> >>> And it is logically consistent, I think.  a[nanargmax(a)] == nanmax(a)
>> >>> (ignoring the silly detail that you can't do an equality on nans).
>> >>
>> >> Why do you call this a silly detail? It seems to me a fundamental flaw
>> >> to
>> >> this approach.
>> >
>> > a nan is a nan is a NaN
>> >
>> >>>> np.testing.assert_equal([0, np.nan], [0, np.nan])
>> >>>>
>>
>> and the functions have "nan" in their names
>> nan in - NaN out
>>
>> what about nanmean, nansum, ...?
>
> nanmean returns nan for empty slices while nansum returns nan in 1.8,
> consistent with previous behavior, and will return 0 in 1.9.
>
> The main problem I had was deciding what arg{max, min} should return as the
> return value is an integer. I like your suggestion of returning 0.

I don't understand the justification for returning 0 at all. "nan" is
not the max or min or the array. Even if argmax/argmin return nan[1],
it's just a special code meaning "undefined", it has no relation to
the nans inside the array. So returning 0 just feels to me like pure
"we have to return *something* and this something! (that we can kind
of justify is no-one looks too hard!)". This exactly the impulse that
"when in doubt refuse the temptation to guess" is written to
counteract...

Seriously what user calls nanargmax and *wants* to get pointed to a
random nan inside the array? Isn't the whole point of calling
nanargmax to avoid exactly this situation?

-n

[1] It seems clear that we shouldn't mess about with argmax/argmin for
1.8, but my guess is that in the long run we'll come up with a more
general convention for signalling partial errors, and eventually want
to switch nanargmax/nanargmin to using that.