Support for 2023.12

[asmeurer]

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 (data-apis/array-api-tests#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 data-apis/array-api-tests#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 to astype
• from_dlpack requires exceptions in some cases (won't be wrapped)
• copy and device keywords to from_dlpack (won't be wrapped)
• sum, prod, trace output dtype change (Update dtype assertions in sum-like tests for >2023.12 versions array-api-tests#234)

Other Changes

• tensordot should support negative axes

[asmeurer]

#166

[asmeurer]

@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:

• How can I get a list of all devices (for devices()). Is this correct?

  def devices():
      return [cupy.cuda.Device(i) for i in range(cupy.cuda.runtime.getDeviceCount())]

• Is cupy.Device(0) always the default device?
• Is it possible for a CUDA device to not support all the dtypes defined in the standard? If so, how can this be introspected?
• Can the default dtypes ever differ across devices, and do they differ from NumPy?
• Are there plans to port the inspection APIs (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.

[asmeurer]

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.

[asmeurer]

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"?

[asmeurer]

searchsorted and tile are still only minimally implemented in the test suite (no actual testing of values or of keyword arguments). However, I believe the existing libraries all implement them correctly, (except for dask, which I can see from the source does not support negative repetitions in tile or sorter in searchsorted, but those are perhaps best left to the upstream anyways).

[asmeurer]

I'd say we can close this. If we run into more issues as we update the test suite, we can fix them.