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
The current situation when an index is an array of ints or bools is very messy:
numpy blindly passes every unexpected object it finds to np.asarray, which makes it accept np.ndarray, lists, tuples, but also memoryviews and anything with an __array__ interface
Sparse accepts lists, tuples, or numpy arrays; other sparse arrays don't work
PyTorch won't accept numpy arrays of unsigned integers
PyTorch won't accept PyTorch arrays of integers with dtype other than the native int
JAX won't accept lists or tuples
dask won't accept tuples
I think the array API standard should define a reasonable common surface.
Just a quick note that take is the standardized/uniform way of doing indexing with an integer array (xref gh-416 and the issue that PR links to).
You're completely right that it's very messy across libraries - it's just very hard, since we can't mandate that libraries stop doing something and break backwards compatible (or technically we can, but it'll probably just be ignored rather than implemented).
The current situation when an index is an array of ints or bools is very messy:
__array__
interfaceI think the array API standard should define a reasonable common surface.
xref data-apis/array-api-compat#205 (comment)
NOTE: the much more complicated case of multiple fancy indices, e.g.
a[[0, 1], [1, 2]]
is out of scope for this issue.The text was updated successfully, but these errors were encountered: