[Numpy-discussion] copy on demand

[Perry Greenfield]

> I guess the best reason to bite the bullet and carry around state
> information
> would be if there were significant other cases where one also
> would want to
> optimize operations under the hood. If there isn't much else in
> this direction
> then the effort involved might not be justified. One thing that bugs me in
> Numeric (and that might already have been solved in numarray) is that
> e.g. ``ravel`` (and I think also ``transpose``) creates
> unnecessary copies,
> whereas ``.flat`` doesn't, but won't work in all cases (viz. when
> the array is
> non-contiguous), so I can either have ugly or inefficient code.
>
I guess that depends on what you mean by unnecessary copies. If the
array is non-contiguous what would you have it do?

> > a feature one wants even though they are not the default, it turns
> > out that it isn't all that simple to obtain views without sacrificing
> > ordinary slicing syntax to obtain a view. It is simple to obtain
> > copies of view slices though.
>
> I'm not sure I understand the above.  What is the problem with
> ``a.view[1:3]``
> (or``a.view()[1:3])?
>
I didn't mean to imply it wasn't possible, but that it was not
quite as clean. The thing I don't like about this approach (or
Paul's suggestion of a.sub) is the creation of an odd object
that has as its only purpose being sliced. (Even worse, in my
opinion, is making it a different kind of array where slicing
behaves differently. That will lead to the problem we have
discussed for other kinds of array behavior, namely, how do
you keep from being confused about a particular array's slicing
behavior). That could lead to confusion as well. Many may be
under the impression that x = a.view makes x refer to an array
when it doesn't. Users would need to know that a.view without
a '[' is usually an error.

Sure it's not hard to implement. But I don't view it as that
clean a solution. On the other hand, a[1:3].copy() (or alternatively,
a[1:3].copy) is another array just like any other.
>
Perry