Assignment 10 -- due Monday, November 16 at the beginning of lab
CS 4521 Fall Semester, 2009
20 Points

Topics: B-trees, Binomial Heaps

The assignment consists of two parts:
(1) adding delete to your implementation of B-Tree operations (15 points), and
(2) writing pseudocode for the binomial heap merge operation (5 points).

Implementation of B-Tree Deletion
For the deletion operation, I followed the strategy of the text, using a non-recursive top-level routine B-Tree-Delete() that called a recursive routine B-Tree-Delete-Fullenough() (this is a common strategy for dealing with recursive routines -- to take care of special initial boundary cases). Also, in general, I found that several routines could be designed by "reading" a related routine backward. This was somewhat true of B-Tree-Delete(), which I checked by reading B-Tree-Insert() backward; here is the pseudocode:

```B-Tree-Delete(T,k)
r <- root[T]
if r = NIL or n[r] = 0 then print "Error: "Attempt to delete from empty tree."
else B-Tree-Delete-Fullenough(r,k)
if n[r] = 0 then
if leaf[r] then root[T] <- NIL
else root[T] <- c_1[r]
deallocate r
```

For B-Tree-Delete-Fullenough(), I followed the pseudocode given in the lab session. But note a couple of subtleties. First, in case 3b, there are two subcases: when ci[x] is merged with ci-1[x] or with ci+1[x]. These two cases can be handled by simply decrementing i if needed and then calling B-Tree-Merge-Children() as follows:

```       if i = n[x] + 1     |> Then we need to merge from left, not from right
then i <- i - 1
B-Tree-Merge-Children( x, i, c_i[x], c_(i+1)[x] )
```
(rather than having two separate calls to B-Tree-Merge-Children()).
Second, it isn't necessary to implement full B-Tree-Successor() and B-Tree-Predecessor() functions, since it is easy to find the successor or predecessor of an internal key by using the B-Tree-Minimum() or B-Tree-Maximum() functions. For example the successor of k is just the left-most key in the subtree to its right:
```        k' <- B-Tree-Minimum( c_(i+1)[x] )
```
and similarly, the predecessor of k is the right-most key in the subtree to its left.
Here is pseudocode for B-Tree-Minimum()
```B-Tree-Minimum(x)
while not leaf[x]
do x <- c_1[x]
return key_1[x]
```

Overall strategy for B-Tree-Delete-Fullenough()
My overall strategy to implement B-Tree-Delete-Fullenough() was to implement and test case 1 (and "case 0") first, then the "find the predecessor/successor" cases 2a and 2b, then the "merge" of case 2c (also used in case 3b), then the "borrow-left" and "borrow-right" subcases of case 3a, and finally the "merge" of case 3b.

As I have mentioned, the "borrow-left" operation is sort of like the "rotate" operation used in red-black trees (I think that the split-child and merge-children operations could be mostly performed by a sequence of "borrow" operations also, so in that sense split and merge are kinds of "super-rotates"). The pseudocode for B-Tree-Borrow-Left() is below; the steps in B-Tree-Borrow-Right() are similar.

```
B-Tree-Borrow-Left( x, i )
y <- c_(i-1)[x]  |> rename left child to simplify pseudocode
z <- c_i[x]      |> rename child to simplify pseudocode
shift all keys (and child pointers if not leaf[z]) up one index
|> in node z to make room for one more key and child pointer
increment n[z]
key_1[z] <- key_(i-1)[x]       |> "rotate" keys
key_(i-1)[x] <- key_(n[y])[y]  |>
c_1[z] <- c_(n[y]+1)[y]        |> and move a child pointer into z
decrement n[y]
```

Implementation of B-Tree-Merge-Children()
The B-Tree-Merge-Children() operation is similar to B-Tree-Split-Child(). As in B-Tree-Split-Child(), to simplify the pseudocode, let y = ci[x], and z = ci+1[x], where it is assumed that both y and z have t-1 keys. Here is the pseudocode:

```B-Tree-Merge-Children( x, i, y, z )
copy the t-1 keys of z into the top t-1 key positions of y
if not leaf[y] then
copy the t child pointers of z into the top t child pointer positions of y
key_t[y] <- key_i[x]   |> move the splitting key down to y
n[y] <- 2t - 1         |> y is now a full node

shift the keys from index i+1 to n[x] down one index in node x
shift the child pointers from index i+2 to n[x]+1 down one index in node x
decrement n[x]         |> since it has lost its splitting key

deallocate z
```

Hints: In the previous assignment, near the end, there is some Helpful code, and some useful pseudocode.

Testing:

Run your implementation on the test files: treetest3, treetest4, treetest5, and treetest6.
Note that treetest6 for this assignment was generated using random numbers, so there are a number of duplicate keys, both for insert and delete. The implementation discussed above and in the text can handle duplicates, so just insert any duplicate keys. That way when you delete any duplicate keys, each will be deleted and you won't generate any "search key not found" messages. The result of treetest6, should have the keys 133 and 357 in its root.

What To Hand In:

1. Clearly marked scripts of treetest3 through treetest6 which test deletion. Outline the nodes and draw the child pointers by hand on your output.
2. Well documented code for your B-tree implementation.
3. Do Exercise 19.2-1 page 471: Write pseudocode for Binomial-Heap-Merge() called in line 2 of the Binomial-Heap-Union() algorithm on page 463 of the text. This is basically a linked list merge operation, similar to the array merge operation of merge-sort.

### Extra Credit (up to 3 points)

For cases 2a and 2b of the delete operation, implement the finding and deleting of k', the successor or predecessor of k, in a single downward pass, then replace k by k' (the pseudocode presented in the lab required two passes and could require even more if there were duplicate keys). In your writeup and/or on your code, carefully explain how your strategy works. Also, implement Disk-Read() and Disk-Write(), inserting calls to them at appropriate places in your code. Disk-Read() and Disk-Write() should just increment the counters numDiskReads and numDiskWrites respectively. Report the number of disk accesses needed for each downward pass.

Page URL: http://www.d.umn.edu /~ddunham/cs4521f09/assignments/a10/assignment.html
Page Author: Doug Dunham