Should we perform this test with the default floating type ie

?

I'm happy with either, personally. I think there is value in doing some or most tests with default floating point type, but there is also some value in testing with non-default types. If that happens naturally by convenience in some tests, great.

I'm only forcing the dtype of expected. For default torch input (float32), directional_stats returns float64. Is that okay?

Same thing for the next test function.

Is that because of data-apis/array-api-compat#152? If not, what is converting it? vector_norm?

For default torch input (float32), directional_stats returns float64. Is that okay?

I don't think so. I think it's just NumPy that converts to float64, and that's because of data-apis/array-api-compat#152 (and sum is used). For torch, the dtype is preserved as it should be, yet even if it is float32, repr(f"{res.mean_resultant_length}") prints lots of digits!

from array_api_compat import torch
from array_api_compat import numpy as np
from scipy import stats
rng = np.random.default_rng(2549824598234528)
x = np.astype(rng.random((3, 10)), np.float32)
y = torch.asarray(x)
assert y.dtype == torch.float32
res = stats.directional_stats(y)
assert res.mean_direction.dtype == torch.float32
assert res.mean_resultant_length.dtype == torch.float32
print(f"{res.mean_resultant_length}")
# 0.941432774066925

I guess that makes sense if Python converts it to a float before printing. I don't think I've noticed that before, though; it's uncommon for the result class to have __repr__ defined explicitly.

I said before that it's OK to let sum do its thing (return np.float64 with np.float32 input), but the problem is that it will change when data-apis/array-api-compat#152 is resolved. Might be better to explicitly provide the dtype to sum so it doesn't change later.

What should we change. then? I assume you are referring to xp.sum being called within our call to xp.mean? We don't call xp.sum directly for PyTorch or NumPy as it uses xp.linalg.

Well, then, not even NumPy converts to float64. You wrote that "For default torch input (float32), directional_stats returns float64. Is that okay?" and I was trying to explain why that might be the case, but it doesn't look like that happens. I guess I didn't actually test for NumPy before, but it doesn't seem to happpen for NumPy either because - as you say - NumPy skips sum, so data-apis/array-api-compat#152 doesn't come up.

I think you only have to force the dtype of expected because data starts out as a float64 array, so Torch's input is a float64 tensor. If we use xp.asarray instead of np.array, it should work without specifying the dtype.

I'm happy with either, personally. I think there is value in doing some or most tests with default floating point type, but there is also some value in testing with non-default types. If that happens naturally by convenience in some tests, great.

I'm only forcing the dtype of expected. For default torch input (float32), directional_stats returns float64. Is that okay?

Same thing for the next test function.

I don't quite fully understand this. If SCIPY_ARRAY_API=0 then xp.sum(xp.conj(x) * x, axis=axis, keepdims=keepdims)**0.5 is always used which doesn't seem preferable compared to np.linalg.norm?

Right, I think I should rework the logic to

if SCIPY_ARRAY_API:
    if hasattr(xp, linalg):
        ...
    else:
        ...
else:
    # use np.linalg.norm

this should be fixed now