10.2 AVL Treeelearning.kocw.net/KOCW/document/2013/youngnam/YoungTak...Advanced Networking Tech. Lab. Yeungnam University (YU -ANTL) O-O Programming & Data Structure DS 10 - 1 Prof

Advanced Networking Tech. Lab. Yeungnam University (YU-ANTL)

O-O Programming & Data Structure Prof. Young-Tak Kim DS 10 - 1

10.2 AVL Tree

AVL trees are balanced An AVL Tree is a binary search tree such that for every

internal node v of T, the heights of the children of v can differ by at most 1

An example of an AVL tree where the heights are shown next to the nodes



Height of an AVL Tree

Fact: The height of an AVL tree storing n keys is O(log n).

Proof: Let us bound n(h): the minimum number of internal nodes of an AVL tree of height h. We easily see that n(1) = 1 and n(2) = 2 For n > 2, an AVL tree of height h contains the root node,

one AVL subtree of height n-1 and another of height n-2. That is, n(h) = 1 + n(h-1) + n(h-2) Knowing n(h-1) > n(h-2), we get n(h) > 2n(h-2). So

n(h) > 2n(h-2), n(h) > 4n(h-4), n(h) > 8n(n-6), … (by induction), n(h) > 2in(h-2i)

Solving the base case we get: n(h) > 2 h/2-1

Taking logarithms: h < 2log n(h) +2 Thus the height of an AVL tree is O(log n)

3

4 n(1)

n(2)



Update Operations

Insertion An example insertion of an entry with key 54 search-and-repair to restore the balance



Trinode Restructuring

Algorithm resturcture(x)

Algorithm restructure(x): Input: A node x of a binary search tree T that has both a parent y

and a grandparent z Output: Tree T after a trinode restructuring (which corresponds to a

single or double rotation) involving nodes x, y, and z 1: Let (a,b,c) be a left-to-right (inorder) listing of the nodes x, y, and z,

and let (T0,T1,T2,T3) be a left-to-right (inorder) listing of the four subtrees of x, y, and z rooted at x, y, or z.

2: Replace the subtree rooted at z with a new subtree rooted at b. 3: Let a be the left child of b and let T0 and T1 be the left and right

subtrees of a, respectively. 4: Let c be the right child of b and let T2 and T3 be the left and right

subtrees of c, respectively.



Trinode Restructuring (1)

let (a,b,c) be an inorder listing of x , y, z perform the rotations needed to make b the topmost node

of the three



Trinode Restructuring (2)

double rotation: RL, LR



Update Operation - Removal

Removal begins as in a binary search tree, which means the node removed will become an empty external node. Its parent, w, may cause an imbalance.

Example:

Fig. 10. 8 Before removal



Rebalancing after a Removal

Let z be the first unbalanced node encountered while travelling up the tree from w. Also, let y be the child of z with the larger height, and let x be the child of y with the larger height

We perform restructure(x) to restore balance at z As this restructuring may upset the balance of another node

higher in the tree, we must continue checking for balance until the root of T is reached

44

17

78 50

88 48

62

54

w

c=x

b=y

a=z

44

17

78

50 88

48

62

54



Performance of AVL Trees

Performance of an n-entry map realized by an AVL tree



C++ Implementation of an AVL Tree

AVLEntry

template <typename E> class AVLEntry : public E { // an AVL entry private:

int ht; // node height protected: // local types

typedef typename E::Key K; // key type typedef typename E::Value V; // value type int height() const { return ht; } // get height void setHeight(int h) { ht = h; } // set height

public: // public functions AVLEntry(const K& k = K(), const V& v = V()) // constructor : E(k,v), ht(0) { } friend class AVLTree<E>; // allow AVLTree access

};



class AVLTree (1) template <typename E> // an AVL tree class AVLTree : public SearchTree< AVLEntry<E> > { public: // public types

typedef AVLEntry<E> AVLEntry; // an entry typedef typename SearchTree<AVLEntry>::Iterator Iterator; // an iterator

protected: // local types typedef typename AVLEntry::Key K; // a key typedef typename AVLEntry::Value V; // a value typedef SearchTree<AVLEntry> ST; // a search tree typedef typename ST::TPos TPos; // a tree position

public: // public functions AVLTree(); // constructor Iterator insert(const K& k, const V& x); // insert (k,x) void erase(const K& k) throw(NonexistentElement); // remove key k entry void erase(const Iterator& p); // remove entry at p

protected: // utility functions int height(const TPos& v) const; // node height utility void setHeight(TPos v); // set height utility bool isBalanced(const TPos& v) const; // is v balanced? TPos tallGrandchild(const TPos& v) const; // get tallest grandchild void rebalance(const TPos& v); // rebalance utility

};



class AVLTree (2) template <typename E> // constructor AVLTree<E>::AVLTree() : ST() { } template <typename E> // node height utility int AVLTree<E>::height(const TPos& v) const {

return (v.isExternal() ? 0 : v->height()); } template <typename E> // set height utility void AVLTree<E>::setHeight(TPos v) {

int hl = height(v.left()); int hr = height(v.right()); v->setHeight(1 + std::max(hl, hr)); // max of left & right

} template <typename E> // is v balanced? bool AVLTree<E>::isBalanced(const TPos& v) const {

int bal = height(v.left()) - height(v.right()); return ((-1 <= bal) && (bal <= 1));

}



class AVLTree (3) template <typename E> // get tallest grandchild

typename AVLTree<E>::TPos AVLTree<E>::tallGrandchild(const TPos& z) const { TPos zl = z.left(); TPos zr = z.right(); if (height(zl) >= height(zr)) // left child is taller if (height(zl.left()) >= height(zl.right())) return zl.left(); // left-left grand child else return zl.right(); // left-right grand child else // right child taller if (height(zr.right()) >= height(zr.left())) return zr.right(); // right-right grand child else return zr.left(); // right-left grand child

}



class AVLTree (4)

template <typename E> // rebalancing utility void AVLTree<E>::rebalance(const TPos& v) {

TPos z = v; while (!(z == ST::root())) { // rebalance up to root

z = z.parent(); setHeight(z); // compute new height if (!isBalanced(z)) { // restructuring needed

TPos x = tallGrandchild(z); z = restructure(x); // trinode restructure setHeight(z.left()); // update heights setHeight(z.right()); setHeight(z);

} }

}



class AVLTree (5)

template <typename E> // insert (k,x) typename AVLTree<E>::Iterator AVLTree<E>::insert(const K& k, const V& x) {

TPos v = inserter(k, x); // insert in base tree setHeight(v); // compute its height rebalance(v); // rebalance if needed return Iterator(v);

} template <typename E> // remove key k entry void AVLTree<E>::erase(const K& k) throw(NonexistentElement) {

TPos v = finder(k, ST::root()); // find in base tree if (Iterator(v) == ST::end()) // not found?

throw NonexistentElement("Erase of nonexistent"); TPos w = eraser(v); // remove it rebalance(w); // rebalance if needed

}



class AVLTree (6) template <typename E>

typename AVLTree<E>::AVLTPos AVLTree<E>::restructure(const AVLTPos& v) // tri-node restructure throw(BoundaryViolation) { AVLTPos c = v; AVLTPos b = c.parent(); // parent AVLTPos a = b.parent(); // grandParent AVLTPos gp = a; AVLTPos ggp = a.parent(); // grandGrandParant AVLTreeRestructures++; K a_k = a.pTN->entry.key(); K b_k = b.pTN->entry.key(); K c_k = c.pTN->entry.key(); if (a_k > b_k) // L { if (b_k > c_k) // *c < *b < *a : LL { AVLTPos br; // right child of b b.pTN->parent = a.pTN->parent; a.pTN->left = br.pTN = b.pTN->right; b.pTN->right = a.pTN; a.pTN->parent = b.pTN; c.pTN->parent = b.pTN; br.pTN->parent = a.pTN;

c

b

a

cL cR

bR

aR

b

a c

cL cR bR aR



class AVLTree (7) if (ggp.pTN->left == gp.pTN)

ggp.pTN->left = b.pTN; else if (ggp.pTN->right == gp.pTN) ggp.pTN->right = b.pTN; else { cout << "Error in resturcture : wrong pointers in grand-grand parent for Entry (“; cout <<v.pTN->entry.value() << "!!" << endl; } return b; } else { // *b < *c < *a : LR AVLTPos cr, cl; // right child and left child of c c.pTN->parent = a.pTN->parent; a.pTN->left = cr.pTN = c.pTN->right; b.pTN->right = cl.pTN = c.pTN->left; c.pTN->right = a.pTN; c.pTN->left = b.pTN; b.pTN->parent = c.pTN; a.pTN->parent = c.pTN; cr.pTN->parent = a.pTN; cl.pTN->parent = b.pTN; if (ggp.pTN->left == gp.pTN) ggp.pTN->left = c.pTN; else if (ggp.pTN->right == gp.pTN) ggp.pTN->right = c.pTN; else { cout << "Error in resturcture : wrong pointers in grand-grand parent for Entry (“; cout <<v.pTN->entry.value() << "!!" << endl; } return c; }

c

a b

bL cL cR aR

a

b

bL

aR c

cR cL



class AVLTree (8) } else { // *a < * b : R

if (b_k < c_k){ // *a < *b < *c : RR AVLTPos bl; // left child of b b.pTN->parent = a.pTN->parent; a.pTN->right = bl.pTN = b.pTN->left; b.pTN->left = a.pTN; a.pTN->parent = b.pTN; c.pTN->parent = b.pTN; bl.pTN->parent = a.pTN; if (ggp.pTN->left == gp.pTN) ggp.pTN->left = b.pTN; else if (ggp.pTN->right == gp.pTN) ggp.pTN->right = b.pTN; else { cout << "Error in resturcture : wrong pointers in grand-grand parent for Entry (“; cout <<v.pTN->entry.value() << "!!" << endl; } return b; }

c

b

a

cR cL

bL

aL

b

c a

aL bL cL cR



class AVLTree (9) else { // *a < *c < *b : RL

AVLTPos cr, cl; // right child and left child of c c.pTN->parent = a.pTN->parent; a.pTN->right = cl.pTN = c.pTN->left; b.pTN->left = cr.pTN = c.pTN->right; c.pTN->left = a.pTN; c.pTN->right = b.pTN; a.pTN->parent = c.pTN; b.pTN->parent = c.pTN; cl.pTN->parent = a.pTN; cr.pTN->parent = b.pTN; if (ggp.pTN->left == gp.pTN) ggp.pTN->left = c.pTN; else if (ggp.pTN->right == gp.pTN) ggp.pTN->right = c.pTN; else { cout << "Error in resturcture : wrong pointers in grand-grand parent for Entry (“; cout <<v.pTN->entry.value() << "!!" << endl; } return c; } }

c

b a

aL cL cR bR

a

b

bR

aL c

cL cR



main.cpp (1) /** main.cpp */ #include <iostream> #include "Planet.h" #include "Entry.h" #include "SearchTree.h" #include "SearchTree.cpp" #include "LinkedBinaryTree.h" #include "LinkedBinaryTree.cpp" #include "Planet.h" #include "Exceptions.h" #include "AVLTree.h" #include "AVLTree.cpp" #include "AVLEntry.h" #define NUM_PLANETS 9 void main() { Planet *pSolarPlanets; int *planetIDs; pSolarPlanets = new Planet[NUM_PLANETS];



main.cpp (2) /** main.cpp (2) */ Planet solarPlanets[] = { Planet(1, "Mercury", 0.0558, 57.9), Planet(2, "Venus", 0.815, 108), Planet(3, "Earth",1.0, 150), Planet(4, "Mars", 0.107, 228), Planet(5, "Jupiter", 318, 778), Planet(6, "Saturn", 95.1, 1430), Planet(7, "Uranus", 14.5, 2870), Planet(8, "Neptune", 17.2, 4500), Planet(9, "Pluto", 0.11, 5900) }; for (int i=0; i<NUM_PLANETS; i++) { cout << "SolarPlanet[" << i << "]: " << solarPlanets[i] << endl; } cout <<" Inserting planets to Planet AVL Tree ..." << endl; AVLTree<Entry<int, Planet>> planetAVLTree; planetAVLTree.setAVLTreeRestructures(0); for (int i=0; i<NUM_PLANETS; i++) { planetAVLTree.insert(i, solarPlanets[i]); planetAVLTree.printAVLTree(); } cout << "Total AVLTree-Restructures: " << planetAVLTree.getAVLTreeRestructures() << endl; }



Example of Execution in Rebalancing in AVL Tree



10.3 Splay Trees

Splay Tree A splay tree is a self-adjusting binary search tree with the additional

property that recently accessed elements are quick to access again. It performs basic operations such as insertion, look-up and removal in O(log n) amortized time. For many sequences of non-random operations, splay trees perform better than other search trees, even when the specific pattern of the sequence is unknown. The splay tree was invented by Daniel Dominic Sleator and Robert Endre Tarjan in 1985.[1]

All normal operations on a binary search tree are combined with one basic operation, called splaying. Splaying the tree for a certain element rearranges the tree so that the element is placed at the root of the tree. One way to do this is to first perform a standard binary tree search for the element in question, and then use tree rotations in a specific fashion to bring the element to the top. Alternatively, a top-down algorithm can combine the search and the tree reorganization into a single phase.

http://en.wikipedia.org/wiki/Binary_search_tree

http://en.wikipedia.org/wiki/Big_O_notation

http://en.wikipedia.org/wiki/Amortized_analysis

http://en.wikipedia.org/wiki/Daniel_Dominic_Sleator

http://en.wikipedia.org/wiki/Robert_Endre_Tarjan

http://en.wikipedia.org/wiki/Tree_rotation



Splaying splay x by moving x to the root of T through a sequence of restructuring

splay tree splay tree is a binary search tree where a node is splayed after it is

accessed (for a search or update) deepest internal node accessed is splayed splaying costs O(h), where h is height of the tree – which is still O(n)

worst-case – O(h) rotations, each of which is O(1)



Zig-Zig : The node x and its parent y are both left children or both right children. We replace z by x, making y a child of x and z a child of y, while

maintaining the in-order relationships of the nodes in T.



zig-zag: One of x and y is a left child and the other is a right child. In this case, we replace z by x and make x have y and z as its children,

while maintaining the in-order relationships of the nodes in T.



zig: x does not have a grandparent (or we are not considering x’s

grandparent for some reason). In this case, we rotate x over y, making x’s children be the node y and

one of x’s former children w, in order to maintain the relative inorder relationships of the nodes in T.



Example of splaying a node (Fig. 10.16)



When to splay (1) When searching for key k, if k is found at a node x, we splay x, else we

splay the parent of the external node at which the search terminates unsuccessfully. For example, the splaying in Figures 10.16 and 10.17 would be performed after searching successfully for key 14 or unsuccessfully for key 14.5.

When inserting key k, we splay the newly created internal node where k gets inserted. For example, the splaying in Figures 10.16 and 10.17 would be performed if 14 were the newly inserted key. We show a sequence of insertions in a splay tree in Figure 10.18.



When to splay (2) When deleting a key k, we splay the parent of the node w that gets

removed, that is, w is either the node storing k or one of its descendents. (Recall the removal algorithm for binary search trees.) An example of splaying following a deletion is shown in Figure 10.19.



Performance of Splay Trees

Recall: rank of a node is logarithm of its size. Thus, amortized cost of any splay operation is

O(log n) In fact, the analysis goes through for any

reasonable definition of rank(x) This implies that splay trees can actually adapt to

perform searches on frequently-requested items much faster than O(log n) in some cases



10.4 (2, 4) Trees

Multi-way Search Trees multi-way trees are defined so that each internal node can have

many children Let v be a node of an ordered tree. We say that v is a d-node if v

has d children. We define a multi-way search tree to be an ordered tree T

that has the following properties, which are illustrated in Figure 10.1(a): Each internal node of T has at least two children. That is, each

internal node is a d-node such that d ≥ 2. Each internal d-node v of T with children v1, . . . ,vd stores an ordered

set of d−1 key-value entries (k1,x1), . . ., (kd−1,xd−1), where k1 ≤ ··· ≤ kd−1. Let us conventionally define k0 = −∞ and kd = +∞. For each entry (k,x)

stored at a node in the subtree of v rooted at vi, i = 1, . . . ,d, we have that ki−1 ≤ k ≤ ki.



A multi-way search tree is an ordered tree such that Each internal node has at least 2 children and stores d −1 key-

element items (ki, oi), where d is the number of children For a node with children v1 v2 … vd storing keys k1 k2 … kd−1 keys in the subtree of v1 are less than k1 keys in the subtree of vi are between ki−1 and ki (i = 2, …, d − 1) keys in the subtree of vd are greater than kd−1

The leaves store no items and serve as placeholders

11 24

2 6 8 15

30

27 32



Multi-Way Inorder Traversal We can extend the notion of inorder traversal from binary trees to multi-

way search trees Namely, we visit item (ki, oi) of node v between the recursive traversals

of the subtrees of v rooted at children vi and vi + 1 An inorder traversal of a multi-way search tree visits the keys in

increasing order

11 24

2 6 8 15

30

27 32

1 3 5 7 9 11 13 19

15 17

2 4 6 14 18

8 12

10

16



Multi-Way Searching

Similar to search in a binary search tree A each internal node with children v1 v2 … vd and

keys k1 k2 … kd−1 k = ki (i = 1, …, d − 1): the search terminates successfully k < k1: we continue the search in child v1 ki−1 < k < ki (i = 2, …, d − 1): we continue the search in child vi k > kd−1: we continue the search in child vd

Reaching an external node terminates the search unsuccessfully

Example: search for 30

11 24

2 6 8 15

30

27 32



Searching in a multi-way tree

search path for key 12

search path for key 24



(2,4) Trees

A (2,4) tree (also called 2-4 tree or 2-3-4 tree) is a multi-way search with the following properties Node-Size Property: every internal node has at most 4 children Depth Property: all the external nodes have the same depth

Depending on the number of children, an internal node of a (2,4) tree is called a 2-node, 3-node or 4-node



Height of a (2,4) Tree

Theorem: A (2,4) tree storing n items has height O(log n) Proof: Let h be the height of a (2,4) tree with n items Since there are at least 2i items at depth i = 0, … , h − 1 and no items at

depth h, we have n ≥ 1 + 2 + 4 + … + 2h−1 = 2h − 1

Thus, h ≤ log (n + 1)

Searching in a (2,4) tree with n items takes O(log n) time

1

2

2h−1

0

items 0

1

h−1

h

depth



Update Operations for (2, 4) Trees - Insertion

We insert a new item (k, x) at the parent v of the leaf reached by searching for k We preserve the depth property but We may cause an overflow (i.e., node v may become a 5-node)

Example: inserting key 30 causes an overflow

27 32 35

10 15 24

2 8 12 18

10 15 24

2 8 12 27 30 32 35 18

v

v



Overflow and Split

We handle an overflow at a 5-node v with a split operation: let v1 … v5 be the children of v and k1 … k4 be the keys of v node v is replaced nodes v' and v" v' is a 3-node with keys k1 k2 and children v1 v2 v3 v" is a 2-node with key k4 and children v4 v5

key k3 is inserted into the parent u of v (a new root may be created)

The overflow may propagate to the parent node u

15 24

12 27 30 32 35 18 v

u

v1 v2 v3 v4 v5

15 24 32

12 27 30 18 v'

u

v1 v2 v3 v4 v5

35 v"



Fig. 10.22 – Node Split (a) overflow at a 5-node v; (b) the third key of v inserted into the parent u of v; (c) node v replaced with a 3-node v′ and a 2-node v′′.



Fig. 10.23 – A sequence of insertion into (2, 4) tree (a) initial tree with one entry; (b) insertion of 6; (c) insertion of 12; (d) insertion of 15, which causes an overflow; (e) split, which causes the creation of a new root node; (f) after the split;



Fig. 10.23 – A sequence of insertion into (2, 4) tree (g) insertion of 3; (h) insertion of 5, which causes an overflow; (i) split; (j) after the split;



Fig. 10.23 – A sequence of insertion into (2, 4) tree (k) insertion of 10; (l) insertion of 8.



Fig. 10.24 – An insertion in a (2, 4) tree that causes a cascading split


O-O Programming & Data Structure Prof. Young-Tak Kim DS 9- 46

Analysis of Insertion

Algorithm insert (k , e) 1. We search for key k to

locate the insertion node v

2. We add the new entry (k , e) at node v

3. while overflow (v) if isRoot(v) create a new empty root

above v v ← split(v)

Let T be a (2,4) tree with n items Tree T has O(log n) height Step 1 takes O(log n) time

because we visit O(log n) nodes

Step 2 takes O(1) time Step 3 takes O(log n) time

because each split takes O(1) time and we perform O(log n) splits

Thus, an insertion in a (2,4) tree takes O(log n) time



Removal

We reduce deletion of an entry to the case where the item is at the node with leaf children

Otherwise, we replace the entry with its inorder successor (or, equivalently, with its inorder predecessor) and delete the latter entry

Example: to delete key 24, we replace it with 27 (inorder successor)

27 32 35

10 15 24

2 8 12 18

32 35

10 15 27

2 8 12 18



Underflow and Fusion

Deleting an entry from a node v may cause an underflow, where node v becomes a 1-node with one child and no keys

To handle an underflow at node v with parent u, we consider two cases

Case 1: the adjacent siblings of v are 2-nodes Fusion operation: we merge v with an adjacent sibling w and move an

entry from u to the merged node v' After a fusion, the underflow may propagate to the parent u

9 14

2 5 7 10

u

v 9

10 14

u

v' w 2 5 7



Underflow and Transfer

To handle an underflow at node v with parent u, we consider two cases

Case 2: an adjacent sibling w of v is a 3-node or a 4-node Transfer operation: 1. we move a child of w to v 2. we move an item from u to v 3. we move an item from w to u After a transfer, no underflow occurs

4 9

6 8 2

u

v w 4 8

6 2 9

u

v w



A sequence of removal from a (2, 4) tree (a) removal of 4, causing an underflow; (b) a transfer operation; (c) after the transfer operation; (d) removal of 12, causing an underflow;



Fig. 10. 25 - A sequence of removal from a (2, 4) tree (e) a fusion operation; (f) after the fusion operation; (g) removal of 13; (h) after removing 13.



Fig. 10.26 – A propagating sequence of fusions in a (2, 4) tree (a) removal of 14, which causes an underflow; (b) fusion, which causes another underflow; (c) second fusion operation, which causes the root to be removed; (d) final tree.



Analysis of Deletion

Let T be a (2,4) tree with n items Tree T has O(log n) height

In a deletion operation We visit O(log n) nodes to locate the node from which

to delete the entry We handle an underflow with a series of O(log n)

fusions, followed by at most one transfer Each fusion and transfer takes O(1) time

Thus, deleting an item from a (2,4) tree takes O(log n) time



Comparison of Map Implementations

find insert remove Notes

Hash Table 1 expected

1 expected

1 expected

o no ordered map methods o simple to implement

Skip List log n high prob.

log n high prob.

log n high prob.

o randomized insertion o simple to implement

AVL and (2,4) Tree

log n worst-case

log n worst-case

log n worst-case

o complex to implement

Documents

10.2 AVL Treeelearning.kocw.net/KOCW/document/2013/youngnam/YoungTak...Advanced Networking Tech. Lab. Yeungnam University (YU -ANTL) O-O Programming & Data Structure DS 10 - 1 Prof