In a binary search tree, how do you determine which list item should be the root, and which items should be the leafs?
To make it optimized each root should be the mid point for each leaf, making the tree more balanced.
Related
I'm reading through red black tree chapter from the book "introduction to algorithms" by Cormen. In that delete chapter, it basically says if both the node and node's parent are black, then the sibling of node's parent has to exist. The text is in page 327 first paragraph.
I don't get the logic for it, like how do we deduct something like that? Is that even true?
Though I did try to implement my own version of RB Tree and I couldn't produce a tree with a subtree like
/
R
/
B
/ \
B ...
/
...
or
/
B
/
B
/ \
B ...
/
...
Basically both node and parent are black but parent doesn't have sibling. Can't produce it so far
The text is correct. The only time you can have a black node with no sibling is when the node in question is the tree root. The easy way to think of this is to draw out the B-tree equivalent, Moving red nodes up so they are part of the same block as their parent black node. When you do this it becomes easy to see that a non-root black node with no sibling is going to produce an unbalanced tree.
In fact the two options for a non-root non-leaf black node are that either the sibling is black, or the sibling is red and has two black children (even if those two children are leaf nodes and simply represented by a null value in the implementation).
SoronelHaetir is right. But there are 3 things to say about fixups of deletes:
When "sibling" is talked about, this is normally the sibling of the current Node. It is not usually parent's sibling. So if the current Node is the left child of the parent then the "sibling" is the right child of the parent.
You say "I don't get the logic for it, like how do we deduct something like that? Is that even true?". Yes it is. One of the rules is the total black Node count down every path is the same.
So in a correct RB tree, for a given node, if the left child is black, then the right child is black (or it is red and it has 2 black children). For a correct RB Tree, you cannot have any node with an unbalanced count of black nodes down all paths. The count has to be the same in every path.
The other situation where you have unbalanced black tree count is where a leaf node has been deleted and it is black, and you are in the process of restoring the black tree count. Until it is restored (which can always be done), the tree is not a valid RB Tree.
I'm getting confused the more I search. Does the term "height" only apply to the root node of a BST? Or does each node have its own corresponding height? Similarly, does each node of a BST have a corresponding level?
Height of a BST or any binary tree is the total number of edges from the root node to the most distant leaf node. You are probably getting confused with recursion when a node on another level is passed as the root. For every node, it is the parent of its subtree, so it is the root for that subtree. That's how recursion works.
I have a telecommunications mesh network graph where there are multiple path between multiple nodes.
I want to be able to select 2 nodes and highlight all inter connected nodes and edges that make up the paths between them.
How would you recommend I tackle this?
I've tried using aStar, then removing the nodes and edges and reiterating, however some paths share edges so that didn't work.
To get all of the paths between two nodes in Cytoscape.js you can use the following:
function findPaths(src,dest) {
let successors = src.successors();
let predecessors = dest.predecessors();
return successors.intersection(predecessors);
}
This takes all of the nodes and edges from src and keeps only those that are also in the set of those leading to dest.
It does not enumerate the paths - it is just the full set of nodes and edges in the paths.
To actually enumerate all the individual possible paths (it can be a large number if you're dealing with a complex graph) you would do a depth first recursion on the results of this function. Each time dest is visited, you would display the path that led to the visit.
I am new to binary search tree data structure. One thing I don't understand is why the leftest node is the smallest
10
/ \
5 12
/ \ / \
1 6 0 14
In the above instance, 0 is the smallest value not 1.
Let me know where I got mixed up.
Thank you!
That tree is not binary search tree.
Creating a binary search tree is a process which starts with adding
elements.
You can do it with array.
First there is no element so make it root.Then start adding elements as node.If the new value is bigger than before add it array[2 x n + 1] (call index of the last value: n). If it is smaller than before add it to array[2 x n]. So all values left of any node is smaller than it and all values right of any node is bigger than it. Even 10 and 6's place.6 cannot be 11.(at your tree,it isn't actually.).That's all !
For a tree to be considered as a binary search tree, it must satisfy the following property:
... the key in each node must be greater than all keys stored in the left sub-tree, and smaller than all keys in right sub-tree
Source: https://en.wikipedia.org/wiki/Binary_search_tree
The tree you posted is not a binary search tree because the root node (10) is not smaller than all keys in the right sub-tree (node 0)
I'm not really sure of your question, but binary search works by comparing the search-value to the value of the node, starting with the root node (value 10 here). If the search-value is less, it then looks at the left node of the root (value 5), otherwise it looks next at the right node (12).
It doesn't matter so much where in the tree the value is as long as the less and greater rule is followed.
In fact, you want to have trees set up like this (except for the bad 0 node), because the more balanced a tree is (number of nodes on left vs. number of nodes on right), the faster your search will be!
A tree balancing algorithm might, for example, look for the median value in a list of values and make that the value of the root node.
I have this code which iterates over a tree, doing a depth-first search. Every element is tackled exactly once. Very good.
-(void)iterateOverTree:(TreeNode *)node
{
NSMutableArray * elements = [NSMutableArray array];
[elements addObject:node];
while([elements count])
{
TreeNode * current = [elements objectAtIndex:0];
[self doStuffWithNode:current];
for(TreeNode * child in current.children)
{
[elements addObject:child];
}
[elements removeLastObject];
}
}
BUT: How can I keep track of the current depth in the graph? I need to know the level of depth. So for example I have these nodes:
A has childs B, J.
B has child C.
C has child D.
D has childs E, F, I.
When A is at depth level 1, then B is 2 and C is 3.
With recursion it was very easy to keep track of the current depth level. Just inrement a variable before calling itself and decrement it after calling itself.
But here with this fancy while loop that is not possible. There is no box in the box in the box happening like with recursion.
I don't really want to have to add properties (or instance variables) to the TreeNode object as this should be re-usable in a generic way for any kind of object graph.
Does anyone have an idea how to do this? Must I introduce another array to keep track of visited nodes?
I think you do need to stack the depths as well. This is what you would actually have done anyway, if you had a recursive version. It's just that the storage would be “invisible”, since you would have used the call stack instead of an explicit stack like you are doing now.
If it helps you, you could easily convert the depth-first search to a breadth-first search, by using the array as a queue instead of a stack. (Just do removeFirstObject instead of removeLastObject.) Then you would know that you always look at the nodes in order of non-decreasing depth. However, if you need exact depths, I think you still need to add some storage for keeping track of when you have to increment the current depth.
Update:
You should be able to do a DFS without the stack altogether, if instead you follow parent pointers of the node to back up the tree. That would make maintaining the depth simple. But you would have to be careful not to break linear-time worst-case complexity by rescanning children to find out where you were.
If you don't have parent pointers, it should be possible to stack just enough information to keep track of the parents. But this would mean that you put some more information on the stack than you are currently doing, so it would not be much of an improvement over stacking the depths directly.
By the way, looking carefully on your algorithm, aren't you looking at the wrong side of the array when you get the next current node? It should work like this:
push root
while stack not empty:
current = pop
push all children of current
Im not understanding your notation, but if I read correctly you process a node and add all children to your list of work to do.
If you could change that part to using a recursion, you could track the tree-depth since it would be the recursion depth.
So instead of adding the child node, recurse for each child node.
hth
Mario
I believe what you are doing actually is BFS. You are working with lists. For doing DFS, you should use a stack;
This might be useful for the depth track, you might look into the vector p (of parents)
Supposing you are doing BFS, the easiest thing to do is to introduce another queue for depth that mirrors your nodes queue. Initialize the depth to zero. Each time you push to the node queue, push the current depth + 1 to the depth queue.