MIPS2.sol MT-FPVM Implementation

[Inphi]

Description

Currently, if you do

cupy_array[some_iterable]

CuPy will interrogate some_iterable to see if it implements __array_struct__, __array_interface__, __array__ (in that order) before concluding that some_iterable is not an array and proceed to iterate over it as a Python object.

The Interoperability documentation says that CuPy produces (for Numba) and consumes (from PyTorch) the __cuda_array_interface__ protocol, as well as DLPack. But if some_iterable produces either or both of these protocols, CuPy does not check.

Should it? Is this a feature request or a bug report?

Additional Information

No response

[kmaehashi]

Thanks for the feedback! This feature request looks legit to me for the __cuda_array_interface__ but would like to check how other libraries are handling it, just in case I'm missing something.

As for the DLPack, explicitly using from_dlpack is the standard way of importing foreign arrays, so cupy_array[cupy.from_dlpack(xxx)] is the expected usage.

[seberg]

This seems to go down to cp.asarray([obj, obj]) failing (i.e. cupy currently accepts anything as an index)

import cupy as cp

class test:
    a = cp.arange(10)
    @property
    def __cuda_array_interface__(self):
        return self.a.__cuda_array_interface__
    def __array__(self):
        print("converting via numpy")
        return self.a.get()

cp.asarray(test())  # via interface (prints nothing_
cp.asarray([test()])  # prints: converting via numpy

This can be fixed by checking for __cuda_array_interface__ in _compute_concat_info_impl and getting the shape and dtype directly from it. Caveat: If there is real work happening when feetching __cuda_array_interface__ that would happen twice.

@jpivarski this also means there is a work-around available, though: You can add __cupy_get_ndarray__ which is supported here. You do have to have valid .shape and .dtype defined though.

[seberg]

Going to close this since I forgot to tag the PR.

Nested CAI will now be supported (v14); i.e. nesting an object should be supported if it is supported by cupy.asarray(), I think. But since cupy.asarray() doesn't accept __dlpack__ neither will it accept nested ones of course (just like everyone else at this point for __dlpack__, though).

So if you want to argue for implicit dlpack conversion in asarray() (or nesting) then we should open a new ~version~ issue (and possibly broaden up the discussion).