[Numpy-discussion] Contiguity of result of astype changed - intentional?
Matthew Brett
matthew.brett@gmail....
Wed Sep 12 14:47:51 CDT 2012
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
More information about the NumPy-Discussion
mailing list