Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

O(1) searchsorted for Ranges satisfying RangeStepRegular #30501

Open
kcajf opened this issue Dec 24, 2018 · 3 comments
Open

O(1) searchsorted for Ranges satisfying RangeStepRegular #30501

kcajf opened this issue Dec 24, 2018 · 3 comments
Labels
domain:search & find The find* family of functions

Comments

@kcajf
Copy link
Contributor

kcajf commented Dec 24, 2018

RangeStepStyle is defined here:
https://github.com/JuliaLang/julia/blob/master/base/traits.jl#L55

Presumably, the implication of this is that searchsorted on a RangeStepRegular Range should be constant-time: just subtract the start, divide by the step, and round it (of course, handling all the edge-cases)? Is this something that could/should be implemented somewhere central? If so, I can't really work out how to write a method that dispatches specifically on Ranges that implement RangeStepRegular.

@kcajf
Copy link
Contributor Author

kcajf commented Dec 24, 2018

Looks like this is already implemented in Base for AbstractRange{<:Real}, so there is a base to work off / extend:

function searchsortedlast(a::AbstractRange{<:Real}, x::Real, o::DirectOrdering)

@nalimilan
Copy link
Member

The RangeStepStyle trait isn't used anywhere currently. It should probably have been removed when #26022 got rid of its uses in hashing code (at least the docstrings should be updated to stop mentioning hash). Maybe we could use it for searchsorted, but you could also start implementing functions for specific range types with a know regular step -- I'm not sure whether it's possible to write generic code which would work for any regular range.

@nalimilan nalimilan added the domain:search & find The find* family of functions label Dec 25, 2018
@mcabbott
Copy link
Contributor

Just found this issue, wonder whether this trait ought to have been used by #30778 to avoid #35203?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:search & find The find* family of functions
Projects
None yet
Development

No branches or pull requests

3 participants