User-defined dtype: np.copy always uses memcopy / memset, rather than copyswapn
#10897
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
It seems odd to me that for a user-defined dtype, you must specify
copyswap(which can be used to provide a default implementation ofcopyswapn), but the default behavior ofnp.copy(PyArray_GetDTypeTransferFunction) will end up providing a transfer method that usesmemmove/memcpy.This creates an issue when implementing dtypes that owns data which is heap-allocated, e.g. variable-size autodiff scalars.
It'd be nice if the default behavior were to leverage the user-defined
copyswapn; while it would impact performance for user dtypes by default, authors could always make the implementation use something akin to whatPyArray_GetStridedCopyFnreturns.Relates #10721: That issue, however, does not impact functionality per se, but more of performance since it creates memory leak. This issue, however, is a blocker for implementing these types of dtypes.
I was able to implement almost all of the features I need to make it possible to expose
Eigen::AutoDiffScalar<Eigen::VectorXd>as a scalar type usingpybind11in C++; I believe this is the only main blocker for the functionality:RobotLocomotion/drake#8452
RobotLocomotion/pybind11#12
The text was updated successfully, but these errors were encountered: