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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
