TST: add test that wrapping preserves view/copy semantics

[ev-br]

If a bare library returns a copy, so does the wrapped library; if the bare library returns a view, so does the wrapped library.
Unary functions only for now.

cross-ref gh-331

[ev-br]

Okay, CI is green now across numpy from 1.22 to -dev. Will likely merge gh-334 first to separate the CI tweaks from -compat tweaks (currently, this PR contains both).

[ev-br]

What were other "unpleasantly surprising" cases, if you happen to remember @crusaderky ?

[crusaderky]

What were other "unpleasantly surprising" cases, if you happen to remember @crusaderky ?

there's the table at #331 (comment); there's sum(axis=0), and probably quite a few more. I didn't do a thorough review of all array API functions but I do expect many edge cases where it is possible (and, very arguably, reasonable) to return a view.

[ev-br]

Views are not a problem per se; returning a view when a bare library returns a copy is.
Regarding the sum example, I actually don't see how sum(x, axis=0) can ever return a view into x. Mind expanding?

[crusaderky]

Regarding the sum example, I actually don't see how sum(x, axis=0) can ever return a view into x. Mind expanding?

sum, prod, mean, and possibly a few more reductions could return a view when all reduced axes have size 1.

[ev-br]

sum, prod, mean, and possibly a few more reductions could return a view when all reduced axes have size 1.

Cannot repro, what am I missing?

In [1]: import numpy as np

In [2]: a = np.asarray([[1, 2, 3]])

In [3]: from array_api_compat import array_namespace

In [4]: xp = array_namespace(a)

In [5]: b = xp.sum(a, axis=0)

In [6]: b
Out[6]: array([1, 2, 3])

In [7]: np.shares_memory(a, b)
Out[7]: False

In [8]: b[0] = 42

In [9]: b
Out[9]: array([42,  2,  3])

In [10]: a
Out[10]: array([[1, 2, 3]])

[crusaderky]

These functions could return a view. They don't return a view in NumPy. I did not test the other backends wrapped by array-api-compat.

[ev-br]

Thanks for the clarification! So it's a theoretical concern at this point.

IMO the reasonable thing to declare is #331 (comment)
And this position is what this PR tests for, at least partially.

[crusaderky]

This leads to loss of precision for very large ints.

[ev-br]

Indeed, thanks. Reworked to avoid round-tripping int->float->int.

[crusaderky]

Just a cosmetic nit

[crusaderky]

int arguments are outside of the scope of the Array API.
So I'm not sure this should be here at all?

For numpy is a bit more nuanced - on one hand it makes sense to unify numpy 1.x behaviour to match 2.x.
On the other hand it's a array-api-compat tweak specifically to cover a change in behaviour that is already outside of the Array API.

[ev-br]

I think it's just backwards compat. On main, all backends try to return integers for integer inputs (via common/_aliases.py), so this PR tries to preserve that, while fixing the views/copies issue.