[Numpy-discussion] Memory order of array copies

[Frédéric Bastien]

As always, I think it is better to don't change the default behaviour.
There is many people that don't update frequently and 2 releases is
not enough. This will lead to many hard to find bug. This will also
give the impression what we can't rely on numpy default behaviour and
numpy is not stable.

As a rule of thumb, we need to compare the benefit and consequence of
changing default behaviour. In this case I see only a marginal speed
gain (marginal in the sense that in the global user script, this won't
matter, but locally it could be significant) vs silent and hard to
find bug. If speed in that case is important, i think it would be much
better to write an optimizer version that will take stride and cache
line length into account. Even if we hard code the cache line lenght,
this will probably bring most of the local speed up, without the
inconvenient.

If people still want to do this change, I think only a big release
like numpy 2.0 make this acceptable but with the warning as Gael told.
But I still prefer it not done and if people matter about the speed,
they can write optimized code.

Fred

On Sun, Sep 30, 2012 at 2:22 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 30, 2012 at 07:17:42PM +0100, Nathaniel Smith wrote:
>> Is there anything better to do than simply revert np.copy() to its
>> traditional behaviour and accept that np.copy(a) and a.copy() will
>> continue to have different semantics indefinitely?
>
> Have np.copy take an 'order=None', which would translate to 'K'. Detect
> 'None' as a sentinel that order as not been specified. If the order is
> not specified, raise a FutureWarning that np.copy will change semantics
> in 2 releases. In two releases, do the change.
>
> That's how I would deal with it.
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion