Algorithms and Data Structures

More documents

Recommendations

Info

N.Wirth. Algorithms and Data Structures. Oberon version 170 p.right := p2.left; p2.left := p; IF p2.bal = +1 THEN p.bal := -1 ELSE p.bal := 0 END; IF p2.bal = -1 THEN p1.bal := 1 ELSE p1.bal := 0 END; p := p2; p2.bal := 0 END END END balanceL; PROCEDURE balanceR (VAR p: Node; VAR h: BOOLEAN); VAR p1, p2: Node; BEGIN (*h; right branch has shrunk*) IF p.bal = 1 THEN p.bal := 0 ELSIF p.bal = 0 THEN p.bal := -1; h := FALSE ELSE (*bal = -1, rebalance*) p1 := p.left; IF p1.bal x THEN delete(x, p.left, h); IF h THEN balanceL(p, h) END ELSIF p.key < x THEN delete(x, p.right, h); IF h THEN balanceR(p, h) END
N.Wirth. Algorithms and Data Structures. Oberon version 171 ELSE (*delete p^*) q := p; IF q.right = NIL THEN p := q.left; h := TRUE ELSIF q.left = NIL THEN p := q.right; h := TRUE ELSE del(q.left, h); IF h THEN balanceL(p, h) END END END END delete Fortunately, deletion of an element in a balanced tree can also be performed with — in the worst case — O(log n) operations. An essential difference between the behaviour of the insertion and deletion procedures must not be overlooked, however. Whereas insertion of a single key may result in at most one rotation (of two or three nodes), deletion may require a rotation at every node along the search path. Consider, for instance, deletion of the rightmost node of a Fibonacci-tree. In this case the deletion of any single node leads to a reduction of the height of the tree; in addition, deletion of its rightmost node requires the maximum number of rotations. This therefore represents the worst choice of node in the worst case of a balanced tree, a rather unlucky combination of chances. How probable are rotations, then, in general? The surprising result of empirical tests is that whereas one rotation is invoked for approximately every two insertions, one is required for every five deletions only. Deletion in balanced trees is therefore about as easy — or as complicated — as insertion. 4.6 Optimal Search Trees So far our consideration of organizing search trees has been based on the assumption that the frequency of access is equal for all nodes, that is, that all keys are equally probable to occur as a search argument. This is probably the best assumption if one has no idea of access distribution. However, there are cases (they are the exception rather than the rule) in which information about the probabilities of access to individual keys is available. These cases usually have the characteristic that the keys always remain the same, i.e., the search tree is subjected neither to insertion nor deletion, but retains a constant structure. A typical example is the scanner of a compiler which determines for each word (identifier) whether or not it is a keyword (reserved word). Statistical measurements over hundreds of compiled programs may in this case yield accurate information on the relative frequencies of occurrence, and thereby of access, of individual keys. Assume that in a search tree the probability with which node i is accessed is Pr {x = k i } = p i , (Si: 1 ≤ i ≤ n : p i ) = 1 We now wish to organize the search tree in a way that the total number of search steps - counted over sufficiently many trials - becomes minimal. For this purpose the definition of path length is modified by (1) attributing a certain weight to each node and by (2) assuming the root to be at level 1 (instead of 0), because it accounts for the first comparison along the search path. Nodes that are frequently accessed become heavy nodes; those that are rarely visited become light nodes. The (internal) weighted path length is then the sum of all paths from the root to each node weighted by that node's probability of access. P = Si: 1 ≤ i ≤ n : p i * h i h i is the level of node i. The goal is now to minimize the weighted path length for a given probability distribution. As an example, consider the set of keys 1, 2, 3, with probabilities of access p 1 = 1/7, p 2 = 2/7 and p 3 = 4/7. These three keys can be arranged in five different ways as search trees (see Fig. 4.36).
Page 1 and 2:
Algorithms and Data Structures © N
Page 3 and 4:
N.Wirth. Algorithms and Data Struct
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120: N.Wirth. Algorithms and Data Struct
Page 169: N.Wirth. Algorithms and Data Struct
Page 211: N.Wirth. Algorithms and Data Struct
show all

Algorithms and Data Structures

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?