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 <mhvk@astro.utoronto.ca <mailto: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 <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> To unsubscribe send an email to numpy-discussion-leave@python.org <mailto:numpy-discussion-leave@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.grigonis@gmail.com
_______________________________________________ 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: stephan.kuschel@gmail.com