Re: propose deprecation of generalized-vector-*

[Noah Lavine <noah.b.lavine@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

Hello,

On Mon, Feb 18, 2013 at 10:55 AM, Andy Wingo <wingo@pobox.com> wrote:

> Hi,
>
> On Wed 23 Jan 2013 13:20, Daniel Llorens <daniel.llorens@bluewin.ch>
> writes:
>
> > In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
> > In [4]: a[1]
> > Out[4]: array([4, 5, 6])
> > In [5]: a[1, 1]
> > Out[5]: 5
> >
> > array-ref can be extended very simply to do that. It accumulates on the
> > position as it is done now, but if the index list comes up short it
> > makes a shared array with the remaining axes instead of giving a rank
> > error. So it shouldn't be any slower than array_ref.
>
> It could make sense, yes.  What do others think?  What happens for
> array-set!?  Care to propose a patch?


I haven't worked with the array functionality, so I might be missing
something, but I don't see why this is natural for array-ref. It breaks the
expectation that array-ref always returns an element of the array. It seems
to be that it might be better to have some other function that returns a
slice of the array, with a one-element array being a special case of its
result. (array-ref could even be implemented in terms of this other
function.)

I think that returning a slice instead of throwing an error would be
natural if we automatically mapped scalar operations over arrays. But we
don't, so an array really does have to be viewed as a very different type
than its components, so this change doesn't make sense to me.

I would be happy to be wrong here, but this just jumped out at me as
something that would be a surprising change in behavior, and possibly lead
to bugs. Does anyone have example code that shows why this makes sense?

Best,
Noah

[-- Attachment #2: Type: text/html, Size: 2325 bytes --]