lt(less than) function argument order of searchsortedfirst is different from that of searchsortedlast.
Is this specification?
These are actually keyword arguments, so their order does not matter. But you’re right that it would be more consistent to use the same order everywhere. And the docstrings should be fixed to use ; to separate positional arguments from keyword arguments (and stop using brackets).
A pull request to fix this would be welcome, but this API is going to be redesigned soon anyway. See this issue and this Julep.
That Julep is missing searchsorted.
The tables are also missing one of the possible return values, length(vec)+1, for searchsortedfirst, when the value is greater than all of the values in vec
A few things that would be very useful for the searchsorted* (that I ended up having to make my own sorted search functions for), is functions optimized for sorted unique vectors, that can both return an insertion point and an indication of whether the value was found, and a searchsortedeq function (basically in, but with the knowledge that the vector is both sorted and has no duplicates).
Another thing is to expose (and document) the ability to pass in the beginning and ending indices for the search,
and have the final argument have a default in that case (now it doesn’t, it requires the final argument that combines the keyword arguments together if you want to pass in the lo and hi args)
The searchsorted* functions are mentioned under “Particular cases”.
Yes, but the section: Dimensions of Variation needs those two extra cases, i.e. the mode of operation (return a range, which is possibly an empty insertion point), and the return when not found (return length(vec)+1).
Note the inconsistency (which I’d stumbled over early on) between searchsortedfirst and findfirst when not found.
It will be very nice to have these functions handled in a cleaner and more consistent fashion!