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

[Travis Oliphant]

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