8000 ENH enable `__imatmul__` for ArrayAPI compatability. by Micky774 · Pull Request #21912 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content
8000

ENH enable __imatmul__ for ArrayAPI compatability. #21912

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

Closed
wants to merge 5 commits into from

Conversation

Micky774
Copy link
Contributor
@Micky774 Micky774 commented Jul 3, 2022

Enables __imatmul__, albeit just inefficiently performing the out-of-place operation and copying, to bring ndarray closer to ArrayAPI compatability.

@seberg
Copy link
Member
seberg commented Jul 5, 2022

I am still hesitant about this, since it seems very unintuitive that a @= b would be slower than a = A @ b.

I just tried this:

In [23]: t = torch.Tensor([[1, 2], [3, 4]])

In [24]: a = t

In [25]: t += t

In [26]: a
Out[26]: 
tensor([[2., 4.],
        [6., 8.]])

In [27]: a is t
Out[27]: True

In [28]: t @= t

In [29]: a is t
Out[29]: False

In [30]: t
Out[30]: 
tensor([[28., 40.],
        [60., 88.]])

In [31]: a
Out[31]: 
tensor([[2., 4.],
        [6., 8.]])

IMO, that is not great, since torch fails to implement in-place (maybe for good reasons, since it is often not possible for @). But, if the option is to make all operands in-place except matmul, my gut feeling is to prefer the NumPy version.

@seberg
Copy link
Member
seberg commented Jul 5, 2022

OTOH, maybe the speed difference is small and we can optimize the stacked array case at least? Might be nice to confirm, and I wonder if we should tie this to the fixing the stacked array version (which is not quite trivial!).

@seberg seberg added triaged Issue/PR that was discussed in a triage meeting triage review Issue/PR to be discussed at the next triage meeting and removed triaged Issue/PR that was discussed in a triage meeting labels Jul 7, 2022
@seberg seberg added triaged Issue/PR that was discussed in a triage meeting and removed triage review Issue/PR to be discussed at the next triage meeting labels Nov 16, 2022
@seberg
Copy link
Member
seberg commented Nov 16, 2022

We discussed this today a bit, and were a bit unsure that this is actually a good match. So I thought I would bring it up again with the data-api: data-apis/array-api#509

@seberg
Copy link
Member
seberg commented Nov 17, 2022

Closing this one because #21120 is much further along. It could be picked up as a new PR of course.

@seberg seberg closed this Nov 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
01 - Enhancement triaged Issue/PR that was discussed in a triage meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0