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