[Numpy-discussion] copy on demand
ransom at physics.mcgill.ca
Mon Jun 17 10:14:48 EDT 2002
On June 17, 2002 04:57 am, Konrad Hinsen wrote:
> > > Then the only solution I see is the current one: default behaviour is
> > > view, and when you want a copy yoy copy explicitly. The inverse is not
> > > possible, once you made a copy you can't make it behave like a view
> > > anymore.
> > I don't think it is necessary to create the other object _from_
> > the default one. You could have copy behavior be the default,
> > and if you want a view of some array you simply request one
> > explicitly with .view, .sub, or whatever.
> Let's make this explicit. Given the following four expressions,
> 1) array
> 2) array
> 3) array.view
> 4) array.view
> what would the types of each of these objects be according to your
> proposal? What would the indexing behaviour of those types be?
> I don't see how you can avoid having either two types or two
> different behaviours within one type.
If we assume that a slice returns a copy _always_, then I agree that #4 in
your list above would not give a user what they would expect:
array.view would give the view of a copy of array, _not_ a view of
array which is probably what is wanted. I _think_ that this could be
fixed by making view (or something similar) an option of the slice rather
than a method of the object. For example (assuming that a is an array):
Expression: Returns: Slicing Behavior:
a or a[:] Copy of all of a Returns a copy of the sub-array
a Copy of a Returns a copy of the sub-array
a[:,view] View of all of a Returns a copy of the sub-array
a[0,view] View of a Returns a copy of the sub-array
Notice that it is possible to return a copy of a sub-array from a view since
you have access (through a pointer) to the original array data.
Scott M. Ransom Address: McGill Univ. Physics Dept.
Phone: (514) 398-6492 3600 University St., Rm 338
email: ransom at physics.mcgill.ca Montreal, QC Canada H3A 2T8
GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989
More information about the NumPy-Discussion