You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we only used the Array API internally to work on our .data, we would get support for other kinds of arrays than Numpy. This would be a huge task, but would bring high rewards (transparent dask or GPU support).
If we provided/exposed an Array API, which is a different task (also huge), we would also get high rewards: our Array objects would be usable as-is in some downstream libraries such as scikit-learn.
A much smaller/easier task would be to implement only the Data Interchange protocol (aka DLPack), which would make la.Array objects consumable directly by downstream libraries like scikit-learn (but would loose labels in the process).
I think this would only be a matter of implementing __dlpack__ and __dlpack_device__ methods both forwarding their calls to the respective methods on .data
The text was updated successfully, but these errors were encountered:
If we only used the Array API internally to work on our .data, we would get support for other kinds of arrays than Numpy. This would be a huge task, but would bring high rewards (transparent dask or GPU support).
This would make #530 obsolete I suppose.
If we provided/exposed an Array API, which is a different task (also huge), we would also get high rewards: our Array objects would be usable as-is in some downstream libraries such as scikit-learn.
A much smaller/easier task would be to implement only the Data Interchange protocol (aka DLPack), which would make la.Array objects consumable directly by downstream libraries like scikit-learn (but would loose labels in the process).
I think this would only be a matter of implementing
__dlpack__
and__dlpack_device__
methods both forwarding their calls to the respective methods on.data
The text was updated successfully, but these errors were encountered: