-
Notifications
You must be signed in to change notification settings - Fork 15
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 sorted collections #501
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jackfirth
force-pushed
the
sorted-collections
branch
from
July 17, 2021 02:51
c9fc64e
to
b48310d
Compare
Planning to reuse this for other sorted collections.
Insertion is implemented. Removal and membership testing aren't yet.
Nothing's implemented yet. Planning on using Okasaki's implementation in Purely Functional Data Structures.
Mutable sorted sets use mutable red-black trees, immutable sorted sets use persistent red-black trees. As an optimization, when an immutable sorted set is created with a builder its elements are placed into an immutable vector and the tree structure (which requires more memory and indirections, but offers persistence) is created lazily. This way, immutable sorted sets that are built from stream pipelines never have to pay the costs of using persistent data structures and get O(1) random access, indirection-free search, and much faster iteration speeds.
No rebalancing yet
Also, move the `cut` data type into its own private module.
This will replace the implementation currently in `rebellion/collection/sorted-set` eventually.
jackfirth
force-pushed
the
sorted-collections
branch
from
August 3, 2021 04:24
5fdcefa
to
2ee4b5a
Compare
Needed to make it possible for `sorted-set-contains?` to work with values that can't be compared to the contents of a set.
Also fixes some minor bugs in iteration and binary search on mutable RB trees.
Making them single use was a cute idea but doesn't really buy anything.
Remaining tasks for sorted sets:
|
This is needed for the synchronized collection views. Not really tested for now since I'm mainly testing it via the synchronized sorted set implementation. Needs thorough tests Eventually™.
Handy version of sequence->sorted-set that doesn't require knowing the comparator.
I'm going to merge this as-is since it's already huge. All the basics for sorted sets are there sans detection of modification during iteration. I'll work on sorted maps next, since multisets, range sets, and range maps are all just views of sorted maps. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a work-in progress change that will add mutable and immutable sorted collections to Rebellion, including:
The immutable collections will also come with builders, which support the use case of building a collection up with many writes before any reads are performed (such as in a stream pipeline, e.g.
(transduce numbers #:into (into-sorted-set natural<=>))
. When created with builders, the immutable collections will not use a persistent representation under the hood to support constant-time random access and efficient iteration. Instead, the persistent representation will be created lazily the first time an immutable collection is used with the persistent update functions such assorted-set-add
. This combines the best of both worlds: use cases that don't need to interleave reads and writes get efficient random-access immutable collections, and use cases that do have their immutable collections upgraded to persistent collections automatically.Lots of implementation work left to do.
In particular, I still need to figure out how to represent subset views efficiently, especially for mutable collections.Also, the mutable collections won't be thread-safe but will provide fail-fast behavior on concurrent modification during iteration, like java'sConcurrentModificationException
. This is too useful for detecting data races to ignore. In the future I may consider offering alternative thread-safe implementations, but the default mutable collection implementations won't change.