Hi Stephan, Thanks for replying to my concerns.
I have looked a bit more into it and `intersect1d` is not the right concept for my problem anyway. And it is great that it works faster than reduce approach. Also, I did more speed tests and, after all, `in1d` approach is not generally faster. It is faster in some cases and slower in others. Also, it uses more memory in all cases. Regards, DG > On 5 Feb 2024, at 14:30, Stephan Kuschel via NumPy-Discussion > <numpy-discussion@python.org> wrote: > > Dear Dom, > > thanks for bringing up the possible constriction. I agree that this would be > serious argument against the change. > > However, as you said the overlapping/non-overlapping indices would become > ambiguous with more than two arrays. And calling the fucntion with only two > arrays at a time would still be possible. So we will be unable to generalize > in the future towards a problem, that only has ambinuous solutions. So I fail > to see what exactly we the other use case would be. > > The point of this change is not the luxory of allowing multiple arrays to > calculate the intersection. Its all about getting the indices in the original > arrays, using `return_indices=True`. > > All the Best > Stephan > > Am 02.02.24 um 17:36 schrieb Dom Grigonis: >> Also, I don’t know if this could be of value, but my use case for this is to >> find overlaps, then split arrays into overlapping and non-overlapping >> segments. >> Thus, it might be useful for `return_indices=True` to return indices of all >> instances, not only the first. >> Also, in my case I need both overlapping and non-overlapping indices, but >> this would become ambiguous with more than 2 arrays. >> If it was left with 2 array input, then it can be extended to return both >> overlapping and non-overlapping parts. I think it could be another potential >> path to consider. >> E.g. what would be the speed comparison: >> intr= intersect1d(arr1, arr2, assume_unique=False) >> intr= intersect1d(intr, np.unique(arr3), assume_unique=True) >> # VS new >> intr= intersect1d(arr1, arr2, arr3, assume_unique=False) >> Then, does the gain from such generalisation justify constriction it >> introduces? >> Regards, >> DG >>> On 2 Feb 2024, at 17:31, Marten van Kerkwijk <m...@astro.utoronto.ca >>> <mailto:m...@astro.utoronto.ca><mailto:m...@astro.utoronto.ca >>> <mailto:m...@astro.utoronto.ca>>> wrote: >>> >>>> For my own work, I required the intersect1d function to work on multiple >>>> arrays while returning the indices (using `return_indizes=True`). >>>> Consequently I changed the function in numpy and now I am seeking >>>> feedback from the community. >>>> >>>> This is the corresponding PR: https://github.com/numpy/numpy/pull/25688 >>>> <https://github.com/numpy/numpy/pull/25688><https://github.com/numpy/numpy/pull/25688 >>>> <https://github.com/numpy/numpy/pull/25688>> >>> >>> <snip> >>> >>> To me this looks like a very sensible generalization. In terms of numpy >>> API, the only real change is that, effectively, the assume_unique and >>> return_indices arguments become keyword-only, i.e., in the unlikely case >>> that someone passed those as positional, a trivial backward-compatible >>> change will fix it. >>> >>> -- Marten >>> _______________________________________________ >>> NumPy-Discussion mailing list -- numpy-discussion@python.org >>> <mailto:numpy-discussion@python.org> <mailto:numpy-discussion@python.org >>> <mailto:numpy-discussion@python.org>> >>> To unsubscribe send an email to numpy-discussion-le...@python.org >>> <mailto:numpy-discussion-le...@python.org><mailto:numpy-discussion-le...@python.org >>> <mailto:numpy-discussion-le...@python.org>> >>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ >>> <https://mail.python.org/mailman3/lists/numpy-discussion.python.org/><https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ >>> <https://mail.python.org/mailman3/lists/numpy-discussion.python.org/>> >>> Member address: dom.grigo...@gmail.com <mailto:dom.grigo...@gmail.com> >> _______________________________________________ >> NumPy-Discussion mailing list -- numpy-discussion@python.org >> <mailto:numpy-discussion@python.org> >> To unsubscribe send an email to numpy-discussion-le...@python.org >> <mailto:numpy-discussion-le...@python.org> >> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ >> <https://mail.python.org/mailman3/lists/numpy-discussion.python.org/> >> Member address: stephan.kusc...@gmail.com <mailto:stephan.kusc...@gmail.com> > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > <mailto:numpy-discussion@python.org> > To unsubscribe send an email to numpy-discussion-le...@python.org > <mailto:numpy-discussion-le...@python.org> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > <https://mail.python.org/mailman3/lists/numpy-discussion.python.org/> > Member address: dom.grigo...@gmail.com <mailto:dom.grigo...@gmail.com>
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
