Contiguity of result of astype changed - intentional?
Hi, We hit a subtle behavior change for the ``astype`` array method between 1.6.1 and 1.7.0 beta. In 1.6.1: In [18]: a = np.arange(24).reshape((2, 3, 4)).transpose((1, 2, 0)) In [19]: a.flags Out[19]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [20]: b = a.astype(float) In [21]: b.flags Out[21]: C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [22]: b.strides Out[22]: (64, 16, 8) So - ``a.astype(float)`` here has made a new C-contiguous array, somewhat as implied by the 'copy' explanation in the docstring. In 1.7.0 beta, ``a`` is the same but: In [22]: b.flags Out[22]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [23]: b.strides Out[23]: (32, 8, 96) Is this intended? Is there a performance reason to keep the same strides in 1.7.0? Thanks for any pointers, Matthew
On Sep 12, 2012, at 1:36 PM, Matthew Brett wrote:
Hi,
We hit a subtle behavior change for the ``astype`` array method between 1.6.1 and 1.7.0 beta.
In 1.6.1:
In [18]: a = np.arange(24).reshape((2, 3, 4)).transpose((1, 2, 0))
In [19]: a.flags Out[19]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
In [20]: b = a.astype(float)
In [21]: b.flags Out[21]: C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
In [22]: b.strides Out[22]: (64, 16, 8)
So - ``a.astype(float)`` here has made a new C-contiguous array, somewhat as implied by the 'copy' explanation in the docstring. In 1.7.0 beta, ``a`` is the same but:
In [22]: b.flags Out[22]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
In [23]: b.strides Out[23]: (32, 8, 96)
Is this intended? Is there a performance reason to keep the same strides in 1.7.0?
I believe that this could be because in 1.7.0, NumPy was changed so that copying does not always default to "C-order" but to "Keep-order". So, in 1.7.0, the strides of b is governed by the strides of a, while in 1.6.1, the strides of b is C-order (because of the copy). -Travis
Hi, On Wed, Sep 12, 2012 at 7:58 PM, Travis Oliphant <travis@continuum.io> wrote:
On Sep 12, 2012, at 1:36 PM, Matthew Brett wrote:
Hi,
We hit a subtle behavior change for the ``astype`` array method between 1.6.1 and 1.7.0 beta.
In 1.6.1:
In [18]: a = np.arange(24).reshape((2, 3, 4)).transpose((1, 2, 0))
In [19]: a.flags Out[19]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
In [20]: b = a.astype(float)
In [21]: b.flags Out[21]: C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
In [22]: b.strides Out[22]: (64, 16, 8)
So - ``a.astype(float)`` here has made a new C-contiguous array, somewhat as implied by the 'copy' explanation in the docstring. In 1.7.0 beta, ``a`` is the same but:
In [22]: b.flags Out[22]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
In [23]: b.strides Out[23]: (32, 8, 96)
Is this intended? Is there a performance reason to keep the same strides in 1.7.0?
I believe that this could be because in 1.7.0, NumPy was changed so that copying does not always default to "C-order" but to "Keep-order". So, in 1.7.0, the strides of b is governed by the strides of a, while in 1.6.1, the strides of b is C-order (because of the copy).
Thanks for the reply. So maybe the bottom line is that the user should not assume any contiguity from ``astype``? If that's the case I'll submit a docstring PR to say that. Cheers, Matthew
Is this intended? Is there a performance reason to keep the same strides in 1.7.0?
I believe that this could be because in 1.7.0, NumPy was changed so that copying does not always default to "C-order" but to "Keep-order". So, in 1.7.0, the strides of b is governed by the strides of a, while in 1.6.1, the strides of b is C-order (because of the copy).
Thanks for the reply.
So maybe the bottom line is that the user should not assume any contiguity from ``astype``? If that's the case I'll submit a docstring PR to say that.
Yes, that would be a great addition to the docstring. Mark, can you confirm this is the desired behavior? Ondrej, this would be something to put in the release notes, if it isn't already. Thanks, -Trvis
Hi Matt, On Wed, Sep 12, 2012 at 1:27 PM, Travis Oliphant <travis@continuum.io> wrote:
Is this intended? Is there a performance reason to keep the same strides in 1.7.0?
I believe that this could be because in 1.7.0, NumPy was changed so that copying does not always default to "C-order" but to "Keep-order". So, in 1.7.0, the strides of b is governed by the strides of a, while in 1.6.1, the strides of b is C-order (because of the copy).
Thanks for the reply.
So maybe the bottom line is that the user should not assume any contiguity from ``astype``? If that's the case I'll submit a docstring PR to say that.
Yes, that would be a great addition to the docstring. Mark, can you confirm this is the desired behavior? Ondrej, this would be something to put in the release notes, if it isn't already.
If you could submit the PR with the docs, that'd be awesome. In the meantime, I've created an issue for it: https://github.com/numpy/numpy/issues/437 and put it into my TODO list: https://github.com/numpy/numpy/issues/396 Ondrej
Hi, On Wed, Sep 12, 2012 at 10:24 PM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
Hi Matt,
On Wed, Sep 12, 2012 at 1:27 PM, Travis Oliphant <travis@continuum.io> wrote:
Is this intended? Is there a performance reason to keep the same strides in 1.7.0?
I believe that this could be because in 1.7.0, NumPy was changed so that copying does not always default to "C-order" but to "Keep-order". So, in 1.7.0, the strides of b is governed by the strides of a, while in 1.6.1, the strides of b is C-order (because of the copy).
Thanks for the reply.
So maybe the bottom line is that the user should not assume any contiguity from ``astype``? If that's the case I'll submit a docstring PR to say that.
Yes, that would be a great addition to the docstring. Mark, can you confirm this is the desired behavior? Ondrej, this would be something to put in the release notes, if it isn't already.
If you could submit the PR with the docs, that'd be awesome. In the meantime, I've created an issue for it:
https://github.com/numpy/numpy/issues/437
and put it into my TODO list:
Sorry - inadequate research on my part - the current docstring for ``astype`` is clear and comprehensive, and the change was obviously intentional. Cheers, Matthew
participants (3)
-
Matthew Brett -
Ondřej Čertík -
Travis Oliphant