Repository navigation
np.max() doesn't behave properly for ndarray subclasses that define __array_ufunc__ #9102
Description
Take the following example:
import numpy as np
class MyArr(np.ndarray):
def __array_ufunc__(self, ufunc, method, *inputs, **kwargs):
func = getattr(ufunc, method)
inp = [i.view(np.ndarray) for i in inputs]
return func(*inp, **kwargs)
data = np.array([[1, 2, 3], [1, 2, 3]])
arr = data.view(MyArr)
print(data.max())
print(arr.max())
On numpy 1.13rc1 this prints:
3
[1 2 3]
For the call to arr.max() numpy calls __array_ufunc__, but there doesn't seem to be a way to tell from inside __array_ufunc__ that we should be reducing across the whole array and not just the first dimension. I think this would work properly if numpy were calling __array_ufunc__ with axis=None.
Ping @mhvk
Activity
eric-wieser commentedon May 11, 2017
Can you
print(inp, kwargs)in there too, and give the output?eric-wieser commentedon May 11, 2017
Actually, nevermind, I see the issue.
@mhvk, your normalization in
normalize_reduce_argsdiscards all arguments which areNone. This is bad for arguments whose default is notNone.Why do we do this check at all?
ngoldbaum commentedon May 11, 2017
Similarly for
np.any:prints:
Here the issue is that numpy is calling np.logical_or.reduce via
umr_any.mhvk commentedon May 11, 2017
Thanks, that is most clearly a bug! I'll try to get a fix in asap!
mhvk commentedon May 11, 2017
p.s. The check on
Nonewas meant forout-- it is definitely not intended to make this general (it may have something to do with trying to combine all normalizations and then undoing it...)mhvk commentedon May 11, 2017
Actually, no, now that I look at it again, I did this on purpose, mistakenly thinking that
Nonewas always the default (and wanting to remove any keyword arguments that were at their default). But in fact foraxis,0is the default. Anyway, I'll correct this to only removeout(also foraccumulate, etc.); I should have realized the code sees the arguments early enough that anything there is explicitly passed in.mhvk commentedon May 11, 2017
OK, see #9104.
@ngoldbaum - thanks for reporting -- I guess it is likely you'll find more mistakes, but hopefully not more such blatant ones! @eric-wieser - thanks for identifying the bug so quickly.
charris commentedon May 17, 2017
See #9106.