[Numpy-discussion] Proposal: np.search() to complement np.searchsorted()

Martin Spacek numpy at mspacek.mm.st
Mon May 15 10:47:14 EDT 2017

On 2017-05-09 07:39 PM, Stephan Hoyer wrote:
> On Tue, May 9, 2017 at 9:46 AM, Martin Spacek <numpy at mspacek.mm.st
> <mailto:numpy at mspacek.mm.st>> wrote:
>     Looking at my own habits and uses, it seems to me that finding the indices
>     of matching values of one array in another is a more common use case than
>     finding insertion indices of one array into another sorted array. So, I
>     propose that np.search(), or something like it, could be even more useful
>     than np.searchsorted().
> The current version of this PR only returns the indices of the /first/ match
> (rather than all matches), which is an important detail. I would strongly
> consider including that detail in the name (e.g., by calling this "find_first"
> rather than "search"), because my naive expectation for a method called "search"
> is to find all matches.
> In any case, I agree that this functionality would be welcome. Getting the
> details right for a high performance solution is tricky, and there is strong
> evidence of interest given the 200+ upvotes on this StackOverflow question:
> http://stackoverflow.com/questions/432112/is-there-a-numpy-function-to-return-the-first-index-of-something-in-an-array

Good point about it only finding the first hit. However, `np.find_first` sounds 
a bit awkward to me. I've updated the PR to have a `which` kwarg that specifies 
whether it should return the first or last hit for values in `v` that have 
multiple hits in `a`.


Not sure if I already mentioned this somewhere, but we might also consider 
naming this `np.index` due to its analogous behaviour to the Python list method 


More information about the NumPy-Discussion mailing list