I want to create an algorithm to sort binary search trees to make them balanced. But I can't do that If I don't understand myself how each step works!
So I have a binary search tree that I want to rotate to make it balanced. I already have and know the answer as shown by figure 2, but am unsure of the steps necessary to get to that point
Figure 1:
Figure 2:
Any pointers would be great.
Also I am using http://visualgo.net/bst.html
The thing you need here is called tree rotation
What you have done from step 1 to step 2 is a left rotation for node 16 like this:
Node 16 is imbalanced and size(left child) < size(right child) =>
We need to transfer the 16 node to left child,
Get a new node (the smallest) from the right child as the new node (18 since is the smallest)
Rebalance the right child
Related
As we know that to delete any node in BST we replace that deleted node with its inorder predecessor or successor.
I've tried a new approach in which I replace the deleted node either by its direct left child or by its direct right child (instead of replacing by its inorder pred. or succ.). And I think that this approach is valid for every node in BST. Program for this approach will be also easy as less number of links are changed for a node.I am attaching 2 pics to make you understand my approach.
Is my approach of deleting a node in BST is right or wrong? If wrong then why?
This can get pretty complicated, but you'll probably want to look into some rotations.
Say you have a full tree with 5 levels, and you are trying to delete the roots right child, which contains a quite a few more nodes. The issue is that by simply replacing with it's left or right child, would result in the deleted index "having" more than two child, which as I'm sure you know, is an invalid BST.
The solution? Rotations!
Here are a couple links that explain with some pictures.
http://www.mathcs.emory.edu/~cheung/Courses/171/Syllabus/9-BinTree/BST-delete2.html
While this is a valid way to delete a node in a binary tree, it won't always work for binary search trees. Let's say you want to delete 40 and 35 has a right child, by connecting 35 to 45, you'll be losing its original right child and every other node connected to it (you'll be losing a subtree). For binary search trees (BST), its better to replace the node with the rightmost node of the left subtree, which in this case is still 35 (this guarantees it does not have a right child) or the leftmost node of the right subtree if there is no left subtree.
If I construct a binary search tree as I have below, is it right? Or is such a tree not a valid binary search tree?
7
/ \
5 8
/ \
4 10
Because I have followed the rule of smaller element on the left and larger element on the right. So I imagine this is a binary search tree?
Try to walk the tree manually; pretending that you're a function looking for the 4.
You start at the root of the tree: the 7.
4 is less than 7, so you go left to 5.
4 is less than 5 so you go left again.
There's nothing there, so you'd come to the conclusion that 4 is not in the tree.
Of course that's incorrect though, so no, this is not a valid setup for a BST. It isn't simply that each value needs to only be in the correct position relative to its direct parent. Each value also needs to be in a correct position relative to the other nodes in the tree.
The exact position depends on the insertion order of each value, but with this configuration of values, the 4 should be to the left of the 5.
It's definitely a binary tree, as each node only has two leaves.
But like others said, it's not a binary search tree. A way of judging is for each node, all left leaves' values should be smaller than self's value and all right leaves' values should be greater than self's value. Only in this way can perform binary search.
(I've seen some very similiar excercises, but all of them for a regular binary trees). As in the title I have to propose an algorithm to convert BST to another BST with symmetric structure, which includes the same values as the previous one. For example
My idea was to build a new tree from the beggining. I would start with a new root that would be in a symmetric position of the original one in a sorted array of values from the original tree. In the example above: 3 5 6 7 12 number 7 will be the new root, because it has reversed number of nodes at its left/right side in comparison to the previous root 5. But it doesn't solve the problem completely, because the new tree depends on the order of insertion. I wanted to end it with performing rotations depending on the balance. My question is: does this tree have to be AVL tree so i can perform rotations (this would mean there's an error in the excercise). Or is there and easier way to solve this?
I would solve this problem in two steps:
Swap the left and right child pointers in every node. This will mirror the tree left-to right, reversing the order of all the values.
Do a forward in-order traversal from the start and a backward in-order traversal from the end. Proceed in lock step, swapping values between the forward and backward positions until they meet. This will reverse the order of values back to their original order, while preserving the new tree structure.
For exa, this is the tree.
10
12 -1
5 1 1 -2
2 3 10 -9
How to find the node with maximum value?
Given the problem as stated, you need to traverse the entire tree. See proof below.
Traversing the entire tree should be a fairly trivial process.
Proof that we need to traverse the entire tree:
Assume we're able to identify which side of a tree the maximum is on without traversing the entire tree.
Given any tree with the maximum node on the left. Call this maximum x.
Pick one of the leaf nodes on the right. Add 2 children to it: x+1 and -x-1.
Since x+1-x-1 = 0, adding these won't change the sum at the leaf we added it to, thus nor the sums at any other nodes in the tree.
Since this can be added to any leaf in the tree, and it doesn't affect the sums, we'd need to traverse the entire tree to find out if this occurs anywhere.
Thus our assumption that we can identify which side of a tree the maximum is on without traversing the entire tree is incorrect.
Thus we need to traverse the entire tree.
In the general case, you need to traverse the entire tree. If the values in the tree are not constrained (e.g. all non-negative, but in your example there are negative values), then the value in a node tells you nothing about the individual values below it.
I've bumped into this question at one of Coursera algorithms course and realized that I have no idea how to do that. But still, I have some thoughts about it. The first thing that comes into my mind was using optimized bit set (like Java's BitSet) to get mapping node's key -> color. So, all we need is to allocate a one bit set for whole tree and use it as color information source. If there is no duplicatate elements in the tree - it should work.
Would be happy to see other's ideas about this task.
Just modify the BST. For black node, do nothing. And for red node, exchange its left child and right child. In this case, a node can be justified red or black according to if its right child is larger than its left child.
Use the least significant bit of one of the pointers in the node to store the color information. The node pointers should contain even addresses on most platforms. See details here.
There's 2 rules we can use:
since the root node is always black, then a red node will always have a parent node.
RB BST is always with the order that left_child < parent < right_child
Then we will do this:
keep the black node unchanged.
for the red node, we call it as R, we suppose it as the left child node for it's parent node, called P.
change the red node value from R to R', while R' = P + P - R
now that R' > P, but as it's the left child tree, we will find the order mismatch.
If we find an order mismatch, then we will know it's a red node.
and it's easy to go back to the original R = P + P - R'
One option is to use a tree that requires less bookkeeping, e.g. a splay tree. However, splay trees in particular aren't very good for iteration (they're much better at random lookup), so they may not be a good fit for the domain you're working in.
You can also use one BitSet for the entire red-black tree based on node position, e.g. the root is the 0th bit, the root's left branch is the 1st bit, the right branch is the 2nd bit, the left branch's left branch is the 3rd bit, etc; this way it shouldn't matter if there are duplicate elements. While traversing the tree make note of which bit position you're at.
It's much more efficient in terms of space to use one bitset for the tree instead of assigning a boolean to each node; each boolean will take up at least a byte and may take up a word depending on alignment, whereas the bitset will only take up one bit per node (plus 2x bits to account for a maximally unbalanced tree where the shortest branch is half the length of the longest branch).
Instead of using boolean property on a child we could define a red node as the one who has a child in the wrong place.
If we go this way all leaf nodes are guaranteed to to be black and we should swap parent with his sibling (making him red) when inserting a new node.