[Numpy-discussion] Contiguity of result of astype changed - intentional?
Travis Oliphant
travis@continuum...
Wed Sep 12 13:58:49 CDT 2012
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
More information about the NumPy-Discussion
mailing list