[Numpy-discussion] NEP 21: Simplified and explicit advanced indexing (original) (raw)

Travis Oliphant teoliphant at gmail.com
Tue Jun 26 04:24:06 EDT 2018

I like the proposal generally. NumPy could use a good orthogonal indexing method and a vectorized-indexing method is fine too.

Robert Kern is spot on with his concerns as well. Please do not change what arr[idx] does except to provide warnings and perhaps point people to new .oix and .vix methods. What indexing does is documented (if hard to understand and surprising in a particular sub-case).

There is one specific place in the code where I would make a change to raise an error rather than change the order of the axes of the output to provide a consistent subspace. Even then, it should be done as a deprecation warning and then raise the error.

Otherwise, just add the new methods and don't make any other changes until a major release.

-Travis

On Tue, Jun 26, 2018 at 2:03 AM Hameer Abbasi <einstein.edison at gmail.com> 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. Best Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> 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 gmail.com> wrote: > I don't think it should be relegated to the "officially discouraged" ghetto of .legacyindex

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 legacyindex. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/4cb45089/attachment.html>

More information about the NumPy-Discussion mailing list