I've heard some terminology in regards to trees that I haven't heard before. There are some references to graft points in our code base in relation to n-ary trees. What exactly is a graft point in a tree and what could these references be referring to? Thanks!
A graft point is nothing more than the location of the node where you're tacking on/inserting an additional node or set of nodes. These can be new nodes or nodes you may have moved from some other location (For instance, when you're balancing a tree).
I assume it's referring to something involving either http://en.wikipedia.org/wiki/Grafting_%28computer%29 or http://en.wikipedia.org/wiki/Grafting_%28algorithm%29.
Related
I need to implement an n-ary tree. The problem is I'm allowed to use only preorder traversal. What I find it hard is to make a function that will add new node. New nodes are being added from left to right, and again, I'm not allowed to use level order, only preorder.
What I thought is to maybe somehow compare levels of the leaf nodes, and if there are free nodes at the maximum level of the tree, then that's where I add new node. Since this is not that easy, and I'm not sure if I'm even on the right way, I decided to post question here to see if anyone has any idea? Or maybe if there's another way of doing this?
Thank you in advance.
We all know what a tree is: on the first level of a tree we have a root, and from the root come branches that are trees as well. But how do I name the "opposite" structure: on the i-th level we have a set of "leaf" nodes, and those nodes form groups of 1+ nodes, and a group points to a "trunk" node on i+1th level. If you want a visual example, imagine raindrops flowing down a window and combining as they collide.
A lot of tree data structures are actually constructed from leaf to root, and can be stored to allow for going one or both directions.
I don't think it really has a special name as it's more a convention than a requirement for trees typically to go from root to leaf rather than the other way or both ways. Also there are a number of tree data structures that allow for going both ways.
Every tree is a DAG, a directed acyclic graph, and so is the data-structure that you describe. What you describe is also a multitree, a subset of DAGs. Possibly there is a more precise real subset of multitrees that describes your graph, but I am not aware of it. Hope this helps.
Is it 'traditional' (or 'ethical') for a Node in a binary tree to keep a reference to its parents?
Normally, I would not think so, simply because a tree is a directed graph, and so the fact that the PARENT-->CHILD link is defined should not mean that CHILD --->PARENT is also defined.
In other words, by keeping a reference to the parent, we would somehow break the semantic of the tree.
But I would like to know what people think?
I asked because I was given a problem of finding the lowest common parent of two given nodes in a tree. If each node has a reference to its parent, the problem would be super easy to solve, but that feels like cheating!
Thanks
How you implement a binary tree should be dependent on your needs.
If your application requires tree traversal in the direction of leaf to trunk, then the best way to do so would be to implement references to parent nodes.
I find that it is better to fit your data structures to your needs rather than try to make workarounds with other logic. After all, why must a tree be a directed graph? Making it directed is a specific implementation, much like a list and its specific implementation as a singly- or doubly-linked list.
It can still be a directed graph of ownership. Consider the following node:
template <typename T>
struct node
{
T data_;
std::unique_ptr<node> left_child_; // I own my children.
std::unique_ptr<node> right_child_;
node* parent_; // Just lookin' at my parent.
};
As Steven Meyer said above, it's really not cheating: build the data structure to solve your problem, don't worry about the ethics of it :-)
Cross-posting from the Software Engineering Stack Exchange.
The Wikipedia definition states "For example, looking at a tree as a whole, one can talk about "the parent node" of a given node, but in general, as a data structure, a given node only contains the list of its children but does not contain a reference to its parent (if any)."
For dynamic programming, what are some of the ways that I store a tree with?
I am working on an assignment that requires me to solve a maze with no left turn and a minimize right turn. The idea that I had is to store all possible paths into a tree and then going through (traverse) the tree looking for the minimum right-turns. To make the code more efficient, anytime a path involves either
a) a left turn
b) a solution with more right turn than the current best known solution
I will not add it to the tree. Hopefully I have a clear understanding of what I am doing here. I really do appreciate input on this.
The tree that I am looking at storing will contain all possible directions in the maze, and the parent of each children will be the previous location. I believe that some parents will have more than 2 children.
I am wondering what is the best way to store this kind of tree?
Thank you in advance.
If the problem is to solve the maze, I suggest using backtracking instead of creating such a tree. If you have to create the tree, you could use a tree in which every junction where you could turn right is represented as a node, and the children would be the next junction if turned right, or the next one if you did not. I'm not sure I understood you correctly, but I hope this gives you some pointers as to how to continue.
I'm using the Lengauer and Tarjan algorithm with path compression to calculate the dominator tree for a graph where there are millions of nodes. The algorithm is quite complex and I have to admit I haven't taken the time to fully understand it, I'm just using it. Now I have a need to calculate the dominator trees of the direct children of the root node and possibly recurse down the graph to a certain depth repeating this operation. I.e. when I calculate the dominator tree for a child of the root node I want to pretend that the root node has been removed from the graph.
My question is whether there is an efficient solution to this that makes use of immediate dominator information already calculated in the initial dominator tree for the root node? In other words I don't want to start from scratch for each of the children because the whole process is quite time consuming.
Naively it seems it must be possible since there will be plenty of nodes deep down in the graph that have idoms just a little way above them and are unaffected by changes at the top of the graph.
BTW just as aside: it's bizarre that the subject of dominator trees is "owned" by compiler people and there is no mention of it in books on classic graph theory. The application I'm using it for - my FindRoots java heap analyzer - is not related to compiler theory.
Clarification: I'm talking about directed graphs here. The "root" I refer to is actually the node with the greatest reachability. I've updated the text above replacing references to "tree" with "graph". I tend to think of them as trees because the shape is mainly tree-like. The graph is actually of the objects in a java heap and as you can imagine is reasonably hierarchical. I have found the dominator tree useful when doing OOM leak analysis because what you are interested in is "what keeps this object alive?" and the answer ultimately is its dominator. Dominator trees allow you to <ahem> see the wood rather than the trees. But sometimes lots of junk floats to the top of the tree so you have a root with thousands of children directly below it. For such cases I would like to experiment with calculating the dominator trees rooted at each of the direct children (in the original graph) of the root and then maybe go to the next level down and so on. (I'm trying not to worry about the possibility of back links for the time being :)
boost::lengauer_tarjan_dominator_tree_without_dfs might help.
Judging by the lack of comments, I guess there aren't many people on Stackoverflow with the relevent experience to help you. I'm one of those people, but I don't want such an interesting question go down with with a dull thud so I'll try and lend a hand.
My first thought is that if this graph is generated by other compilers would it be worth taking a look at an open-source compiler, like GCC, to see how it solves this problem?
My second thought is that, the main point of your question appears to be avoiding recomputing the result for the root of the tree.
What I would do is create a wrapper around each node that contains the node itself and any pre-computed data associated with that node. A new tree would then be reconstructed from the old tree recursively using these wrapper classes. As you're constructing this tree, you'd start at the root and work your way out to the leaf nodes. For each node, you'd store the result of the computation for all the ancestory thus far. That way, you should only ever have to look at the parent node and the current node data you're processing to compute the value for your new node.
I hope that helps!
Could you elaborate on what sort of graph you're starting with? I don't see how there is any difference between a graph which is a tree, and the dominator tree of that graph. Every node's parent should be its idom, and it would of course be dominated by everything above it in the tree.
I do not fully understand your question, but it seems to me you want to have some incremental update feature. I researched a while ago what algorithms are their but it seemed to me that there's no known way for large graphs to do this quickly (at least from a theoretical standpoint).
You may just search for "incremental updates dominator tree" to find some references.
I guess you are aware the Eclipse Memory Analyzer does use dominator trees, so this topic is not completely "owned" by the compiler community anymore :)