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 <sebast...@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.k...@gmail.com> > > > wrote: > > > > > > On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser <wieser.eric+numpy@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@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
