[Numpy-discussion] Proposed X.flat solution

Travis Oliphant oliphant at ee.byu.edu
Fri Feb 18 12:29:21 EST 2005

>Hmm.  It seems to me that if it is not a live view you can run into
>serious problems.  What happens if you do this:
>a = zeros((10,10))
>b = a[::2,::2].flat
>b[4] = 1
>a[0,8] = 2
>del b
>Doesn't your behavior lead to a[0,8] being overwritten to 1 by the copy
>back from b?
Well in this particular case since a is contiguous to begin with, b is 
not a copy so the copy-back would not occur.

But, you bring up a valid point that if "a" were discontiguous which 
forced a copy, then any later modifications to "a" would be ignored.
Now, this could be fixed by making "a" read-only for the duration of 
existence of the flattened reference. 

In fact, it probably stands to reason that whenever, UPDATEIFCOPY is 
used on the C-level, the to-be-copied-to array is flagged readonly for the
duration of existence of the "reference."

Besides that point, to clarify what we are talking about here:

1)  The PEP has been modified so that X[K] is interpreted as X[K,]  for 
integer arrays, and the previously-discussed distinction disappears.

2)  It is desired that X.flat[K]  provide the flattened behavior.   How 
should this be done?

     a) having X.flat return an indexable iterator (with an __array__ 
method that will automatically return an update-if-copy array on
         request from asarray() or C-level equivalent)

     b) having X.flat return an update-if-copy array (with X flagged as 
readonly while a reference to X.flat exists)

     c) it shouldn't be done and X.flat should just raise an error if X 
is not contiguous.

Please chime in and "vote" for one of the three solutions (or another 
one not covered) for 2 if you haven't already expressed your view.

By the way, I think it's been settled that X.flat will not behave the 
same as ravel(X) (which should probably be a method---X.ravel() ).


More information about the NumPy-Discussion mailing list