The problem is
@given(
x=hh.arrays(dtype=hh.all_dtypes, shape=hh.shapes(min_dims=1, max_side=2)),
copy_kw=hh.kwargs(copy=st.booleans()),
data=st.data()
)
def test_from_dlpack(x, copy_kw, data):
....
tgt_device_kw = data.draw(
hh.kwargs(device=st.sampled_from(devices) | st.none())
)
...
y = xp.from_dlpack(x, **tgt_device_kw, **copy_kw)
...
if x.dtype == float64, and the target device does not support float64 (mps of pytorch or array-api-strict's Device("no_float64")), the from_dlpack call fails as it should: you cannot transfer the x array on a device which does not support it.
The key problem is that dtype=hh.all_dtypes generates all dtypes with no regard to whether the result is supported by the device or not. Attempting to filter unsupported dtype/device pairs after the fact, via assume or otherwise, generates a hypothesis strategy filters too much error.
The specific error in this specific test can be worked around yes; the problem is bound to become systemic when we start testing devices more broadly, in all creation functions (cf gh-302). A structural fix probably requires a dedicated strategy to only generate supported dtype/device pairs.
The problem is
if
x.dtype == float64, and the target device does not supportfloat64(mpsof pytorch or array-api-strict'sDevice("no_float64")), thefrom_dlpackcall fails as it should: you cannot transfer thexarray on a device which does not support it.The key problem is that
dtype=hh.all_dtypesgenerates all dtypes with no regard to whether the result is supported by the device or not. Attempting to filter unsupported dtype/device pairs after the fact, viaassumeor otherwise, generates a hypothesis strategy filters too much error.The specific error in this specific test can be worked around yes; the problem is bound to become systemic when we start testing devices more broadly, in all creation functions (cf gh-302). A structural fix probably requires a dedicated strategy to only generate supported dtype/device pairs.