2. Illustrate the C program to represents the Stack Implementation on POP and PUSH operation. Ans: 2 #include<studio.h> #include<conio.

h> #define Max 5 Int Staff [Max], top=-1; Void display() { If ((top==-1 || (top==0)) { Printf(\n stack is full\n); } Else { Printf(\n stack elements are\n); For(int i=top-1;i>=0;i--) } } void push() { int ele; char ch; it(top-=-1) top=0; do { If (top>=5) { Printf(\n stack is full); Break; } Else { Clrscr(); Printf(\n enter the element to be insearted\n); Scanf(%d, &ele); Staff(top++)=ele display(); } Printf(\n Do u want to add more elements:?\n); Scanf(\n%c, &ch); } While ((ch==y ||(ch==Y)); } void pop() { If ((top==-1)||(top==0)

{ Printf(\nstack is under flow\n); } Else { Printf(%d is deleted fro stack\n,Staff(--top]); display(); } } Void main() { clrscr(); char c; int choice; do { cirscr(); printf(\n enter the choice\n); printf(1->push\n); printf(2-pop\n); scant(%d, &choice); if(choice==1) push(); elshif(choice==2) pop(); else printf(\in valid choice); printf(\n do u want to continue:?); scanf(\n%c, &c); } While{(c==y)||(c==Y)); }

3. Show the result of inserting 3, 1, 4, 5, 2, 9, 6, 8 into a a) b) Bottom-up splay tree. Top-down splay tree.

Ans: 3 Splay Trees We shall describe the algorithm by giving three rewrite rules in the form of pictures. In these pictures, x is the node that was accessed (that will eventually be at the root of the tree). By looking at the local structure of the tree defined by x, xs parent, and xs grandparent we decide which of the following three rules to follow. We continue to apply the rules until x is at the root of the tree:

Notes 1) Each rule has a mirror image variant, which covers all the cases.

2) The zig-zig rule is the one that distinguishes splaying from just rotating x to the root of the tree. 3) Top-down splaying is much more efficient in practice.

The Basic Bottom-Up Splay Tree

achieved. We use rotations such as weve seen before. The zig case. Let X be a non-root node on the access path on which we are rotating. If the parent of X is the root of the tree, we merely rotate X and the root as shown in Figure 2.

Figure 2 Zig Case

This is the same as a normal single rotation. The zig-zag case. In this case, X and both a parent P and a grandparent G. X is a right child and P is a left child (or vice versa).

This is the same as a double rotation. This is shown in Figure 3. The zig-zig case. This is a different rotation from those we have previously seen. Here X and P are either both left children or both right children. The transformation is shown in Figure 4. This is different from the rotate-to-root. Rotate-to-root rotates between X and P and then between X and G. The zig-zig splay rotates between P and G and X and P.

Figure 4 Zig-zig Case

Given the rotations, consider the example in Figure 5, where we are splaying c.

Top-Down Splay Trees

nodes that are on the access path, and move them and their subtrees out of the way. We must also perform some tree rotations to guarantee the amortized time bound. At any point in the middle of a splay, we have: The current node X that is the root of its subtree. Tree L that stores nodes less than X. Tree R that stores nodes larger than X.
Initially, X is the root of T, and L and R are empty.

As we descend the tree two levels at a time, we encounter a pair of nodes. Depending on whether these nodes are smaller than X or larger than X, they are placed in L or R along with subtrees that are not on the access path to X. When we finally reach X, we can then attach L and R to the bottom of the middle tree, and as a result X will have been moved to the root. We now just have to show how the nodes are placed in the different tree. This is shown below:

Zig-Zig Figure

Zig-Zag Figure

4. Discuss the techniques for allowing a hash file to expand and shrink dynamically. What are the advantages and disadvantages of each? Ans: 4 Dynamic Hashing: As the database grows over time, we have three options: 1. Choose hash function based on current file size. Get performance degradation as file grows. 2. Choose has function based on anticipated file size. Space is wasted initially. 3. Periodically re-organize hash structure as file grows. Requires selecting new hash function, recomputing all addresses and generating new bucket assignments. Some hashing techniques allow the hash function to be modified dynamically to accommodate the growth or shrinking of the database. These are called dynamic hash functions. Extendable hashing is one form of dynamic hashing. Extendable hashing splits and coalesces buckets as database size changes.

Figure 11.9: General extendable hash structure.

We choose a hash function that is uniform and random that generates values over a relatively large range. Range is b-bit binary integers (typically b=32). is over 4 billion, so we don't generate that many buckets! Instead we create buckets on demand, and do not use all b bits of the hash initially. At any point we use i bits where . The i bits are used as an offset into a table of bucket addresses. Value of i grows and shrinks with the database. Figure 11.19 shows an extendable hash structure.

Note that the i appearing over the bucket address table tells how many bits are required to determine the correct bucket. It may be the case that several entries point to the same bucket. All such entries will have a common hash prefix, but the length of this prefix may be less than i. So we give each bucket an integer giving the length of the common hash prefix. This is shown in Figure 11.9 (textbook 11.19) as . Number of bucket entries pointing to bucket j is then : .

To find the bucket containing search key value

Compute

Take the first i high order bits of . Look at the corresponding table entry for this i-bit string. Follow the bucket pointer in the table entry.

We now look at insertions in an extendable hashing scheme.

Follow the same procedure for lookup, ending up in some bucket j. If there is room in the bucket, insert information and insert record in the file. If the bucket is full, we must split the bucket, and redistribute the records. If bucket is split we may need to increase the number of bits we use in the hash.

Two cases exist: 1. If

, then only one entry in the bucket address table points to bucket j. Then we need to increase the size of the bucket address table so that we can include pointers to the two buckets that result from splitting bucket j. We increment i by one, thus considering more of the hash, and doubling the size of the bucket address table. Each entry is replaced by two entries, each containing original value. Now two entries in bucket address table point to bucket j. We allocate a new bucket z, and set the second pointer to point to z. Set and to i. Rehash all records in bucket j which are put in either j or z. Now insert new record. It is remotely possible, but unlikely, that the new hash will still put all of the records in one bucket. If so, split again and increment i again. , then more than one entry in the bucket address table points to bucket j. Then we can split bucket j without increasing the size of the bucket address table (why?).

2. If

Note that all entries that point to bucket j correspond to hash prefixes that have the same value on the leftmost bits. We allocate a new bucket z, and set and to the original value plus 1. Now adjust entries in the bucket address table that previously pointed to bucket j. Leave the first half pointing to bucket j, and make the rest point to bucket z. Rehash each record in bucket j as before. Reattempt new insert.

Note that in both cases we only need to rehash records in bucket j. Deletion of records is similar. Buckets may have to be coalesced, and bucket address table may have to be halved. Insertion is illustrated for the example deposit file of Figure 11.20.

32-bit hash values on bname are shown in Figure 11.21. An initial empty hash structure is shown in Figure 11.22. We insert records one by one. We (unrealistically) assume that a bucket can only hold 2 records, in order to illustrate both situations described. As we insert the Perry ridge and Round Hill records, this first bucket becomes full. When we insert the next record (Downtown), we must split the bucket. Since , we need to increase the number of bits we use from the hash. We now use 1 bit, allowing us buckets. This makes us double the size of the bucket address table to two entries. We split the bucket, placing the records whose search key hash begins with 1 in the new bucket, and those with a 0 in the old bucket (Figure 11.23). Next we attempt to insert the Redwood record, and find it hashes to 1. That bucket is full, and . So we must split that bucket, increasing the number of bits we must use to 2. This necessitates doubling the bucket address table again to four entries (Figure 11.24). We rehash the entries in the old bucket. We continue on for the deposit records of Figure 11.20, obtaining the extendable hash structure of Figure 11.25.

Advantages:

Extendable hashing provides performance that does not degrade as the file grows. Minimal space overhead - no buckets need be reserved for future use. Bucket address table only contains one pointer for each hash value of current prefix length.

Disadvantages:

Extra level of indirection in the bucket address table.