Fix bug in search_sorted (we weren't testing for equality at the end)
#1296
Conversation
|
No good deed goes unpunished, eh? There are two reasonable I think we should have both. The exact-match-only API is easily implemented in terms of the largest-smaller-index API (and now that we have the case-of-case optimization, doing it that way shouldn't even incur any performance cost, provided the optimization triggers). We might even try to change the type of largest-smaller-index API to return some type like |
Context: google-research#1296 (comment) The more basic API, still named `search_sorted`, returns a `Post n`. The idea is that the elements of `xs` are fence sections, and we find the position between them (inclusive on either end) where `x` falls in the ordering. In terms of this, we now define `search_sorted_exact` (better name?), which returns a `Maybe n`, which is the index of an element of `xs` that equals `x` exactly, or `Nothing` if such does not exist. Also reorder the prelude slightly to try to both maintain semantic groupings and respect name resolution dependencies.
|
Superseded by #1315. |
Context: #1296 (comment) The more basic API, still named `search_sorted`, returns a `Post n`. The idea is that the elements of `xs` are fence sections, and we find the position between them (inclusive on either end) where `x` falls in the ordering. In terms of this, we now define `search_sorted_exact` (better name?), which returns a `Maybe n`, which is the index of an element of `xs` that equals `x` exactly, or `Nothing` if such does not exist. Also reorder the prelude slightly to try to both maintain semantic groupings and respect name resolution dependencies.
No description provided.