Hello, On Mon, Feb 18, 2013 at 10:55 AM, Andy Wingo <wi...@pobox.com> wrote:
> Hi, > > On Wed 23 Jan 2013 13:20, Daniel Llorens <daniel.llor...@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
