Hi, On Wed, Sep 12, 2012 at 7:58 PM, Travis Oliphant <tra...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion