TST: array types: wrap namespaces centrally

[crusaderky]

Prevent headaches such as https://github.com/scipy/scipy/pull/22240/files#r1913475509

[mdhaber]

I had assumed the purpose of using un-wrapped namespaces in the tests was for the tests to better reflect the conditions in practice, assuming end-users do not use array_api_compat.

That said, since array_api_compat does not wrap array objects themselves (IIRC), it seems that the SciPy function being tested will behave the same way whether the arrays were generated using a wrapped or unwrapped namespace.

From that perspective, providing a wrapped xp to the unit tests really shouldn't affect the results , and it would make writing the tests more convenient. So if that's right, seems good to me.

[crusaderky]

That said, since array_api_compat does not wrap array objects themselves (IIRC)

Correct.

I don't know if the SciPy function being tested will behave any differently whether the array arguments were generated using a wrapped or unwrapped namespace.

Unless a user-facing function accepts xp as an optional parameter and the test explicitly passes xp=xp to it, it can't behave any different. I haven't witnessed this specific condition throughout the scipy codebase.
Another edge case would be for a scipy function to accept a callback that points back into the namespace.

[mdhaber]

Unless a user-facing function accepts xp as an optional parameter

I am not aware of any.
So +1 for the idea.

[lucascolley]

I think this works, yes. I suppose if array-api-compat ever did modify the array objects then we would have problems.

Unless a user-facing function accepts xp as an optional parameter

https://docs.scipy.org/doc/scipy/reference/generated/scipy.fft.fftfreq.html

[crusaderky]

I think this works, yes. I suppose if array-api-compat ever did modify the array objects then we would have problems.

Unless a user-facing function accepts xp as an optional parameter

https://docs.scipy.org/doc/scipy/reference/generated/scipy.fft.fftfreq.html

You also need a test that explicitly passes the unwrapped xp, otherwise it will default internally to array_namespace(args)

[crusaderky]

This fails in CI PyTorch, stating that res.nit has 3 unique elements. Can't reproduce locally.
https://github.com/scipy/scipy/actions/runs/12767945483/job/35587336176?pr=22320

To me it seems like a genuine bug but I don't have enough domain knowledge to understand what's right and wrong. @mdhaber could you have a look?

[mdhaber]

Not a bug. I'll fix the test in a bit . You can skip that line if it's holding you up.

[crusaderky]

skipped, ty

[mdhaber]

Looking more carefully, this part of the test was NumPy-only before the PR:

scipy/scipy/differentiate/tests/test_differentiate.py

Lines 589 to 591 in df134ea

	if is_numpy(xp):
	assert len(np.unique(res.nit)) == 4
	assert len(np.unique(res.nfev)) == 4

The purpose is to check that it's possible for all four numbers to be different. It was challenging to find an example for which that was the case, and it turned out to be sensitive to arithmetic, so we made it NumPy only.

It must have started failing only because the if is_numpy line was removed?

[crusaderky]

It must have started failing only because the if is_numpy line was removed?

Correct. I find surprising that different backends can yield different results.

[crusaderky]

Ready for review.
See comment above about the CI failure.

[lucascolley]

thanks @crusaderky, very nice clean-up