Open asmeurer opened 5 months ago
@leofang I'm looking at implementing the inspection APIs for CuPy https://data-apis.org/array-api/latest/API_specification/inspection.html. I have some questions:
devices()
). Is this correct?
def devices():
return [cupy.cuda.Device(i) for i in range(cupy.cuda.runtime.getDeviceCount())]
cupy.Device(0)
always the default device?numpy/_array_api_info.py
) over to CuPy itself soon? If so I can just wait and then copy that code here. Unfortunately, while I do have a CUDA GPU, I don't currently have a machine with more than one to test this stuff on.
I implemented something at https://github.com/data-apis/array-api-compat/pull/166/files#diff-c81a58c37b983a1eea2b7fcc43f23c8c769acac5e6d0cf1763e9a3964568c035, but I made some assumptions about the answers to the above questions.
Looking at PyTorch, there are some questions that arise for inspection APIs:
How do you get a list of all devices? PyTorch supports multiple backends, only a subset of which will actually be available at runtime. Do I need to gather a list of every possible backend and check if it's available. I think that's possible (see https://pytorch.org/docs/stable/backends.html), although it won't be very future-proof.
How can I tell what dtypes are supported on which devices? Is my only option to test them directly?
Are the default dtypes always the same in PyTorch (int64, float32, complex64)?
Should the dtypes()
function return unsigned integer dtypes? PyTorch has objects for unsigned integer objects, but support for them is limited. For the purposes of the array API, they are not fully implemented (they have to be skipped in the test suite).
Is it correct that the default device should always be "cpu"?
This is a tracking issue for 2023.12 support in array-api-compat.
The list of changes for 2023.12 is at https://data-apis.org/array-api/latest/changelog.html#v2023-12
Currently, we don't have test suite support for 2023.12 (https://github.com/data-apis/array-api-tests/issues/249), so it's hard to implement full support. However, if there are any known differences for a given library and 2023.12, we can implement a wrapper for them, especially if this is blocking anyone's real world usage. Please comment below if this is the case for you.
Note that any function that is already implemented in upstream libraries will already work with array-api-compat, since it only extends the existing library namespaces. So this is only necessary if some upstream function or behavior is different from what is written in the 2023.12 standard.
Here is the checklist of functions (from https://github.com/data-apis/array-api-tests/issues/249):
Here is the list of changes https://data-apis.org/array-api/latest/changelog.html#v2023-12
New Functions
__array_namespace_info__
(i.e., the inspection API)clip
(not implemented for dask, as the wrapper implementation uses mask assignment)copysign
cumulative_sum
hypot
maximum
minimum
moveaxis
repeat
searchsorted
signbit
tile
unstack
API Changes
device
keyword added toastype
from_dlpack
requires exceptions in some cases~ (won't be wrapped)copy
anddevice
keywords tofrom_dlpack
~ (won't be wrapped)sum
,prod
,trace
output dtype change (https://github.com/data-apis/array-api-tests/issues/234)Other Changes
tensordot
should support negative axes