ENH: Make signed/unsigned integer comparisons exact#23713
Merged
charris merged 2 commits intonumpy:mainfrom May 7, 2023
Merged
ENH: Make signed/unsigned integer comparisons exact#23713charris merged 2 commits intonumpy:mainfrom
charris merged 2 commits intonumpy:mainfrom
Conversation
This makes comparisons between signed and unsigned integers exact
by special-casing promotion in comparison to never promote integers
to floats, but rather promote them to uint64 or int64 and use a
specific loop for that purpose.
This is a bit lazy, it doesn't make the scalar paths fast (they never were
though) nor does it try to vectorize the loop.
Thus, for cases that are not int64/uint64 already and require a cast in
either case, it should be a bit slower. OTOH, it was never really fast
and the int64/uint64 mix is probably faster since it avoids casting.
---
Now... the reason I was looking into this was, that I had hoped
it would help with NEP 50/weak scalar typing to allow:
uint64(1) < -1 # annoying that it fails with NEP 50
but, it doesn't actually, because if I use int64 for the -1 then very
large numbers would be a problem...
I could probably(?) add a *specific* "Python integer" ArrayMethod for comparisons
and that could pick `object` dtype and thus get the original Python object
(the loop could then in practice assume a scalar value).
---
In either case, this works, and unless we worry about keeping the behavior
we probably might as well do this.
(Potentially with follow-ups to speed it up.)
Member
|
Thanks Sebastian. There were a couple of long lines that could be fixed, but maybe we should make a sweep for such things before the 2.0 release. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This makes comparisons between signed and unsigned integers exact by special-casing promotion in comparison to never promote integers to floats, but rather promote them to uint64 or int64 and use a specific loop for that purpose.
This is a bit lazy, it doesn't make the scalar paths fast (they never were though) nor does it try to vectorize the loop.
Thus, for cases that are not int64/uint64 already and require a cast in either case, it should be a bit slower. OTOH, it was never really fast and the int64/uint64 mix is probably faster since it avoids casting.
Now... the reason I was looking into this was, that I had hoped it would help with NEP 50/weak scalar typing to allow:
but, it doesn't actually, because if I use int64 for the -1 then very large numbers would be a problem...
I could probably(?) add a specific "Python integer" ArrayMethod for comparisons and that could pick
objectdtype and thus get the original Python object (the loop could then in practice assume a scalar value).In either case, this works, and unless we worry about keeping the behavior we probably might as well do this.
(Potentially with follow-ups to speed it up.)