[Numpy-discussion] array copy-to-self and views

Travis Oliphant oliphant@ee.byu....
Thu Feb 1 14:15:45 CST 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