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
ENH: Allow no conversion to scalar guarantee in ufunc and ufunc.outer #14489
base: main
Are you sure you want to change the base?
Conversation
86dc281
to
445c31d
Compare
Would be great if we could add this for reductions too - we don't want to end up in a limbo where |
Well, I am still not sure if I don't think that The change itself is going to be easy though, I think. |
I'm not suggesting we change the default any time soon, just that we give users the option to leave things wrapped for reductions too. |
Yeah, I was considering for a moment if |
Hmmmpf, there is an issue. Implementors of The other option would be to guarantee an array (EDIT: read |
@mhvk since I migrated a bit from the issue. just in case you are interested. Reduction is not an issue of course. The main issue is that |
d490a16
to
2d98a62
Compare
I think if this happens, we should just throw an exception - since |
I'd like to add this to triage review. |
We could also use |
Now that's an interesting idea. I almost wonder if we want to allow passing any array subclass in there. |
@eric-wieser well, we could initially only support ndarray. The thing I think that is missing is to figure out where we want to use this right now. I think it may be that almost(?) all places where we would be using this internally, we already make sure we are wokring with arrays. But yes, I like the idea as such to use the type... The issue is that we have no control over what |
Passing in |
The current commit uses ... which is short to write, but other than that does not have much reason going for. So we should probably change that.
So to be clear, the issue here is that Does |
Perhaps one option to get out of this issue: we change the signature to
|
Marking for re-triage, just because this came up as a pain-point during #16273 |
I haven't really followed this in detail, but just looked at the PR and that certainly looks good. I guess the choices are:
I'm not quite sure where we are in the development cycle, but if it is a few months to the next release, one could just start with the present PR and see if any of the packages that test against -dev start to fail... |
Notably, |
In this respect, perhaps the original |
I think the point you're missing is that |
Hmm, indeed. So I guess your solution makes more sense. I do wonder whether instead of creating a new keyword argument for what is a niche case instead always pass on a context, also for ufunc reductions, and include |
@eric-wieser triage marking is nice, but I need a bit more head-start to bring it up (and it would be best if you are around too). I still have to get to wrapping my head around the options, I guess the only way to support array-wrap is to add the argument. Which was why I think the PR basically used |
@seberg is this meant to be part of the ufunc reworking for 1.20 or do we let it slide to a future release? |
Let it slide, it might create ufunc rework merge conflicts, but is an unrelated feature. Should look at it and see if I can figure out how subclasses should be dealt with though :/. |
@seberg It looks like your recent work leads to a conflict. |
@seberg Needs rebase. |
@seberg Still interested in this? Needs rebase. |
It sounds like there is some serious thought about a 2.0. Maybe in that case we can just start to return array scalars instead of proper scalars? I.e., start to omit the cast to scalar? Apart from being mutable, the difference seems rather small. |
Does numpy 2.0 include deprecating scalars in favour of array scalars? If so, this becomes somewhat moot, but I didn't see it on the roadmap |
I don't want to aim for it. For me there are still quite a lot of unknowns and probably some exploration needed about how feasible it is. |
In that case, it is perhaps worth revising this PR? |
Yes, likely. Still haven't had the spark of the original idea how to deal with subclasses. We could also abuse An alternative thing that would be a big change, but not as big as removing scalars one, would be this: https://github.com/seberg/numpy/pull/new/try-0d-preservation that I tried to explore a bit today. The proposal would be to:
(The tail of that is not super trivial, quite a few test failures, scipy also relies on scalars in a few places for example, but it looks harmless). But run that branch with:
to try. A fun little caveat: |
This would still be nice to have, though I now wonder if numpy 2.0 isn't a good opportunity to just change it -- really, if one gives arrays as input, one should get arrays as output, even if the arrays happen to have shape |
The current commit uses
...
(Ellipsis
) instead of aleave_wrapped
singleton, which is short to write, but other thanthat does not have much reason going for. So we should probably
change that.
xref gh-13105