PoC: Try 0d preservation #52
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Sebastian Berg <sebastianb@nvidia.com>
<
8000
svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-git-commit">
Many remaining ones are around object arrays returning arguably better (less "NumPy") results, but probably not all :)
I don't believe in this (I mean as an option, I suppose who cares, but that isn't actually useful if you can never transition, IMO). But, it should be at least tried a bit, so...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements an older PoC to try preserving scalars in NumPy. It doesn't pass all tests, but it passes most (the test failures remaining are mostly bug-fixes around object arrays, but...).
This is in response to scientific-python/summit-2025#38. Since the change to NumPy (for the first part here!) isn't the blocker for a while now IMO, the blocker is to properly assess downstream impact.
(That was of course not always the case, there are many fixes in the past 2 years that enabled this.)
The simple rule is, if any input is already an array, the output should also be an array.
The one extension is that
axis=Nonefor reductions should return scalars. Some may argue that last rule, butNoneis special enough, and it doesn't even matter if you like it or not, because the main point is thatarr.sum()won't change behavior.(Gufuncs that remove axes will effectively always return arrays here, which may not always be desired.)
It also adds a last commit to enable
NUMPY_DISLIKE_SCALARS=1, if set, NumPy will never return scalars (this is probably even true for a lot of scalar math, so that is a problem).To be clear, while I am happy to agree that anything makes sense to try. I don't believe in this being feasible.
Since that doesn't work at all, it adds an
arr.to_scalar()method, that does the same asarr[()]did previously.