[Numpy-discussion] array copy-to-self and views
Travis Oliphant
oliphant at ee.byu.edu
Thu Feb 1 15:15:45 EST 2007
Zachary Pincus wrote:
>>>A question, then: Does this represent a bug? Or perhaps there is a
>>>better idiom for modifying an array in-place than 'a[:] = ...'? Or is
>>>incumbent on the user to ensure that any time an array is directly
>>>modified, that the modifying array is not a view of the original
>>>array?
>>>
>>>
>>>
>>>
>>Yes, it is and has always been incumbent on the user to ensure that
>>any
>>time an array is directly modified in-place that the modifying
>>array is
>>not a "view" of the original array.
>>
>>
>
>Fair enough. Now, how does a user ensure this -- say someone like me,
>who has been using numpy (et alia) for a couple of years, but clearly
>not long enough to have an 'intuitive' feel for every time something
>might be a view (a feeling that must seem quite natural to long-time
>numpy users, who may have forgotten precisely how long it takes to
>develop that level of intuition)?
>
>
Basically, red-flags go off when you do in-place modification of any
kind and you make sure you don't have an inappropriate view. That
pretty much describes my "intuition." Views arise from "slicing"
notation. The flipud returning a view is a bit obscure and should be
documented better.
>Documentation of what returns views helps, for sure. Would any other
>'training' mechanisms help? Say a function that (despite Tim's pretty
>reasonable 'don't do that' warning) will return true when two arrays
>have overlapping memory? Or an 'inplace_modify' function that takes
>the time to make that check?
>
>
I thought I had written a function that would see if two input arrays
have over-lapping memory, but maybe not. It's not hard for a contiguous
chunk of memory, but for two views it's a harder function to write.
It's probably a good idea to have such a thing, however.
-Travis
More information about the NumPy-Discussion
mailing list