ENH: support CuPy to_device "cpu"

[tylerjereddy]

• allow to_device(x, "cpu") for CuPy--this makes it easier to write portable unit tests where the
  expected value is on the host (a NumPy array)

• otherwise, you can end up writing different shims in downstream libraries to move the array-like back to the host (.get() for CuPy...); if CuPy conforms to the standard, we shouldn't need this shim long-term

[asmeurer]

Looks fine to me, although this might also be something to request upstream from cupy.

[asmeurer]

if CuPy conforms to the standard, we shouldn't need this shim long-term

The standard doesn't say anything about how devices are specified https://data-apis.org/array-api/latest/design_topics/device_support.html#syntax-for-device-assignment. The "cpu" device for NumPy was just a convention that was chosen, probably based off pytorch. Maybe the standard should specify that "cpu" == host? It could be worth opening an issue about. I'm not sure what has already been discussed here.

[asmeurer]

CuPy won't be tested until I test it manually. I'll be sure to do that before making another release.

[tylerjereddy]

For the record I did test on CuPy (and Torch) locally with a 1080 Ti and passed for me.

[asmeurer]

I'm actually a little unsure about this thinking about it. If you transfer a CuPy array to NumPy, you change what namespace it uses. That's different from PyTorch where CPU and GPU tensors both use the torch namespace.

[tylerjereddy]

Good point, I shared that in the cross-linked array API standard issue. That said, at least for my use case, I didn't care so much about staying in the same array namespace as being able to have the memory usable directly in assert_allclose(). The fact that different array libraries have such drastically different semantics in moving data between device and host probably further underlines the need for a portable shim of some sort? Unless you really want each lib to write its own shims for this.

[asmeurer]

Well you would need to make sure to recall array_namespace after calling to_device.

My feeling is that this goes against some of the design decisions of the standard (see https://data-apis.org/array-api/latest/purpose_and_scope.html and https://data-apis.org/array-api/latest/design_topics/data_interchange.html). But device stuff isn't really my wheelhouse so hopefully other folks will weigh in on the issue or at the consortium meeting.