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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion