[Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

[Robert Kern]

On Tue, Jun 26, 2018 at 1:36 AM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> > On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
> > <sebastian at sipsolutions.net> wrote:
>
> <snip>
>
> > >
> > > Yes, that is true, but I doubt you will find a lot of code path
> > > that
> > > need the current indexing as opposed to vindex here,
> >
> > That's probably true! But I think it's besides the point. I'd wager
> > that most code paths that will use .vindex would work perfectly well
> > with current indexing, too. Most of the time, people aren't getting
> > into the hairy corners of advanced indexing.
> >
>
> Right, the proposal was to have DeprecationWarnings when they differ,
> now I also thought DeprecationWarnings on two advanced indexes in
> general is good, because it is good for new users.
> I have to agree with your argument that most of the confused should be
> running into broadcast errors (if they expect oindex vs. fancy). So I
> see this as a point that we likely should just limit ourselves at least
> for now to the cases for example with sudden transposing going on.
>
> However, I would like to point out that the reason for the more broad
> warnings is that it could allow warping normal indexing at some point.
>

I don't really understand this. You would discourage the "normal" syntax in
favor of these more specific named syntaxes, so you can introduce different
behavior for the "normal" syntax and encourage everyone to use it again?
Just add more named syntaxes if you want new behavior! That's the beauty of
the design underlying this NEP.


> Also it decreases traps with array-likes that behave differently.
>

If we were to take this seriously, then no one should use a bare [] ever.

I'll go on record as saying that array-likes should respond to `a[rr, cc]`,
as in Juan's example, with the current behavior. And if they don't, they
don't deserve to be operated on by skimage functions.

If I'm reading the NEP correctly, the main thrust of the issue with
array-likes is that it is difficult for some of them to implement the full
spectrum of indexing possibilities. This NEP does not actually make it
*easier* for those array-likes to implement every possibility. It just
offers some APIs that more naturally express common use cases which can
sometimes be implemented more naturally than if expressed in the current
indexing. For instance, you can achieve the same effect as orthogonal
indexing with the current implementation, but you have to manipulate the
indices before you pass them over to __getitem__(), losing information
along the way that could be used to make a more efficient lookup in some
array-likes.

The NEP design is essentially more of a way to give these array-likes
standard places to raise NotImplementedError than it is to help them get
rid of all of their NotImplementedErrors. More specifically, if these
array-likes can't implement `a[rr, cc]`, they're not going to implement
`a.vindex[rr, cc]`, either.

I think most of the problems that caused these libraries to make different
choices in their __getitem__() implementation are due to the fact that
these expressive APIs didn't exist, so they had to shoehorn them into
__getitem__(); orthogonal indexing was too useful and efficient not to
implement! I think that once we have .oindex and .vindex out there, they
will be able to clean up their __getitem__()s to consistently support
whatever of the current behavior that they can and raise
NotImplementedError where they can't.

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/008c0aa2/attachment.html>