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>> 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-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
_______________________________________________
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: stephan.kusc...@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
