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

A Library of Binary Tree Algorithms as Mixable Scala Traits #496

Closed
wants to merge 12 commits into from

Conversation

erikerlandson
Copy link
Contributor

This is a PR for tree and map traits supporting some binary tree algorithms, factored out of the PR for implementing t-digest: #495

A Library of Binary Tree Algorithms as Mixable Scala Traits
http://erikerlandson.github.io/blog/2015/09/26/a-library-of-binary-tree-algorithms-as-mixable-scala-traits/

@erikerlandson
Copy link
Contributor Author

@johnynek I have tree/map libs in a state that is ready for some more review. They now inherit from SortedMapLike and SortedSetLike. (#495 is not currently rebased onto these latest changes). Unit tests are passing except for a spurious randomized test failure in HLL.

@erikerlandson
Copy link
Contributor Author

Actually I'm going to tweak this a little, it causes some subtle problems when I try to apply it to TDigestMap

@erikerlandson
Copy link
Contributor Author

@johnynek OK I have #495 and #496 synced up.

@@ -1,9 +1,8 @@
language: scala
sudo: false
matrix:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this change in here? other than the compile step being before the test step whats the gain/reasoning?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test was timing out. Factoring out the compilation helps keep the actual 'sbt test' command from running too long. This used to be a separate commit with its own message, but it was all squashed when I refactored the PR

@erikerlandson
Copy link
Contributor Author

@ianoc I replaced object with package

new Inject[K, V](keyOrdering, valueMonoid) with INodeInc[K, V] with IncrementMap[K, V] {
// INode[K]
val color = clr
val lsub = ls.asInstanceOf[NodeInc[K, V]]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the casts here? Why not accept NodeInc[K, V] as the type for ls? same for the rest.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you put a return type on iNode. What are we using here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iNode is an abstract function defined in ...redblack.tree.Node (the very top of the hierarchy). Its return type is INode (the highest level internal tree node type). At that level, it has no knowledge of any sub classes, and so ls and rs have to be Node, and therefore they need to be cast. I also would have preferred not to require casting, but could not discover any way around it. I decided it was at least (a) localized and (b) only relevant to anybody designing a new tree/map subclass.

@erikerlandson
Copy link
Contributor Author

@johnynek, replacing IncrementingMonoid with the standard and more idiomatic MonoidAggregator works as expected.

@erikerlandson
Copy link
Contributor Author

@johnynek @ianoc @avibryant
Any feedback and/or questions on the latest state?

@erikerlandson
Copy link
Contributor Author

This is now available here:
https://github.com/isarn/isarn-collections

So I'm going to close this out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants