-
Notifications
You must be signed in to change notification settings - Fork 88
Resolve numpy 1.25 issues #973
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
Conversation
cunumeric/module.py
Outdated
|
|
||
| if dtype is None: | ||
| dtype = np.find_common_type([], [type(start), type(stop), type(step)]) | ||
| dtype = np.result_type(type(start), type(stop), type(step)) |
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.
@seberg is this OK or do we need to pass actual scalars?
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.
find_common_type calls np.dtype() first while np.result_type tends to convert to arrays when it doens't see an exact scalar type or dtype. I think that could fail with the type() for very strange input.
So it should be a bit safer to pass the values (or use np.dtype(type(start)) to keep the identical behavior).
Passing values may also be more future-proof, but that goes into too much arange weirdness.
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.
* a little consistency between eager/deferred modules * pass deferred arrays to _call_full * avoid runtime getattr in ufuncs * split out where check to simplify _prepare_operands * fix test
This is an abridged version of #972 to clear up CI issues, that updates everything except a few more complicated uses of
find_common_types.A
test_argsort.pytest is failing for me locally, but also fails for me locally onbranch-23.07so I don't think it is related.