[Numpy-discussion] Ill-defined in-place operations (#1085)

[josef.pktd at gmail.com]

On Wed, Apr 15, 2009 at 5:39 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Wed, Apr 15, 2009 at 2:51 PM, Pauli Virtanen <pav at iki.fi> wrote:
>>
>> Wed, 15 Apr 2009 22:34:49 +0200, Matthieu Brucher wrote:
>>
>> > I think this is unavoidable. If we state clearly that every numpy
>> > function assums non-pointer aliasing, then people have to care about
>> > this themselves (like they would in Fortran, or in C++ for object-like
>> > arrays).
>>
>> Nevertheless, this is an easy way to shoot yourself into foot. Also, (as
>> indicated by the x.T example), it's doubtful anyone actually relies on
>> the current behavior for N-D arrays, since it depends on order of data in
>> memory, etc.
>>
>> It rather likely is possible to cheaply detect potentially troublesome
>> cases and raise a warning. (The user can silence these, if the behavior
>> is really relied on.) I don't know what is the performance impact of
>> Python warnings, though.
>>
>> The alternative is to have really good documentation on views...
>
> Asking the average user to understand memory issues is probably a bit much.
> Better to raise a warning and let the sophisticated users override it if
> they really need to. Checking if the same memory chunk is used should be
> sufficient (I think that can be done).
>

It is also often difficult to figure out if an operation creates a
view or a copy, and it would be safer to at least get a warning. The
more convenient solution for users like me, would be to do also a copy
in those cases where the operation is "inconsistent" with the view.

Since I realized that there is this type of problem, I started to add
more .copy() to my calculations.

Josef