In numpy.array_api, we said that type checking that inputs were Array was too much overhead, and we would just rely on the the type signatures and type checking to do this.

However, given that we are no longer thinking of this library as something that is used in production, I don't think we need to worry so much about the overhead of type checking. It might be a good idea to add explicit type checks to functions. This would prevent a sufficiently duck-typed object from silently passing through, although that's pretty unlikely since basically every function uses x._array on its input. The real reason would be to provide better error messages that AttributeError on bad inputs.

Maybe this can be done automatically from the type signatures using one of those fancy libraries I know nothing about.

https://data-apis.org/array-api/latest/API_specification/generated/array_api.unstack.html

I would appreciate if you could update this with an unstack command!

See https://data-apis.org/array-api/latest/API_specification/data_types.html#default-data-types and https://data-apis.org/array-api/latest/API_specification/generated/array_api.info.default_dtypes.html#array_api.info.default_dtypes.

We should add flags to the set_array_api_strict_flags to configure these away from the NumPy defaults.

One concern here is that some instances of moving from float64 to float32, we might have to just downcast the result from NumPy, meaning the computation will still happen in float64, producing a result that could be different from a library that actually does everything in float32. This should likely be worked around wherever possible by downcasting the input before computing rather than the output.

Obviously not just yet, but once NumPy 2.0 is released and stable, we should drop support for NumPy 1.26 as a backend. That would allow us to remove all the compatibility code and only have code related to strictness.

The actual backend in array-api-strict doesn't really matter that much, but this would limit the usability for libraries that use NumPy internally in addition to the array API, so we should only do this once the ecosystem seems generally caught up on NumPy 2.0 support.

We may want to move cupy.array_api to this library as a cupy backend. That would provide support for non-trivial device support, which is currently the one thing that can't really be checked that much through the usage of this library alone.

Right now the documentation for the API just points to the standard. https://data-apis.org/array-api-strict/api.html#array-api-functions

It would be useful to have a short docstring for each function that points to its standard implementation, and includes any other relevant notes. Right now the docstrings point to the corresponding numpy functions, but pointing to the standard would be more appropriate.

Should we support older versions of the standard?

I don't think there's any point to supporting 2021.12, since no implementation actually supports it (including array-api-compat). However, as libraries actually start implementing the standard, being able to support multiple versions here could be useful.

For now, we could just tell people to install older versions of array-api-strict. But if people actually test against old versions of the standard, I would much rather just support them at once here than trying to support backport versions.

Plus, the __array_namespace__ method has the version flag specifically for this sort of thing.

By the way, if you were to ask the same question for array-api-compat, or any actual implementation for that manner, I would say no, unless the standard ends up adopting some serious backwards incompatible changes in some future version. But there could be an argument for the strict implementation to have this.

Probably not surprising; in scipy/scipy#20172 I noticed what looks like a requirement for at least a small copy argument pass-through shim with NumPy main here because of (currently) a single test in SciPy. In that PR I was able to patch similar errors with fairly crude copy=None pass-through type shims, though in this library it may actually need to do something useful (the intended purpose) if the copy arg really needs to be respected I suppose.

============================================================================================ FAILURES =============================================================================================
______________________________________________________________________________ test_dispatch_to_unrecognize_library _______________________________________________________________________________
[gw22] linux -- Python 3.11.2 /home/treddy/python_venvs/py_311_scipy_dev/bin/python
scipy/special/tests/test_support_alternative_backends.py:25: in test_dispatch_to_unrecognize_library
    res = f(xp.asarray(x))
        f          = <function get_array_special_func.<locals>.f at 0x7f404756a2a0>
        x          = [1, 2, 3]
        xp         = <module 'array_api_strict' from '/home/treddy/python_venvs/py_311_scipy_dev/lib/python3.11/site-packages/array_api_strict/__init__.py'>
scipy/special/_support_alternative_backends.py:33: in f
    array_args = [np.asarray(arg) for arg in array_args]
        args       = (Array([1, 2, 3], dtype=array_api_strict.int64),)
        array_args = (Array([1, 2, 3], dtype=array_api_strict.int64),)
        f_scipy    = <ufunc 'ndtr'>
        kwargs     = {}
        n_array_args = 1
        other_args = ()
        xp         = <module 'array_api_strict' from '/home/treddy/python_venvs/py_311_scipy_dev/lib/python3.11/site-packages/array_api_strict/__init__.py'>
scipy/special/_support_alternative_backends.py:33: in <listcomp>
    array_args = [np.asarray(arg) for arg in array_args]
E   TypeError: Array.__array__() got an unexpected keyword argument 'copy'
        .0         = <tuple_iterator object at 0x7f4062090cd0>
        arg        = Array([1, 2, 3], dtype=array_api_strict.int64)
===================================================================================== short test summary info =====================================================================================
FAILED scipy/special/tests/test_support_alternative_backends.py::test_dispatch_to_unrecognize_library - TypeError: Array.__array__() got an unexpected keyword argument 'copy'

For example:

In [47]: import array_api_strict as xp

In [48]: x = xp.ones((2,2))

In [49]: list(iter(x))
Out[49]: []

I think this is because __getitem__ raises a IndexError

In [47]: import array_api_strict as xp

In [48]: x = xp.ones((2,2))

In [49]: list(iter(x))
Out[49]: []

In [50]: x.__getitem__(0)
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
Cell In[50], line 1
----> 1 x.__getitem__(0)

File ~/miniconda3/envs/scipy-dev-pytorch/lib/python3.11/site-packages/array_api_strict/_array_object.py:588, in Array.__getitem__(self, key)
    583 """
    584 Performs the operation __getitem__.
    585 """
    586 # Note: Only indices required by the spec are allowed. See the
    587 # docstring of _validate_index
--> 588 self._validate_index(key)
    589 if isinstance(key, Array):
    590     # Indexing self._array with array_api_strict arrays can be erroneous
    591     key = key._array

File ~/miniconda3/envs/scipy-dev-pytorch/lib/python3.11/site-packages/array_api_strict/_array_object.py:374, in Array._validate_index(self, key)
    370 elif n_ellipsis == 0:
    371     # Note boolean masks must be the sole index, which we check for
    372     # later on.
    373     if not key_has_mask and n_single_axes < self.ndim:
--> 374         raise IndexError(
    375             f"{self.ndim=}, but the multi-axes index only specifies "
    376             f"{n_single_axes} dimensions. If this was intentional, "
    377             "add a trailing ellipsis (...) which expands into as many "
    378             "slices (:) as necessary - this is what np.ndarray arrays "
    379             "implicitly do, but such flat indexing behaviour is not "
    380             "specified in the Array API."
    381         )
    383 if n_ellipsis == 0:
    384     indexed_shape = self.shape

IndexError: self.ndim=2, but the multi-axes index only specifies 1 dimensions. If this was intentional, add a trailing ellipsis (...) which expands into as many slices (:) as necessary - this is what np.ndarray arrays implicitly do, but such flat indexing behaviour is not specified in the Array API.

which is meant for out of bounds, instead I think we should be raising a TypeError.

This can be reproduced also in the following example

In [51]: class A:
    ...:     def __getitem__(self, key):
    ...:         raise IndexError
    ...:

In [52]: list(iter(A()))
Out[52]: []

Currently we support all the behaviors that require data dependent shapes (currently just the unique_* functions, nonzero, and boolean indexing).

It would be useful to have some sort of mode to disable these so people could test against libraries that don't have them.

Real documentation will be useful for array-api-strict, especially as we start to implement more features like #8. We can just copy the docs skeleton from array-api-compat.

This is a tracking issue for supporting 2023.12 in array-api-strict.

Here is a changelog for 2023.12 https://data-apis.org/array-api/latest/changelog.html#v2023-12

It would be helpful to have test suite support for the new features. This is especially true for any feature that isn't already implemented in NumPy. data-apis/array-api-tests#249

We'll also want to implement #8 as well so that we can continue to support 2022.12.