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

Sebastian Berg sebastian at sipsolutions.net
Wed Jun 27 02:45:44 EDT 2018


On Tue, 2018-06-26 at 22:26 -0700, Robert Kern wrote:
> On Tue, Jun 26, 2018 at 10:21 PM Juan Nunez-Iglesias <jni.soma at gmail.
> com> wrote:
> > 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:
> > 


OK, sounds fine to me, I see that we just can't start planning for a
possible long term future yet. I personally do not care really what the
warnings itself say for now (Deprecation or not), larger packages will
have to avoid them in any case though.
But I guess we have a consent on a certain amount of warnings (probably
will have to see how much they actually appear) and then can revisit in
a longer while.

- Sebastian


> > 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.
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180627/9846401a/attachment.sig>


More information about the NumPy-Discussion mailing list