PR #42 had to stop early because we need Numba to let us recognize np.ndarray subclasses inside of a Numba-compiled function. This feature is being implemented, but it is not finished or in any released version of Numba yet: numba/numba#6148.
Override __getitem__ to return the appropriate VectorObject*DType when it would otherwise return a np.record.
(Presumably, @DrTodd13's implementation would ensure that other slices maintain their class. If not, include that in the __getitem__ override. Currently, a VectorNumpy loses its class—becoming a plain np.ndarray—when it is range-sliced; this will have to be tested.)
(It might also be necessary to override an array iterator.)
Override __array_ufunc__ for the relevant ufuncs (np.absolute, np.add, np.equal, etc.).
That's it! Not nearly as much work as vector.backends.numba_object.
PR #42 had to stop early because we need Numba to let us recognize
np.ndarray
subclasses inside of a Numba-compiled function. This feature is being implemented, but it is not finished or in any released version of Numba yet: numba/numba#6148.When that is done, we can follow the procedure described in https://github.com/numba/numba/pull/6148#issuecomment-676541700 to:
__getitem__
to return the appropriateVectorObject*DType
when it would otherwise return anp.record
.__getitem__
override. Currently, aVectorNumpy
loses its class—becoming a plainnp.ndarray
—when it is range-sliced; this will have to be tested.)__array_ufunc__
for the relevant ufuncs (np.absolute
,np.add
,np.equal
, etc.).That's it! Not nearly as much work as
vector.backends.numba_object
.