[Numpy-discussion] copy on demand

[Alexander Schmolck]

Chris Barker <Chris.Barker at noaa.gov> writes:

> My conclusion is that nested lists and Arrays simply are different
> beasts so we can't expect complete compatibility. I'm also wondering why
> lists have that weird behavior of a single index returning a reference,
> and a slice returning a copy. Perhaps it has something to so with the

This is not weird at all. Slicing and single item indexing are different
conceptually and what I think you have in mind wouldn't really work. Think of
a real life container, like box with subcompartments. Obviously you should be
able to take out (or put in) an item from the box, which is what single
indexing does (and the item may happen to be another box). My understanding is
that you'd like the box to return copies of whatever was put into it on
indexing, rather than the real thing -- this would not only be
counterintuitive and inefficient, it also means that you could exclusively put
items with a __copy__-method in lists, which would rather limit their
usefulness.

Slicing on the other hand creates a whole new box but this box is filled with
(references to) the same items (a behavior for which a real life equivalent is
more difficult to find :) :

>>> l = 'foobar'
>>> l = ['foobar', 'barfoot']
>>> l2 = l[:]
>>> l2[0] is l[0]
1

Because the l and l2 are different boxes, however, assigning new items to l1
doesn't change l2 and vice versa.

It is true, however that the situation is somewhat different for arrays,
because "multidimensional" lists are just nested boxed, whereas
multidimensional arrays have a different structure. array[1] indexes some part
of itself according to its .shape (which can be modified, thus changing what
array[1] indexes, without modifying the actual array contents in memory),
whereas list[1] indexes some "real" object. 

This may mean that the best behavior for ``array[0]`` would be to return a
copy and ``array[:]`` etc. what would be a "deep copy" if it where nested
lists. I think this is the behavior Paul Dubois MA currently has.


> auto-resizing of lists. That being said, I still like the idea of slices
> producing copies, so:
> 
> > 1) array
> An Array like we have now, but slice-is-copy
> semantics.                                                                                                                                                                                               
> 
> > 2) array[0]
> An Array of rank one less than array,  sharing data with array
> 
> > 3) array.view
> An object that can do nothing but create other Arrays that share data
> with array. I don't know if is possible but I'd be just as happy if
> array.view returned None, and array.view[slice] returned an Array that

No it is not possible.

> shared data with array. Perhaps there is some other notation that could
> do this.
> 
> > 4) array.view[0]
> Same as 2)

I can't see why single-item indexing views would be needed at all if
``array[0]`` doesn't copy as you suggest above.

> 
> To add a few:
> 
> 5) array[0:1] 
> An Array with a copy of the data in array[0]

(I suppose you'd also want array[0:1] and array[0] to have different shape?)

> 
> 6) array.view[0:1] 
> An Array sharing data with array
> 
> As I write this, I am starting to think that this is all a bit strange.
> Even though lists treat slices and indexes differently, perhaps Arrays
> should not. They really are different beasts. I also see why it was done

Yes, arrays and lists are indeed different beasts and a different indexing
behavior (creating copies) for arrays might well be preferable (since array
indexing doesn't refer to "real" objects).

> the way it was in the first place!
> 
> -Chris

alex

-- 
Alexander Schmolck     Postgraduate Research Student
                       Department of Computer Science
                       University of Exeter
A.Schmolck at gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/