Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
FIX: Fix unit example so that we can unpin numpy<2.1#29616
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Closesmatplotlib#28780.The underlying problem is that operations on numpy scalars try toeagerly convert the other operand to an array. As a result `scalar = np.float64(2); scalar * radians` would result in a numpy scalar. But we don't want that.Instead we enforce `radians.__rmul__(scalar)` by giving the unit ahigher`__array_priority__`. See also https://github.com/numpy/numpy/issues/17650.I haven't found any specific change notes on this in numpy 2.1.Interestingly, the full story is even more complex. Also for numpy<2.1`radians.__rmul__(scalar)` is not called, but there seems anothermechanism through __array__ and __array_warp__ catching back in so thatthe result is again a TaggedValue. But I have not fully investigated why it worked previously. In fact, we want the solution here with going through __rmul__, and that works for all numpy versions.`
story645 left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
but also will follow up on discussion in issue about this example
3fa730d intomatplotlib:mainUh oh!
There was an error while loading.Please reload this page.
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove the If these instructions are inaccurate, feel free tosuggest an improvement. |
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove the If these instructions are inaccurate, feel free tosuggest an improvement. |
Don't see any point of backporting to the doc branch if 3.10.1 is imminent. |
…3.10.xBackport PR#29616 on branch v3.10.x (FIX: Fix unit example so that we can unpin numpy<2.1)
It's not urgent but somehow these changes should propagate to the doc branch. How does it work? Is doc reset to 3.10.x when that is released or is 3.10.x merged into doc? |
It's merged together before a release, and v3.10.1-doc starts fresh after v3.10.1 |
Closes#28780.
The underlying problem is that operations on numpy scalars try to eagerly convert the other operand to an array. As a result
scalar = np .float64(2); scalar * radianswould result in a numpy scalar. But we don't want that.Instead we enforce
radians.__rmul__(scalar)by giving the unit a higher__array_priority__. See alsonumpy/numpy#17650.I haven't found any specific change notes on this in numpy 2.1. Interestingly, the full story is even more complex. Also for numpy<2.1
radians.__rmul__(scalar)is not called, but there seems another mechanism through__array__and__array_warp__catching back in so that the result is again a TaggedValue. But I have not fully investigated why it worked previously. In fact, we want the solution here with going through__rmul__, and that works for all numpy versions.