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

Eric Wieser wieser.eric+numpy at gmail.com
Tue Jun 26 12:36:39 EDT 2018


We can expose some of the internals

These could be expressed as methods on the internal indexing objects I
proposed in the first reply to this thread, which has seen no responses.

I think Hameer Abbasi is looking for something like
OrthogonalIndexer(...).to_vindex()
-> VectorizedIndexer such that arr.oindex[ind] selects the same elements as
arr.vindex[OrthogonalIndexer(ind).to_vindex()]

Eric
​

On Tue, 26 Jun 2018 at 08:04 Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Tue, 2018-06-26 at 04:01 -0400, Hameer Abbasi wrote:
> > I second this design. If we were to consider the general case of a
> > tuple `idx`, then we’d not be moving forward at all. Design changes
> > would be impossible. I’d argue that this newer model would be easier
> > for library maintainers overall (who are the kind of people using
> > this), reducing maintenance cost in the long run because it’d lead to
> > simpler code.
> >
> > I would also that the “internal” classes expressing outer as
> > vectorised indexing etc. should be exposed, for maintainers of duck
> > arrays to use. God knows how many utility functions I’ve had to write
> > to avoid relying on undocumented NumPy internals for pydata/sparse,
> > fearing that I’d have to rewrite/modify them when behaviour changes
> > or I find other corner cases.
>
> Could you list some examples what you would need? We can expose some of
> the internals, or maybe even provide funcs to map e.g. oindex to vindex
> or vindex to plain indexing, etc. but it would be helpful to know what
> downstream actually might need. For all I know the things that you are
> thinking of may not even exist...
>
> - Sebastian
>
>
>
> >
> > Best Regards,
> > Hameer Abbasi
> > Sent from Astro for Mac
> >
> > > On 26. Jun 2018 at 09:46, Robert Kern <robert.kern at gmail.com>
> > > wrote:
> > >
> > > On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser <wieser.eric+numpy at gma
> > > il.com> wrote:
> > > > > I don't think it should be relegated to the "officially
> > > > discouraged" ghetto of `.legacy_index`
> > > >
> > > > The way I read it, the new spelling lof that would be the
> > > > explicit but not discouraged `image.vindex[rr, cc]`.
> > > >
> > >
> > > Okay, I missed that the first time through. I think having more
> > > self-contained descriptions of the semantics of each of these would
> > > be a good idea. The current description of `.vindex` spends more
> > > time talking about what it doesn't do, compared to the other
> > > methods, than what it does.
> > >
> > > Some more typical, less-exotic examples would be a good idea.
> > >
> > > > > I would reserve warnings for the cases where the current
> > > > behavior is something no one really wants, like mixing slices and
> > > > integer arrays.
> > > >
> > > > These are the cases that would only be available under
> > > > `legacy_index`.
> > > >
> > >
> > > I'm still leaning towards not warning on current, unproblematic
> > > common uses. It's unnecessary churn for currently working,
> > > understandable code. I would still reserve warnings and deprecation
> > > for the cases where the current behavior gives us something that no
> > > one wants. Those are the real traps that people need to be warned
> > > away from.
> > >
> > > If someone is mixing slices and integer indices, that's a really
> > > good sign that they thought indexing behaved in a different way
> > > (e.g. orthogonal indexing).
> > >
> > > If someone is just using multiple index arrays that would currently
> > > not give an error, that's actually a really good sign that they are
> > > using it correctly and are getting the semantics that they desired.
> > > If they wanted orthogonal indexing, it is *really* likely that
> > > their index arrays would *not* broadcast together. And even if they
> > > did, the wrong shape of the result is one of the more easily
> > > noticed things. These are not silent errors that would motivate
> > > adding a new warning.
> > >
> > > --
> > > Robert Kern
> > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > NumPy-Discussion at python.org
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/0a9dbac7/attachment.html>


More information about the NumPy-Discussion mailing list