ENH: Have dtype transfer for equivalent user dtypes prefer user-defined `copyswapn` #10898
This is a simple way that initially enables things like exposing autodiff scalars with heap-allocated derivatives. See the original issue for more info.
This Travis build job shows the code working with this patch (well, an older version of it):
\cc @njsmith - Since this is a relatively small change, figured I'd see if this appropriate to upstream at this point.
Hmm... My understanding, from having looked at some of the NumPy v1.11.0 source (what I'm using on Ubuntu), is that
Will still try it out on my test case to see if it works out, and post the results here. Thanks!
EDIT: Checked against v1.11.0 (unpatched) from system, and it works for
EDIT 2: Confirmed that
If these inconsistencies were fixed, then
That also being said, if there is a hook to cause
EDIT 3: I may risk the segfaults with
Looking again - seems you're right,
So maybe this is the best call. I worry that there will be a lot of places that just assume they can memcpy a user dtype though, so this will be the first of many changes you need to make.
Why is it that a memcpy doesn't work for you?
Ah, gotcha. For the most part, though, it seems that the main algorithms do well in using the correct dispatches to copy arrays. Though I'm sure I'll run into that issue at some point. It'll be an interesting adventure, then :P
In this case,
EDIT: This may be jumping the design gun, but in the future, could
This was referenced
Apr 14, 2018
Just checking back in on this PR - may I ask if there's anything I may do to increase confidence in its change to see if it can be merged into
Perhaps instrument some user-defined dtype test to check which user-defined methods have been called?
I think this is probably fine as it. The change is pretty straightforward, and I assume your code works with it.
There's a slight performance penalty here for custom dtypes, but I imagine it's pretty minor - those users can presumably just call
If no one else has any opinions on this, I'll merge it in a few days. Tagging with 1.15 so I don't forget.
One concern is it looks like
EDIT: Er, just to clarify, I don't think this PR should be blocked on account of a convenience method being user-accessible; for the time being, it seems like it's more-or-less trivial to write a non-swap version of
referenced this pull request
May 11, 2018
My point is that
Can you perhaps add something to the release notes about this change?