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
I think preserving the dtype (if it is supported on the target device) is what should happen (aka behaviour of v2.5). I think the default dtype is something to look at for functions like ones() and friends. For those there is no hint from the user what the type should be.
A fix could be to use:
# numpy default dtype may differ; if so, adjust the dtype.# Only do this for inputs whose dtype was inferred by NumPy (Python# scalars / sequences). Inputs that carry their own dtype (arrays and# buffer-protocol objects) must have that dtype preserved.ifdtypeisNoneanddeviceisnotNoneandnot_supports_buffer_protocol(obj):
res_dtype=DType(res.dtype)
Grr. _supports_buffer_protocol won't suffice, sadly, because torch does not support it, even on CPU.
In [1]: import array_api_strict as xp
In [2]: xp.__version__
Out[2]: '2.5'
In [3]: import torch
In [4]: xp._creation_functions._supports_buffer_protocol(torch.ones(3)) # oops
Out[4]: False
In [5]: xp.asarray(torch.ones(3))
Out[5]: Array([1., 1., 1.], dtype=array_api_strict.float32)
In [6]: torch.ones(3).device
Out[6]: device(type='cpu')
Special-casing np.ndarray won't do either as a bugfix because In[5] above: xp.asarray(torch.ones(3)) succeeds in 2.5.
ATM the only way around I see is to branch on hasattr(obj, "dtype"). Any better ideas?
Unless of course, we declare the 2.5 behavior a bug and declare that array-api-strict does not really support xp.asarray from alternative array libraries?
Unless of course, we declare the 2.5 behavior a bug and declare that array-api-strict does not really support xp.asarray from alternative array libraries?
If it is indeed the case that PyTorch does not support the buffer protocol (is memoryview(obj) the correct test for that?), then yes, it seems better for array-api-strict to not support whatever makes np.asarray work (that is presumably absent from the spec).
Here's what I believe is a backwards compatible fix: #223
Please do review / test / poke holes in it!
If it is indeed the case that PyTorch does not support the buffer protocol (is memoryview(obj) the correct test for that?), then yes, it seems better for array-api-strict to not support whatever makes np.asarray work (that is presumably absent from the spec).
I believe that yes and yes (pytorch does not support buffer protocol, and memoryview is the appropriate check for it).
That said, let's maybe consider making array-api-strict stricter in a regular release (and consider this together with __array__). Meanwhile I think gating the dtype adjustment dance on obj.dtype is makes it backwards compatible: we first call np.array(obj), that either succeeded or failed. If it failed, there's no change in 2.6 or here; if it succeeded, then two options: obj is a python object (then we adjust the dtype) or it's an array (and then numpy did the work already and res.dtype matches obj.dtype).
Activity
lucascolley commentedon Jul 10, 2026
Or perhaps more simply — mimicking the existing:
we could have
betatim commentedon Jul 10, 2026
I think we need
_supports_buffer_protocol(obj)to catch other inputs that have a dtype attached, like numpy scalars or torch arrays (on the CPU).ev-br commentedon Jul 10, 2026
Grr.
_supports_buffer_protocolwon't suffice, sadly, becausetorchdoes not support it, even on CPU.ev-br commentedon Jul 10, 2026
Special-casing
np.ndarraywon't do either as a bugfix becauseIn[5]above:xp.asarray(torch.ones(3))succeeds in 2.5.ATM the only way around I see is to branch on
hasattr(obj, "dtype"). Any better ideas?Unless of course, we declare the 2.5 behavior a bug and declare that
array-api-strictdoes not really supportxp.asarrayfrom alternative array libraries?lucascolley commentedon Jul 10, 2026
If it is indeed the case that PyTorch does not support the buffer protocol (is
memoryview(obj)the correct test for that?), then yes, it seems better for array-api-strict to not support whatever makesnp.asarraywork (that is presumably absent from the spec).ev-br commentedon Jul 10, 2026
Here's what I believe is a backwards compatible fix: #223
Please do review / test / poke holes in it!
I believe that yes and yes (pytorch does not support buffer protocol, and memoryview is the appropriate check for it).
That said, let's maybe consider making
array-api-strictstricter in a regular release (and consider this together with__array__). Meanwhile I think gating the dtype adjustment dance onobj.dtypeis makes it backwards compatible: we first callnp.array(obj), that either succeeded or failed. If it failed, there's no change in 2.6 or here; if it succeeded, then two options:objis a python object (then we adjust the dtype) or it's an array (and then numpy did the work already andres.dtypematchesobj.dtype).MAINT: adapt to array-api-strict 2.6 per-device dtype semantics
ENH: improve device handling more, add pytorch meta device testing (#…