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

Robert Kern robert.kern at gmail.com
Wed Jun 27 01:26:44 EDT 2018

On Tue, Jun 26, 2018 at 10:21 PM Juan Nunez-Iglesias <jni.soma at gmail.com>

> Let me start by thanking Robert for articulating my viewpoints far better
> than I could have done myself. I want to explicitly flag the following
> statements for endorsement:
> *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.*
> *In the post-NEP .oindex/.vindex order, everyone can get the behavior that
> they want. Your argument for deprecation is now just about what the default
> is, the semantics that get pride of place with the shortest spelling. I am
> sympathetic to the feeling like you wish you had a time machine to go fix a
> design with your new insight. But it seems to me that just changing which
> semantics are the default has relatively attenuated value while breaking
> compatibility for a fundamental feature of numpy has significant costs.
> Just introducing .oindex is the bulk of the value of this NEP. Everything
> else is window dressing.*
> *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).*
> I would offer the exception of trailing slices to this statement, though:
> In [1]: from skimage import data
> In [2]: astro = data.astronaut()
> In [3]: astro.shape
> Out[3]: (512, 512, 3)
> In [4]: rr, cc = np.array([1, 3, 3, 3]), np.array([1, 8, 9, 10])
> In [5]: astro[rr, cc].shape
> Out[5]: (4, 3)
> In [6]: astro[rr, cc, :].shape
> Out[6]: (4, 3)
> This does exactly what I would expect.

Yup, sorry, I didn't mean those. I meant when there is an explicit slice in
between index arrays. (And maybe when index arrays follow slices; I'll need
to think more on that.)

> Going back to the motivation for the NEP, I think this bit, emphasis mine,
> is crucial:
> the existing rules for advanced indexing with multiple array indices are
> typically confusing to both new, **and in many cases even old,** users of
> NumPy
> I think it is ok for advanced indexing to be accessible to advanced users.
> I remember that it took me quite a while to grok NumPy advanced indexing,
> but once I did I just loved it.
> I also like that this syntax translates perfectly from integer indices to
> float coordinates in `ndimage.map_coordinates`.
> *I'll go on record as saying that array-likes should respond to `a[rr,
> cc]`, as in Juan's example, with the current behavior. And if they don't,
> they don't deserve to be operated on by skimage functions.*
> (I don't think of us highly enough to use the word "deserve", but I would
> say that we would hesitate to support arrays that don't use this
> convention.)

Ahem, yes, I was being provocative in a moment of weakness. May the
array-like authors forgive me.

Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/4cfaa12d/attachment-0001.html>

More information about the NumPy-Discussion mailing list