Closed bjarthur closed 9 months ago
No reason I cant remember what even failed to have a type restriction there.
I think searchsorted
just needs <
and <=
defined? Can anything be considered "ordered" without that?
Maybe we can just delete all of those types.
We can just state in the docs that Ordered
lookup contents must define <
. The automatic detection for it runs issorted
already anyway, which must also use <
.
Merging #560 (64cf739) into main (b9162e1) will increase coverage by
0.01%
. The diff coverage isn/a
.
@@ Coverage Diff @@
## main #560 +/- ##
==========================================
+ Coverage 88.06% 88.07% +0.01%
==========================================
Files 40 40
Lines 3326 3329 +3
==========================================
+ Hits 2929 2932 +3
Misses 397 397
Files | Coverage Δ | |
---|---|---|
src/LookupArrays/selector.jl | 87.82% <ø> (ø) |
... and 3 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Well that failed on Symbol
... maybe we can go back to just adding String
, or AbstractString
and work this out more systematically later.
Thanks!
any reason not to use the much faster
searchsorted
instead offindfirst
forAt
on a dimension whose indices areString
? tests pass locally and my application code is 2x faster.