Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix #8477: Allow copies with different strides for 0-length data #8482

Merged
merged 3 commits into from Oct 11, 2022
Merged

Fix #8477: Allow copies with different strides for 0-length data #8482

merged 3 commits into from Oct 11, 2022

Commits on Oct 3, 2022

  1. Fix numba#8477: Allow copies with different strides for 0-length data 

    Since NumPy 1.23, it is possible for zero-length ndarrays to have
different strides (e.g. `(0,)`, and `(8,)`). If we attempt to copy from
a zero-length device array to a zero-length host array where the strides
differ, our compatibility check fails because it compares strides.

This commit fixes the issue by only considering strides when checking
compatibility of nonzero-length arrays. I believe this to be valid
because the following works normally with NumPy 1.23:

```python
import numpy as np

ary1 = np.arange(0)
ary2 = np.ndarray((0,), buffer=ary1.data)
ary3 = np.empty_like(ary2)

ary3[:] = ary2
ary3[...] = ary2
np.copyto(ary2, ary3)
```

i.e. copying zero-length arrays with different strides generally works
as expected.

The included test is written in such a way that it should test this
change in behaviour regardless of the installed NumPy version - we
explicitly construct zero-length device and host arrays with differing
strides. The additional sanity check ensures that the host array has the
strides we expect, just in case there is some version of NumPy in which
setting the strides explicitly didn't result in the expected strides - I
have observed that requesting nonzero strides for a zero length array
can result still in zero strides (a separate but related behaviour), so
this sanity check is provided to account for any other unexpected
behaviour of this nature. I have tested locally with NumPy 1.22 and 1.23
(pre- and post-changes to strides).

See also dask/distributed#7089 where a
workaround for an observation of this issue was needed. This would not
be needed with the fix in this commit.
    @gmarkall
    gmarkall committed Oct 3, 2022
    Configuration menu
    Copy the full SHA
    23c8934 View commit details
    Browse the repository at this point in the history

  2. CUDA: Test copies in all directions for numba#8477 fix

    @gmarkall
    gmarkall committed Oct 3, 2022
    Configuration menu
    Copy the full SHA
    a3716cd View commit details
    Browse the repository at this point in the history

  3. CUDA: Skip test for numba#8477 fix in cudasim

    @gmarkall
    gmarkall committed Oct 3, 2022
    Configuration menu
    Copy the full SHA
    9546e58 View commit details
    Browse the repository at this point in the history