-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Add range searches to TreeMap/TreeSet #4604
Comments
That would be really appreciated! |
@thestinger hi, I have some progress on this issue and I would like to try to resolve it, if you don't mind. However I need some advice:
|
It can return an upper bound but it won't be able to return a lower bound, so it would return Iterating in both directions from the same iterator isn't a pattern represented by iterators in Rust, because a pair of iterators is more useful. A double-ended iterator is possible for some of the iterators, but it would be slower so it can't just replace the normal iterators. |
@thestinger I implemented lower_bound/upper_bound, please review: #8227 |
If pull request (#8227) is accepted and merged (as I hope ^_^), it will be easy to implement Also I can't find a good example of situation when I would want use What do you think about it? |
I'm going to call this done. There's the potential for a |
TreeMap (and TreeSet) should provide a variant of
find
that returns an iterator instead of the value, for finding the start (or end) of a range of values in O(log n). It would probably make sense to exposelower_bound
andupper_bound
like C++ does instd::map
too.The basic functionality is pretty simple, it's just the same process as
find
but each node along the way is pushed onto an iterator's stack, which is then returned. However, it would be nice to get values in the reverse direction too, especially without needing to walk down the tree twice. In C++, the lazy iterators are bidirectional - but that's because they have pointers to walk (which really wouldn't work for an owned tree in Rust, and is likely slower).The text was updated successfully, but these errors were encountered: