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

Charles R Harris charlesr.harris at gmail.com
Wed Oct 2 13:05:28 EDT 2013

```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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20131002/fbeeea81/attachment.html>
```