Appendix E-E Hashing – Variations

1. Modified Appendix E-E Hashing – Variations http://en.wikipedia.org/wiki/Hash_table

2. Coalesced hashing Coalesced hashing, also called coalesced chaining, is a strategy of collision resolution in a hash table that forms a hybrid of separate chaining and open addressing. Coalesced hashing uses a similar technique as separate chaining, but instead of allocating new nodes for the linked list, buckets in the actual table (not overflow area) are used. The first empty bucket in the table at the time of a collision is considered the collision bucket. When a collision occurs anywhere in the table, the item is placed in the collision bucket and a link is made between the chain and the collision bucket. Java Software Structures, 4th Edition, Lewis/Chase

3. Coalesced hashing Given a sequence "qrj," "aty," "qur," "dim," "ofu," "gcl," "rhv," "clq," "ecd," "qsu" Java Software Structures, 4th Edition, Lewis/Chase

4. Coalesced hashing The chain for "clq" is said to "coalesce" with the chain of "qrj," hence the name of the algorithm. However, the extent of coalescing is minor compared with the clustering exhibited by open addressing. For example, when coalescing occurs, the length of the chain grows by only 1, whereas in open addressing, search sequences of arbitrary length may combine. Java Software Structures, 4th Edition, Lewis/Chase

5. Coalesced hashing An important optimization, to reduce the effect of coalescing, is to restrict the address space of the hash function to only a subset of the table. For example, if the table has size M with buckets numbered from 0 to M − 1, we can restrict the address space so that the hash function only assigns addresses to the first N locations in the table. The remaining M − N buckets, called the cellar, are used exclusively for storing items that collide during insertion. No coalescing can occur until the cellar is exhausted. The optimal choice of N relative to M depends upon the load factor (or fullness) of the table. A careful analysis shows that the value N = 0.86 × M yields near-optimum performance for most load factors. Java Software Structures, 4th Edition, Lewis/Chase

6. Incremental resizing of a hash table • Some hash table implementations, notably in real-time systems, cannot pay the price of enlarging the hash table all at once, because it may interrupt time-critical operations. If one cannot avoid dynamic resizing, a solution is to perform the resizing gradually: • During the resize, allocate the new hash table, but keep the old table unchanged. • In each lookup or delete operation, check both tables. • Perform insertion operations only in the new table. • At each insertion also move r elements from the old table to the new table. • When all elements are removed from the old table, deallocate it. • To ensure that the old table is completely copied over before the new table itself needs to be enlarged, it is necessary to increase the size of the table by a factor of at least (r + 1)/r during resizing. Java Software Structures, 4th Edition, Lewis/Chase