[Numpy-discussion] Change in behavior of np.concatenate for upcoming release
Hi, I just noticed that this works for numpy 1.6.1: In [36]: np.concatenate(([2, 3], [1]), 1) Out[36]: array([2, 3, 1]) but the beta release branch: In [3]: np.concatenate(([2, 3], [1]), 1) --- IndexErrorTraceback (most recent call last) /Users/mb312/ipython-input-3-0fa244c8aaa8 in module() 1 np.concatenate(([2, 3], [1]), 1) IndexError: axis 1 out of bounds [0, 1) In the interests of backward compatibility maybe it would be better to raise a warning for this release, rather than an error? Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Change in behavior of np.concatenate for upcoming release
On Wed, Sep 12, 2012 at 2:46 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, I just noticed that this works for numpy 1.6.1: In [36]: np.concatenate(([2, 3], [1]), 1) Out[36]: array([2, 3, 1]) but the beta release branch: In [3]: np.concatenate(([2, 3], [1]), 1) --- IndexErrorTraceback (most recent call last) /Users/mb312/ipython-input-3-0fa244c8aaa8 in module() 1 np.concatenate(([2, 3], [1]), 1) IndexError: axis 1 out of bounds [0, 1) In the interests of backward compatibility maybe it would be better to raise a warning for this release, rather than an error? Yep, that'd be a good idea. Want to write a patch? :-) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Contiguity of result of astype changed - intentional?
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
Re: [Numpy-discussion] Contiguity of result of astype changed - intentional?
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Contiguity of result of astype changed - intentional?
Hi Matt, On Wed, Sep 12, 2012 at 1:27 PM, Travis Oliphant tra...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
