A binary search tree is a binary tree storing distinct keys from a total order, with every key in a node's left subtree smaller than that node's key and every key in its right subtree larger. The condition concerns entire subtrees, not just immediate neighbours.
For membership, start at the root of a tree and compare the target with the current key. Return true on equality; continue into the left subtree for a smaller target and the right subtree for a larger target; return false on an empty subtree. The binary search tree ordering ensures that a discarded subtree cannot contain the target. Each step descends one level, so the algorithm terminates and uses time complexity for height of a binary tree , under constant-time key comparison.
First perform splaying on the key to be deleted, making its node the root of a tree. Delete that root, leaving left and right subtrees . If either is empty, return the other. Otherwise find the maximum key of by following right-child references, and perform splaying on within . This makes the root of with an empty right subtree. Attach there. The result is the original splay tree with exactly the selected key removed. An unsuccessful lookup leaves the represented set unchanged.
For algorithm correctness, all keys of are smaller than the deleted key, and all keys of are larger. Splaying preserves the binary search tree property by the permitted assumption. Since is the maximum of , it has no larger key within ; since every key of exceeds , attaching as its right subtree preserves every ordering condition. All remaining keys occur once. This is the join-based deletion of a splay tree.[ref]
No. In a red-black tree with no red nodes, equal black height forces every graph path from the root to an absent-child position to have the same length. A real node cannot have exactly one real child: the two paths through that node would then have different numbers of black nodes. Recursively, every real level must be full. The tree is therefore a perfect binary tree.
With real levels its size is . A size of would require , which is impossible for an integer . The black null sentinels are not counted among the stored entries. This is the all-black red-black tree size criterion.
Use the conventional bottom-up red-black tree insertion: insert a red node by the binary search tree rule, repair a red parent with recolouring or tree rotations, and make the root black. Write and for black and red. The first three insertions give root , with on the left and on the right.
Inserting as the left child of gives a red parent and a red uncle. Recolour black and retain a black root . Inserting then gives the inner configuration ––. A left tree rotation at , followed by a right tree rotation at , produces a subtree rooted at with and beneath it. Finally insert to the left of . Its uncle is red, so recolour black and red. No further repair is required because has black parent .
The final root is ; its left child is and its right child is . Under are on the left and on the right; has left child . All omitted children are black null sentinels. Each root-to-null graph path has two real black nodes, and no red node has a red child.
Figure 1.
The red-black tree after the six insertions, with colours also marked B and R
. Details.
Write . After splaying on , that key is at the root, and is the smallest key in its right subtree. This uses the integer assumption: no stored key lies strictly between and . Thus has an empty left subtree while it remains within the right subtree of .
Now perform ordinary bottom-up splaying on . Until the final step involving , all tree rotations occur below and leave it at the root. There are only two possible final cases.
  • If is the right child of , a single zig step rotates above , placing immediately to its left.
  • Otherwise is a grandchild of . Its parent lies in the right subtree of and must satisfy . Hence the last two directions are right then left. A zig-zag step rotates above and then above , again placing immediately to its left. A right-right final configuration is impossible because is the minimum of this subtree.
Therefore becomes the left child of . The argument applies more generally to consecutive keys in a binary search tree, even when their numerical difference is not one.
Use the usual bottom-up splaying operations. We prove the stronger result that at most three successful calls suffice. No insertions or deletions are needed.
If the chosen key is the minimum stored key, first perform splaying on and then on its immediate successor. The argument for consecutive keys in a binary search tree makes the left child of the successor with an empty right subtree; minimality makes its left subtree empty too. Hence is a leaf of a rooted tree. The maximum-key case is the mirror image.
Suppose is an interior key. Since at least four keys are stored, there are either two keys larger than or two smaller than . In the former case choose four consecutive stored keys
where is the predecessor of , and are the next two successors. Perform .
Here is a complete check of the local shapes. After the first call, is the root. After the second, is the root; every key below is in its left subtree , and every key above stays in the right subtree of . These outside subtrees cannot interfere with the next search. Between and there are only . The last step of splaying on is either a zig step, leaving as its right child; a zig-zag step, with the same result; or a zig-zig step, leaving some as its right child with immediately to the right of . Consequently the possible right subtrees of are exactly among these four forms, using for a node with its left and right subtrees:
Here an unexpanded or denotes a node with no children. Each row follows by the indicated one or two tree rotations in each bottom-up step. All rows end with as the right child of , with both its subtrees empty. If instead two keys below are available, reflect the construction, exchanging left and right and reversing the order of keys. This proves splaying a chosen node into a leaf for every node of every splay tree of size at least four.

Articles by others on the same topic (0)

There are currently no matching articles.