-
-
Notifications
You must be signed in to change notification settings - Fork 779
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
Adopt Python Array API standard #4789
Comments
See numpy/numpy#18585. |
@kmaehashi Would CuPy follow exactly what NumPy does and creates a new |
We will follow NumPy's design as our goal is to be a drop-in replacement for NumPy 😄 |
Thanks for confirming @kmaehashi! |
Update: NumPy has done its first pass! numpy/numpy#18585 |
This is a meta-issue tracking the adoption of Python Array API standard:
In the Data API weekly meetings, it was decided that a reference implementation will be provided to NumPy (see NEP-47), which other implementations can follow and test against. Given that CuPy is IMHO by far the most compliant library with the API standard (probably more compliant than NumPy is, given many design deviations), I think it is much easier if we just wait until the ref implementation is out, and try taking it as is.
A new array object will be added in a separate namespace, delegating real work to
cupy.ndarray
whenever appropriate. Following NEP-47 I suggest the namespace to becupy.array_api
, but I supposecupyx.array_api
is also a fine choice.The array object will only have "dunder" methods (names with double underscores), and all APIs for manipulating this object live under the new namespace.
But in addition to the new array object and APIs added to the new namespace, similar to
numpy
/numpy.ndarray
there are some work to be done in thecupy
namespace as well as incupy.ndarray
. A list of such examples are copied from NEP-47 for convenience:ndarray.__dlpack__
ndarray.__dlpack_device__
ndarray.device
In addition, since DLPack is the main data exchange mechanism, we better support
kDLCPUPinned
) (related: Pinned memory allocation returns odd size #3625)There are still some issues in the standard to be ironed out (ex: linalg related APIs), but I think it's getting close to be completed.
The text was updated successfully, but these errors were encountered: