Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

np.sum fails with awkward arrays in v2 #1612

Closed
alexander-held opened this issue Aug 21, 2022 · 4 comments
Closed

np.sum fails with awkward arrays in v2 #1612

alexander-held opened this issue Aug 21, 2022 · 4 comments

Comments

@alexander-held
Copy link
Member

Version of Awkward Array

1.9.0rc10

Description and code to reproduce

Performing a sum over an awkward array by calling np.sum fails with the awkward v2 API. It works in v1. A similar function (at least I expected it would behave similarly), np.mean, works fine with v2 as well. I am using numpy version 1.23.2.

import awkward._v2 as ak
import numpy as np

arr = ak.Array([1, 2, 3])
print(ak.sum(arr))  # this works
print(np.sum(arr))  # TypeError

print(np.mean(arr))  # this works

output:

6
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    print(np.sum(arr))  # TypeError
  File "<__array_function__ internals>", line 180, in sum
  File "[...]/lib/python3.9/site-packages/numpy/core/fromnumeric.py", line 2298, in sum
    return _wrapreduction(a, np.add, 'sum', axis, dtype, out, keepdims=keepdims,
  File "[...]/lib/python3.9/site-packages/numpy/core/fromnumeric.py", line 86, in _wrapreduction
    return ufunc.reduce(obj, axis, dtype, out, **passkwargs)
TypeError: operand type(s) all returned NotImplemented from __array_ufunc__(<ufunc 'add'>, 'reduce', <Array [1, 2, 3] type='3 * int64'>, axis=None, dtype=None): 'Array'
@alexander-held alexander-held added the bug (unverified) The problem described would be a bug, but needs to be triaged label Aug 21, 2022
@jpivarski
Copy link
Member

It's because we have np.sum overloading the v1 ak.sum and will be able to switch it to the v2 ak.sum when v1 is actually dropped.

At some point soon, we'll have to split the git branches into a main (v2 only) and main-v1 (v1 only), so that things like this can be handled. But the split between Uproot main (v5) and main-v4 (v4) already means we have to do extra work whenever we need to backport a fix to both branches. We want to split the git branches when we're reasonably sure that the old version is done (i.e. don't expect to have to backport much).

@jpivarski jpivarski removed the bug (unverified) The problem described would be a bug, but needs to be triaged label Aug 21, 2022
@jpivarski
Copy link
Member

I don't know how to classify this: it's not a bug, but it's not any of the other labels, either. It's not a policy because we will be switching the NEP-18 coverage over from v1 to v2, we just haven't done it yet.

@agoose77
Copy link
Collaborator

I do think we might need a few more issue labels that we have currently. I find myself sometimes reaching for one and not finding it. Some projects have a 'intended behaviour' label?

@agoose77
Copy link
Collaborator

Fixed by #1721

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants