Link/Cut-Trees implementation #186
Conversation
|
I'm not sure that Boost.Graph really is the right place for |
|
@jeremy-murphy comments resolved, checks passed :) |
|
Hi @jeremy-murphy Thanks for reviewing! This PR has been ready for quite a while. Any concerns before merging it? Would appreciate someone with write access to have a look :) @jzmaddock |
|
Hey, sorry, I don't have much time for open-source projects now that I have a baby! I'll try to review again quickly. |
|
@jeremy-murphy Thanks for helping review again 😄 |
|
Hi @jeremy-murphy good sir, all comments resolved & checks passed, ready again :) Hope this is not disturbing you @jzmaddock Would you mind having a look to help merge it? :)) |
|
I can't merge it, sorry, I don't have that access. @jzmaddock is the only person I'm aware of with that access and is active at the moment. |
|
This has been lying in backlog for quite a while. @jzmaddock would you mind having a look? :) |
…rename link_cut_tree to link_cut_trees; add docs
… typename outside of template
|
thanks for adding this! |
|
@jingpengw I guess it depends on the template parameters? All I know is that boost serialization supports POD and STL containers, I think you can use them to instantiate link-cut trees. |
|
@jzmaddock Could you please take a look at this MR when you've got time? It's ready for merge :) Thank you. |
|
@jzmaddock did you get a chance to take a look? is it good to merge? |
|
I need to get the CI fixed and I'm going to prioritize merging some bug fixes, but then one day I'll get back to you! ;) |
|
any chance to merge this? |
Yes, there is a chance. :) I'll try to look over it again soon, but I can't guarantee anything. |
Btw, what I meant is, I definitely want to merge it, it's just a matter of chance that I find time to do it. :) |
|
|
||
| namespace boost | ||
| { | ||
| template<class ElementParentMap, class ElementChildMap = ElementParentMap> |
There was a problem hiding this comment.
I presume that Element in the Parent and Child maps have to be the same type, right? Or at the very minimum, they must be convertible to each other? The reason I ask is that I presume we can simplify the member functions from being templated on Element to being non-template functions. If we impose the strict requirement of being the same type then we can just get the element type from one of the map types, something like:
using Element = ElementParentMap::key_type;
Or if we want to allow more flexibility, then it might have to be:
using Element = typename std::common_type_t<ElementParentMap::key_type, ElementChildMap::key_type>;
What do you think?
| template <class Element> | ||
| Element find_path(Element x) | ||
| { | ||
| splay(x); | ||
| return x; | ||
| } | ||
|
|
There was a problem hiding this comment.
Not sure if this function needs to exist?
| template <class ID = identity_property_map, | ||
| class InverseID = boost::unordered_map<typename property_traits<ID>::value_type, typename property_traits<ID>::key_type>, | ||
| class IndexMapContainer = boost::unordered_map<typename property_traits<ID>::value_type, typename property_traits<ID>::value_type> > |
There was a problem hiding this comment.
Boost.Unordered has a new, much faster, hash map called unordered_flat_map: https://www.boost.org/doc/libs/develop/libs/unordered/doc/html/unordered.html
It's not compliant with unordered_map, but I presume we don't need the extra features of the standard interface and can drop it in here.
This PR implements Link/Cut-Trees data structure for Boost Graph Library. Since disjoint_sets algorithms has been moved into boost/graph (#169), this should also be the right place to put link_cut_trees algorithm.
This implementation of link_cut_trees supports following operations:
make_tree(x): create a new link/cut-tree containing only rootxlink(x, y): make the tree rooted atxa subtree ofy;cut(x): remove the edge connectingxto its parent;find_root(x): find the root of the tree containingx;lowest_common_ancestor(x, y): find the lowest common ancestor of suchxandythat have same root.All operations above are of amortized time complexity O(log n), except O(1) for
make_tree.This implementation refers to:
Robert Endre Tarjan, Data Structures and Network Algorithms, Chapter 5