8000 Inconsistent indexing result depending on argument type · Issue #6564 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Inconsistent indexing result depending on argument type #6564

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
llvilanova opened this issue Oct 26, 2015 · 5 comments
Closed

Inconsistent indexing result depending on argument type #6564

llvilanova opened this issue Oct 26, 2015 · 5 comments

Comments

@llvilanova
Copy link

The following results seem inconsistent to me (numpy 1.9.2):

>>> a = np.arange(8).reshape((2,2,2))
>>> a[ [[0], [0]] ]
array([[0, 1]])
>>> a[ np.array([[0], [0]]) ]
array([[[[0, 1],
         [2, 3]]],
       [[[0, 1],
         [2, 3]]]])

I've briefly looked at the indexing manual (http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html) and nothing seems to account for this.

Thanks,
Lluis
@njsmith
Copy link
Member
njsmith commented Oct 27, 2015

Well, that looks weird indeed. Normally I'd ignore this and wait for @seberg to respond, but I think he's on vacation :-)

I think what's going on is... well, first, background: Python has a weird calling convention for indexing, where if you write [obj] without any commas then __getitem__ gets passed obj directly, but if you write [obj1, obj2] with a comma then __getitem__ gets passed a tuple (obj1, obj2). A consequence of this is that it's impossible to tell the difference between getting passed a single tuple [(obj1, obj2)] versus getting passed two arguments [obj1, obj2]. This means that __getitem__ has to have some special case code to figure out when to unpack tuples and stuff. So far so good. I think what's going on here is that numpy is seeing a[ [[0], [0]] ] and incorrectly treating the outermost list like it were a tuple, i.e., it's treated like it were a[ ([0], [0]) ], which is equivalent to a[ [0], [0] ].

This looks like a bug to me, but it might be one of those bugs that we can't fix without breaking a bunch of code, or where there's some complicated deprecation required or something... probably we should just wait until @seberg gets back because he'll probably know off the top of his head which type of weird case this one is :-)

@seberg
Copy link
Member
seberg commented Oct 27, 2015

exactly, i have an opwn PR to deprecate it, might need some work though. the docs do have a warning somewhere, but the excat rules are a bit funny and nowherr explained

greetings from esfahan, iran :).

@seberg
Copy link
Member
seberg commented Nov 10, 2015

There is a warning here http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#advanced-indexing which basically hints at the problem.

IIRC the exact rule is: A sequence is treated like a tuple, if:

  1. It has no more then 32 entries (maximum number of dimensions)
  2. It contains at least one of a sequence, None, Ellipsis or slice object.

The pull request I mentioned is gh-4434, is it time to try this? Maybe another note to the list would be good as well before we do that. @llvilanova if you feel strongly about it, please go ahead :).

@llvilanova
Copy link
Author

I've just noted it in the list (https://mail.scipy.org/pipermail/numpy-discussion/2015-November/074266.html). Thanks.

@reminisce reminisce mentioned this issue May 30, 2018
Open
@seberg
Copy link
Member
seberg commented Jan 3, 2019

This has a futurewarning now and will eventually change, so closing.

@seberg seberg closed this as completed Jan 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@seberg @llvilanova @njsmith
0