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

[Benjamin Root]

On Wed, Oct 2, 2013 at 1:05 PM, Charles R Harris
<charlesr.harris at gmail.com>wrote:

>
>
>
> On Wed, Oct 2, 2013 at 10:56 AM, <josef.pktd at gmail.com> wrote:
>
>> On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt <stefan at sun.ac.za>
>> wrote:
>> > On 2 Oct 2013 18:04, "Charles R Harris" <charlesr.harris at gmail.com>
>> wrote:
>> >>
>> >> The question is what to do when all-nan slices are encountered in the
>> >> nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the
>> first
>> >> returns nan and raises a warning, the second returns intp.min and
>> raises a
>> >> warning. It is proposed that the nanarg{max, min} functions, and
>> possibly
>> >> the nan{max, min} also, raise an error instead.
>> >
>> > I agree with Nathan; this sounds like more reasonable behaviour to me.
>>
>> If I understand what you are proposing
>>
>> -1 on raising an error with nan{max, min},
>>
>> an empty array is empty in all columns
>> an array with nans, might be empty in only some columns.
>>
>> as far as I understand, nan{max, min} only make sense with arrays that
>> can hold a nan, so we can return nans.
>>
>
> That was my original thought.
>
>
>>
>> If a user calls with ints or bool, then there are either no nans or
>> the array is empty, and I don't care.
>>
>> ---
>> aside
>> with nanarg{max, min} I would just return 0 in an all nan column,
>> since the max or min is nan, and one is at zero.
>> (but I'm not arguing)
>>
>>
> That is an interesting proposal. I like it.
>
> Chuck
>
>
>
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).

Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20131002/f61c16de/attachment.html>