diff options
author | Sebastian Berg <sebastianb@nvidia.com> | 2023-05-04 16:33:27 +0200 |
---|---|---|
committer | Sebastian Berg <sebastianb@nvidia.com> | 2023-05-04 16:33:27 +0200 |
commit | ec8d5db302c0e8597feb058f58863d5e9a6554c1 (patch) | |
tree | 6edf099a4deebdc5ab86fdad314a892d3db7db7b /numpy/distutils/_shell_utils.py | |
parent | c37a577c9df74e29c97a7bb010de0b37f83870bb (diff) | |
download | numpy-ec8d5db302c0e8597feb058f58863d5e9a6554c1.tar.gz |
ENH: Make signed/unsigned integer comparisons exact
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.)
Diffstat (limited to 'numpy/distutils/_shell_utils.py')
0 files changed, 0 insertions, 0 deletions