<div dir="ltr"><div class="markdown-here-wrapper" style="font-size:1em;font-family:Helvetica,arial,freesans,clean,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255);border:none;line-height:1.2"><blockquote style="margin:1em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1em 0px">We can expose some of the internals</p>
</blockquote>
<p style="margin:1em 0px">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.</p>
<p style="margin:1em 0px">I think Hameer Abbasi is looking for something like <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">OrthogonalIndexer(...).to_vindex() -> VectorizedIndexer</code> such that <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">arr.oindex[ind]</code> selects the same elements as <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">arr.vindex[OrthogonalIndexer(ind).to_vindex()]</code></p>
<p style="margin:1em 0px">Eric</p>
<div title="MDH:Jmd0O8KgPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzMsIDMzLCAzMyk7Ij5XZSBjYW4gZXhwb3Nl
IHNvbWUgb2YmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzMsIDMzLCAzMyk7
Ij50aGUgaW50ZXJuYWxzPGJyPjxicj48L3NwYW4+PGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IHJn
YigzMywgMzMsIDMzKTsiPlRoZXNlIGNvdWxkIGJlIGV4cHJlc3NlZCBhcyBtZXRob2RzIG9uIHRo
ZSBpbnRlcm5hbCBpbmRleGluZyBvYmplY3RzIEkgcHJvcG9zZWQgaW4gdGhlIGZpcnN0IHJlcGx5
IHRvIHRoaXMgdGhyZWFkLCB3aGljaCBoYXMgc2VlbiBubyByZXNwb25zZXMuPC9zcGFuPjwvZGl2
PjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzMsIDMzLCAzMyk7Ij48YnI+PC9zcGFuPjwv
ZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzMsIDMzLCAzMyk7Ij5JIHRoaW5rJm5i
c3A7PC9zcGFuPjxmb250IGNvbG9yPSIjMjEyMTIxIj5IYW1lZXIgQWJiYXNpIGlzIGxvb2tpbmcg
Zm9yIHNvbWV0aGluZyBsaWtlPC9mb250PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzMywg
MzMpOyI+Jm5ic3A7YE9ydGhvZ29uYWxJbmRleGVyKC4uLikudG9fdmluZGV4KCkgLSZndDsgVmVj
dG9yaXplZEluZGV4ZXJgIHN1Y2ggdGhhdCBgYXJyLm9pbmRleFtpbmRdYCBzZWxlY3RzIHRoZSBz
YW1lIGVsZW1lbnRzIGFzIGBhcnIudmluZGV4Wzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJn
YigzMywgMzMsIDMzKTsiPk9ydGhvZ29uYWxJbmRleGVyKGluZCkudG9fdmluZGV4KCldYDwvc3Bh
bj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzMywgMzMpOyI+PGJyPjwv
c3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzMywgMzMpOyI+RXJp
Yzwvc3Bhbj48L2Rpdj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">​</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 26 Jun 2018 at 08:04 Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2018-06-26 at 04:01 -0400, Hameer Abbasi wrote:<br>
> I second this design. If we were to consider the general case of a<br>
> tuple `idx`, then we’d not be moving forward at all. Design changes<br>
> would be impossible. I’d argue that this newer model would be easier<br>
> for library maintainers overall (who are the kind of people using<br>
> this), reducing maintenance cost in the long run because it’d lead to<br>
> simpler code.<br>
> <br>
> I would also that the “internal” classes expressing outer as<br>
> vectorised indexing etc. should be exposed, for maintainers of duck<br>
> arrays to use. God knows how many utility functions I’ve had to write<br>
> to avoid relying on undocumented NumPy internals for pydata/sparse,<br>
> fearing that I’d have to rewrite/modify them when behaviour changes<br>
> or I find other corner cases.<br>
<br>
Could you list some examples what you would need? We can expose some of<br>
the internals, or maybe even provide funcs to map e.g. oindex to vindex<br>
or vindex to plain indexing, etc. but it would be helpful to know what<br>
downstream actually might need. For all I know the things that you are<br>
thinking of may not even exist...<br>
<br>
- Sebastian<br>
<br>
<br>
<br>
> <br>
> Best Regards,<br>
> Hameer Abbasi<br>
> Sent from Astro for Mac<br>
> <br>
> > On 26. Jun 2018 at 09:46, Robert Kern <<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>><br>
> > wrote:<br>
> > <br>
> > On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser <wieser.eric+numpy@gma<br>
> > <a href="http://il.com" rel="noreferrer" target="_blank">il.com</a>> wrote:<br>
> > > > I don't think it should be relegated to the "officially<br>
> > > discouraged" ghetto of `.legacy_index`<br>
> > > <br>
> > > The way I read it, the new spelling lof that would be the<br>
> > > explicit but not discouraged `image.vindex[rr, cc]`.<br>
> > > <br>
> > <br>
> > Okay, I missed that the first time through. I think having more<br>
> > self-contained descriptions of the semantics of each of these would<br>
> > be a good idea. The current description of `.vindex` spends more<br>
> > time talking about what it doesn't do, compared to the other<br>
> > methods, than what it does.<br>
> > <br>
> > Some more typical, less-exotic examples would be a good idea.<br>
> > <br>
> > > > I would reserve warnings for the cases where the current<br>
> > > behavior is something no one really wants, like mixing slices and<br>
> > > integer arrays. <br>
> > > <br>
> > > These are the cases that would only be available under<br>
> > > `legacy_index`.<br>
> > > <br>
> > <br>
> > I'm still leaning towards not warning on current, unproblematic<br>
> > common uses. It's unnecessary churn for currently working,<br>
> > understandable code. I would still reserve warnings and deprecation<br>
> > for the cases where the current behavior gives us something that no<br>
> > one wants. Those are the real traps that people need to be warned<br>
> > away from.<br>
> > <br>
> > If someone is mixing slices and integer indices, that's a really<br>
> > good sign that they thought indexing behaved in a different way<br>
> > (e.g. orthogonal indexing).<br>
> > <br>
> > If someone is just using multiple index arrays that would currently<br>
> > not give an error, that's actually a really good sign that they are<br>
> > using it correctly and are getting the semantics that they desired.<br>
> > If they wanted orthogonal indexing, it is *really* likely that<br>
> > their index arrays would *not* broadcast together. And even if they<br>
> > did, the wrong shape of the result is one of the more easily<br>
> > noticed things. These are not silent errors that would motivate<br>
> > adding a new warning.<br>
> > <br>
> > -- <br>
> > Robert Kern<br>
> > <br>
> > _______________________________________________<br>
> > NumPy-Discussion mailing list<br>
> > <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> > <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
> <br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>