[Numpy-discussion] Proposed X.flat solution
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 = 1
>a[0,8] = 2
>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