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 <mhvk@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
<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 To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: dom.grigonis@gmail.com