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

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.

> 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.mapcoordinates. > > > 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