Re: propose deprecation of generalized-vector-*

[Noah Lavine]

Hello,

On Mon, Feb 18, 2013 at 10:55 AM, Andy Wingo <address@hidden> wrote:

Hi,

On Wed 23 Jan 2013 13:20, Daniel Llorens <address@hidden> 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