I'm starting to see multiple Array API compliant libraries that are just thin wrappers around another arbitrary Array API compliant library:
- @mdhaber's marray
- @lucascolley's quantity-array
- I'm deliberately keeping Dask out of scope for this issue, as there is a lot of nuance involved in it.
- xarray's wrapping design also predates the Array API and xarray is not (today) Array API compatible, but I can see it joining the fray soon.
These libraries currently fail to work with array-api-compat, array-api-extra, or anything that relies on them (like scipy) except in the most basic use cases, e.g. wrapping around a writeable numpy or cupy array.
These are the reasons I could find so far:
array_api_compat.is_writeable_array blindly returns True for unknown namespaces. This is problematic also when wrapping around read-only numpy arrays.
array_api_compat.is_lazy_array incorrectly returns False for wrapped Dask. This will lead to major performance issues.
xpx.at, xpx.apply_where, and xpx.lazy_apply have special casing for Dask which won't be triggered when Dask is wrapped. You can't just change array_api_compat.is_dask_array to return True for wrapped dask objects, because there are a wealth of dask-specific calls (da.map_blocks, passing the arrays to a @delayed function) that won't work out of the box.
- The same functions, plus
nunique, have special casing for JAX. Again, there are jax-specific function calls e.g. jax.pure_callback that won't accept wrapped arrays.
- Delegated functions (
xpx.pad) should work thanks to their generic code path, but they are untested; so for example pad on PyTorch works due to special casing, but there are no tests that verify that the generic implementation of pad applied to a wrapper around PyTorch will work.
I'm starting to see multiple Array API compliant libraries that are just thin wrappers around another arbitrary Array API compliant library:
These libraries currently fail to work with
array-api-compat,array-api-extra, or anything that relies on them (like scipy) except in the most basic use cases, e.g. wrapping around a writeable numpy or cupy array.These are the reasons I could find so far:
array_api_compat.is_writeable_arrayblindly returns True for unknown namespaces. This is problematic also when wrapping around read-only numpy arrays.array_api_compat.is_lazy_arrayincorrectly returns False for wrapped Dask. This will lead to major performance issues.xpx.at,xpx.apply_where, andxpx.lazy_applyhave special casing for Dask which won't be triggered when Dask is wrapped. You can't just changearray_api_compat.is_dask_arrayto return True for wrapped dask objects, because there are a wealth of dask-specific calls (da.map_blocks, passing the arrays to a@delayedfunction) that won't work out of the box.nunique, have special casing for JAX. Again, there are jax-specific function calls e.g.jax.pure_callbackthat won't accept wrapped arrays.xpx.pad) should work thanks to their generic code path, but they are untested; so for examplepadon PyTorch works due to special casing, but there are no tests that verify that the generic implementation ofpadapplied to a wrapper around PyTorch will work.