Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)
On Di, 2016-09-06 at 13:59 -0400, Marten van Kerkwijk wrote: > In a separate message, since perhaps a little less looney: yet > another > option would be work by analogy with np.ix_ and define pre-dispatch > index preparation routines np.ox_ and np.vx_ (say), which would be > used as in: > ``` > array[np.ox_[:, 10]] -- or -- array[np.vx_[:, 10]] > ``` > This could work if those functions each return something appropriate > for the legacy indexer, or, if that is not possible, a specific > subclass of tuple as a marker that gets interpreted further up. > A specific subclass of tuple Part of me thinks this is horrifying, but it actually would solve some of the subclassing issues if `arr.vindex[...]` could end up calling `__getitem__` with a bit special indexing tuple value. I simply can't quite find the end of subclassing issues. We have tests for things like masked array correctly calling the `_data` subclass, but if the `_data` subclass does not implement the new method, numpy would have to run in circles (or something) - Sebastian > In the end, though, probably also too complicated. It may remain best > to simply implement the new methods instead and keep it at that! > > -- Marten > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)
There remains the option to just let subclasses deal with new ndarray features... Certainly, for `Quantity`, I'll quite happily do that. And if it alllows the ndarray code to remain simple and efficient, it is probably the best solution. -- Marten ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)
On So, 2016-09-11 at 11:19 -0400, Marten van Kerkwijk wrote: > There remains the option to just let subclasses deal with new ndarray > features... Certainly, for `Quantity`, I'll quite happily do that. > And if it alllows the ndarray code to remain simple and efficient, it > is probably the best solution. -- Marten > Maybe, but I can't quite shake the feeling that we would see a lot of annoying bugs for subclasses that don't adept very quickely. > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] New iterator APIs (nditer / MapIter): Overlap detection in NumPy
Hi, In the end some further API additions turn out to appear needed: * NPY_ITER_COPY_IF_OVERLAP, NPY_ITER_OVERLAP_NOT_SAME flags for NpyIter_New. * New API function PyArray_MapIterArrayCopyIfOverlap, as ufunc.at needs to check overlaps for index arrays before constructing iterators, and the parsing is done in multiarray. Continuation here: https://github.com/numpy/numpy/pull/8043 Wed, 07 Sep 2016 18:02:59 +0200, Sebastian Berg kirjoitti: > Hi all, > > Pauli just opened a nice pull request [1] to add overlap detection to > the new iterator, this means adding a new iterator flag: > > `NPY_ITER_COPY_IF_OVERLAP` > > If passed to the iterator (also exposed in python), the iterator will > copy the operands such that reading and writing should only occur for > identical operands. For now this is implemented by always copying the > output/writable operand (this could be improved though, so I would not > say its fixed API). > > Since adding this flag is new API, please feel free to suggest other > names/approaches or even decline the change ;). > > > This is basically a first step, which should be easily followed by > adding overlap detection to ufuncs, removing traps such as the well (or > not so well known) `a += a.T`. Other parts of numpy may follow one by > one. > > The work is based on his older awesome new memory overlap detection > implementation. > > If there are no comments, I will probably merge it very soon, so we can > look at the follow up things. > > - Sebastian > > > [1] https://github.com/numpy/numpy/ pull/8026___ > NumPy-Discussion mailing list NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
