_nanop knowing about argmax/argmin is a total layering violation
though -- utility functions are supposed to be usable by knowing their
contract, you're not supposed to have to go poking around to see which
operations they have special magic knowledge about. Besides, the
problem here isn't that the operations are argmax/argmin, the problem
is that those operations (and who knows, maybe someday others) take
float arrays as inputs and return ints as outputs.

According to the chart:
  http://docs.scipy.org/doc/numpy/reference/arrays.scalars.html
what I meant was actually 'inexact', not 'floating', but the principle
seems sound...

On Fri, Jan 11, 2013 at 9:33 PM, Charles Harris
<notifications@github.com> wrote:
>
> In numpy/lib/function_base.py:
>
> > @@ -1397,6 +1397,9 @@ def _nanop(op, fill, a, axis=None):
> >          if np.isscalar(res):
> >              res = np.nan
> >          else:
> > +            if not np.issubdtype(res.dtype, np.floating):
>
> Noticed this also
>
> In [3]: np.float_(np.nan).astype(int)
> Out[3]: -9223372036854775808
>
> In [4]: np.float_(np.nan).astype(int8)
> Out[4]: 0
>
> ;) But I don't think that matters here. So you propose to keep the current behavior but add a future warning? My impression was that you wanted to raise an error. However, using a check for argmin|argmax looks like a good, explicit way to go that also clarifies exactly where the problem lies.
>
> —
> Reply to this email directly or view it on GitHub.