I am wondering if there is fundamental issue for AVL tree re-balancing. According to several tutorials, for AVL insertion, maximum 2 rotates it can be balanced. However, it may depend what is called as balanced. Follow link to see the tree.
Originally it has 6 elements. Assume that we inserted the last value as 3 or 4.5 or 5.5 or 6.5. Anyway, it will be inserted on the left side of the bottom. As total 7 element tree, for perfect balancing, I will consider it has only 3 rows.
This will force the new root is 6 or 6.5 (if we insert 6.5). I really cannot figure out a way to rebalancing it within 2 rotations.
If we only depends on the "balance" definition, 4-rows is still called balanced, but it will result more searching time.
Am I missing something?
In case the picture got deleted, below is a text version:
7
5 9
4 6 8 Empty_slot
3 or 4.5 or 5.5 or 6.5
As you can read on wikipedia
In an AVL tree, the heights of the two child subtrees of any node differ by at most one
That doesn't imply that you have a complete tree ! See examples of balances tree in the wikipedia page linked.
So for any of the insertion you propose you tree will still be balanced (for the common definition of balanced) after the insertion
on the one side of the root you'll have the subtree
5
4 6 height 2
3 # # #
and on the oder side you would have the subtree
9
8 # height 1
As thoses 2 subtrees only have a difference of height of 1, so it's ok ... and you can check that this property is true for all nodes
Related
I'm working on a homework problem involving B+ Trees. The question asks us to insert (2,3,5,7,11,17,19,23,29,31) in a B+ Tree whose node structure has 4 pointers.
This is where I have reached.
Solution so far
Image 2
I want to know if now, to inset 17 should I split the current node into two and distribute key-values (Same as step 2 : Image 1) or should I move 5 to the leaf node on left and update key-value in parent node to 7 and the insert 17 by shifting 7 and 11 one place left(As in image 2)? The second approach would impose computational overhead but will save space. But there is no mention of this in the text.(Database System Concepts)
I have a problem of tee diagram that represents city roads and need to calculate all possible ways -permutations- to establish these roads.
The role is " you can not start level 2 without finishing level 1" and so on for higher levels
this image illustrates the ideahere
i tried to think of it as an array for every level and then a single column for every branch like this
level1=[1 2]
level2=[3 4
5 6]
and
l
;evel1=[1 2 3]
level2=[4 5 0;
6 7 8;
9 10 0]
level3=[11 12;
13 0;
14 15;
16 17;
0 0;
0 0;
18 19]
But i stopped and have no idea how to complete. so i need to know how to think in this kind of problems.
You should look into the concept of "abstract datatypes" as your current design won't scale. Every time you add a new level, you need to create a new array and then update your code to know about this new array.
And the process of searching one level before moving on to the next is known as "breadth first" searching. If you create a list type, you can add all the nodes from the current level to the list and then as you process the list, you add the child nodes to the end of the list.
But that isn't really applicable to generating all permutations - doing "depth first" is more suitable as you travel down the tree and when you can't go no further, the path you've taken is a permutation.
I had a doubt when we are using a splay tree, the last accessed element will come to the root node. consider my tree is
5
/ \
3 7
/ \ / \
2 4 6 8
when I perform a inorder traversal, the output will be
2 3 4 5 6 7 8
so here the last accessed element is 8, in that I have a doubt, so the 8 will be the last accessed node, so we want to move 8 as a root node or not?
Your logic is correct. But the operation of splaying is only done during insertion and searching and not during traversal. When you insert or search a node it is moved to the top(made as root node) so that it would be accessed quickly thereafter.
You can choose either way. There are multiple factors here.
The classic algorithm for inorder traversal of binary trees is recursive, and splay trees can be as deep as they have nodes because they are not strictly balanced. So, a recursive in order traversal of a splay tree can easily run out of stack space -- and it could take up as much memory than the splay tree itself!
If the splay tree has nodes with parent pointers the inorder traversal can be done without recursion and without splaying. This is because you can find the prececessor and successor by following left, right, and parent pointers.
It is also possible to efficiently iterate splay tree nodes in order as follows:
Find the smallest element and splay it to the root.
Find its successor and splay it to the root.
Find its successor and splay it to the root. Etc.
Continue until there is no successor.
In this case, when all is done, the root will be the largest element when done.
Inorder traversal of splay trees (or https://doi.org/10.1016/S1571-0661(04)80771-0) describes why this approach is efficient. It is nearly O(n) to visit each node of a splay tree in order, splaying each time.
I have a question regarding the insertion in an AVL Tree. I noticed that there are some cases in which for example, after you inserted an element, both the parent and it's child are breaking the AVL condition. For example here https://www.youtube.com/watch?v=EsgAUiXbOBo, at min. 12:50, when after 1 was inserted, both 4 and 3 are breaking the AVL condition. My question is on which node should we do the rotation. The closest one to the root (in this case is the root itself) or the one who is farthest from the root, as we would get two different trees in those cases? Or is it correct either way?
Rotation starts from the bottom (the inserted node).
Let's consider having balanced all nodes up to P (included). So the subtree of P is perfectly balanced. We go to P's parent (Q). The subtree of Q is checked and (eventually) rotated. The result tree (the root may have changed if a rotation was performed) is perfectly balanced. Advance up again.
I'm trying to create a B+ tree with the following sequence,
10 20 30 40 50 60 70 80 90 100
all index nodes should have minimum of 2 and max of 3 keys. I was able to insert till 90, but as soon as insert 100 it increases the height from 2 to 3.
The problem is second child of root has one node, and I cannot fix it. It should have atleast 2, right? Can someone guide me?
UPDATE: I'm following this algorithm
If the bucket is not full (at most b - 1 entries after the insertion), add the record.
Otherwise, split the bucket.
Allocate new leaf and move half the bucket's elements to the new bucket.
Insert the new leaf's smallest key and address into the parent.
If the parent is full, split it too.
Add the middle key to the parent node.
Repeat until a parent is found that need not split.
If the root splits, create a new root which has one key and two pointers. (That is, the value that gets pushed to the new root gets removed from the original node)
P.S: I'm doing it manually, by hand, to understand the algorithm. There's no code!
I believe your B+ Tree is O.K, assuming the order of your B+ Tree is 3. If the order is m, each internal node can have ⌈m/2⌉ to m children. In your case, each internal node can have 2 to 3 children. In a B+ Tree if a node is having just 2 it children, then it requires only 1 key, so no constraints are violated by your B+ Tree.
If you are still confused, look at this B+ Tree Simulator. Try it.
To get the tree you've drawn after inserting the values 10 to 100, the Order of your tree must be 4 not 3. Otherwise the answer given is correct: order m allows m-1 keys in each leaf and each node. After that the Wikipedia description gets a bit confusing as it concentrates on children not keys, and doesn't mention what to do with rounding. Dealing with just keys, the rules are:
Max keys for all nodes = Order-1
Min keys for leaf nodes = floor(Order/2)
Min keys for internal nodes = floor(maxkeys/2)
So you are correct in having one key in the node (order=4, max=3, minleaf=2, minnode=1). You might find this page useful as it has an online JavaScript version of the processes as well as documentation of both insert and delete:
http://goneill.co.nz/btree.php