bug: reducers from numpy no longer seem to work?

[lgray]

Tests with this sort of syntax were passing until dask-awkward 2023.11.0.

@agoose77 @douglasdavis

import numpy as np
import uproot

events = uproot.dask("https://github.com/CoffeaTeam/coffea/raw/master/tests/samples/nano_dy.root:Events")

np.all(events.Muon_pt > 30)

it now fails with:

  File "<stdin>", line 1, in <module>
  File "<__array_function__ internals>", line 200, in all
  File "/Users/lgray/miniforge3/envs/coffea-dev/lib/python3.8/site-packages/numpy/core/fromnumeric.py", line 2515, in all
    return _wrapreduction(a, np.logical_and, 'all', axis, None, out,
  File "/Users/lgray/miniforge3/envs/coffea-dev/lib/python3.8/site-packages/numpy/core/fromnumeric.py", line 86, in _wrapreduction
    return ufunc.reduce(obj, axis, dtype, out, **passkwargs)
  File "/Users/lgray/miniforge3/envs/coffea-dev/lib/python3.8/site-packages/dask_awkward/lib/core.py", line 1380, in __array_ufunc__
    raise RuntimeError("Array ufunc supports only method == '__call__'")
RuntimeError: Array ufunc supports only method == '__call__'

This is also true of np.sum, np.any, etc.

[agoose77]

I saw the word "ufunc" and immediately thought "oh no, what did I break now" 😆

This happens because we use the __array_function__ mechanism to intercept reducers. It looks we don't handle that in dask-awkward right now.

Whilst we could make np.all work here, I think it will be a lot easier for us if we make that an error and instead require ak.all; the NumPy compatibility behavior is defined in Awkward, and would be a bit fiddly to reproduce.

N.B. that I can't immediately conceive of why this would've stopped working in recent versions. I'm assuming that the test with np.XXX is actually a new one.

[lgray]

@agoose77 the test that fails first with np.all has been there for several months.

[lgray]

and it's littered throughout the coffea testing, this has worked for quite some time.

[lgray]

In fact tests using np.all with awkward arrays go back several years, looking at blame.