[Numpy-discussion] Ill-defined in-place operations (#1085)
josef.pktd@gmai...
josef.pktd@gmai...
Wed Apr 15 15:36:09 CDT 2009
On Wed, Apr 15, 2009 at 4:10 PM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
>
>
> On Wed, Apr 15, 2009 at 1:52 PM, Pauli Virtanen <pav@iki.fi> wrote:
>>
>> Mixing views and mutating (eg. in-place) operations can cause surprising
>> and ill-defined results. Consider
>> http://projects.scipy.org/numpy/ticket/1085:
>>
>> >>> import numpy as np
>> >>> x = np.array([[1,2], [3,4]])
>> >>> x
>> array([[1, 2],
>> [3, 4]])
>> >>> x += x.T
>> >>> x
>> array([[2, 5],
>> [8, 8]])
>> >>> y = np.array([[1,2], [3,4]], order='F')
>> >>> y
>> array([[1, 2],
>> [3, 4]])
>> >>> y += y.T
>> >>> y
>> array([[2, 7],
>> [5, 8]])
>>
>> The result depends on the order in which the elements happen to lie in
>> the memory. Predicting the outcome is nearly impossible. (Also, I think
>> Numpy tries to optimize the order of the loops, making it even more
>> difficult?)
>>
>> This is a sort of a pitfall. Should Numpy issue a warning every time a
>> mutating operation is performed on an array, with input data that is a
>> view on the same array?
>
> My first thought is yes, just because the result is hard to predict.
>
>>
>> Some alternatives:
>>
>> a) Raise warning for all arrays, even 1-D.
>
> Yes again. Are there examples where one would not want a warning? Examples
> that couldn't be implemented otherwise?
>
> Chuck
I had a similar problem with changing the view or dtype of an array to
a structured array, that also worked directly on the base and only
threw an exception if the base was inconsistent with the change in
dtype.
Is there a list of gotchas for working with views that might produce
unexpected results?
Josef
More information about the Numpy-discussion
mailing list