-
Notifications
You must be signed in to change notification settings - Fork 29
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
Support the copy keyword in asarray #119
Conversation
This does remove jax testing from the isdtype test, since we should not test jax functionality for non-helper functions.
This test currently fails because this logic isn't implemented correctly for numpy/cupy/dask. It does pass for pytorch.
This now properly supports all relevant versions of NumPy. This also removes the asarray_numpy function from the namespace. I plan to do the same for cupy and dask as well.
This also fixes the device keyword to actually work, and fixes copy=None logic. copy=False is not implemented and requires upstream support, which should come in CuPy 14.
array_api_compat/cupy/_aliases.py
Outdated
# cupy is like NumPy 1.26 (except without _CopyMode). See the comments | ||
# in asarray in numpy/_aliases.py. | ||
if copy is None: | ||
copy = False |
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.
@leofang did you say at the meeting today that cupy 14 would definitely support NumPy 2.0? The meaning of copy=False changed between NumPy 1.26 and 2.0. Is it safe to add a if cupy.__version__ >= 14
check here? If we just leave this wrapper code as it is, it will break once cupy makes the change, because the default would become the array API copy=False semantics.
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.
It was TBD so here's my question: I would think like dpctl once CuPy is compliant we'd no longer need array-api-compat coverage? If so, I don't think we need a version check here, as it'd become moot anyway? WDYT?
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.
The way the compat library currently works is unconditionally wraps cupy. We could remove the wrapping once cupy is compliant but we'd need a version check to do that too.
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.
I mean, the version check could be added to, say, __init__.py
instead of here, once we know better after which CuPy version all array-api-compat wrappers can just fall back to native CuPy without extra action (=no-ops), right? Maybe I oversimplified it?
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.
If cupy is completely compliant and needs no wrappers we could do that. We're not doing that yet for numpy 2.0 but we probably should.
At any rate, I've thought of a better way to structure this code so that it won't actually break when cupy changes the meaning of copy=False
, so this isn't actually important. I'll still need to update this to remove the NotImplementedError
for copy=False
, but is isn't pressing to try to do it ahead of time now because I've made it so that the default behavior won't break, and that would be a new feature for cupy anyways.
This way it is more future-proof for when cupy changes the meaning of copy=False.
This also fixes several bugs in the implementation, and updates some tests.
@lithomas1 can you take a look at the dask.array changes here. |
Python 3.8 is starting to become a nuisance. I think I'm going to just drop support for it. |
Other libraries currently break with numpy 2.0.
Not finished yet. Still need to: