fix: don't touch for ascontiguousarray
#2397
Conversation
This is because touching should really only occur if the operation result _depends_ upon the array value, which it does not in this instance.
There was a problem hiding this comment.
We talked about this in our meeting, and the key point is
The plan is to remove (1) later, once
dask-awkwardpasses in its own special content types.
I'm not comfortable using an under-documented NumPy feature (np.dtype.metadata), particularly since pretend_contiguous is a statement about its shape and strides (everything but the dtype). However, the dtype follows the array, so it's expedient to do it this way for now.
This will go into the next release.
|
What do we need to do over in dask awkward to make it function as expected? I'm not sure if we've actually hit this one yet, given that the other PR fixed the issue I was running into with Yi-Mu. |
|
We'll be able to avoid relying on The current method of rehydrating with zero-strided (but otherwise real NumPy) arrays doesn't do that. What I'm addressing here is a preferred refactoring; I don't know if you were asking about something more fundamental, like why this PR exists at all. |
|
Oh I was trying to understand what additional PRs would be needed in dask-awkward before minting another release, and it sounds like None until we run into this problem there. |
Codecov Report
Additional details and impacted files
|
This is because touching should really only occur if the operation result depends upon the array value, which it does not in this instance.
This PR
dask-awkwardto setpretend_contiguouson thendarray.dtypefor our "fake" buffers, ensuring that nplikes do not force them to become contiguous.ascontiguousarrayThe plan is to remove (1) later, once
dask-awkwardpasses in its own special content types.