6.006 Intro to Algorithms
Recitation 07
February 25, 2011
Resizing Hash Tables
Hash tables perform well if the number of elements in the table remain proportional to the size of
the table. If we know exactly how many inserts/deletes are going to be performed on a table, we
would be able to set the table size appropriately at initialization. However, it is often the case that
we won’t know what series of operations will be performed on a table. We must have a strategy
to deal a various number of elements in the hash table while preserving an average
O
(1)
access,
insertion, and removal operations.
To restrict the load balance so that it does not get too large (slow search, insert, delete) or too
small (waste of memory), we will increase the size of the hash table if it gets too full and decrease
the size of the hash table if it gets too empty.
Resizing a hash table consists of choosing a new hash function to map to the new size, creating
a hash table of the new size, iterating through the elements of the old table, and inserting them into
the new table.
Consider a hash table that resolves collisions using the chaining method. We will double the
size of the hash table whenever we make an insert operation that results in the load balance exceed
ing 1, i.e.
n > m
. We will halve the size of the hash table whenever we make a delete operation
that results in the load balance falling beneath
1
4
, i.e.
n <
m
4
. In the next sections, we will analyze
this approach and show that the average runtime of each insertion and deletion is still
O
(1)
, even
factoring in the time it takes to resize the table.
This preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
This is the end of the preview.
Sign up
to
access the rest of the document.
 Spring '11
 byrns
 Math, hash function

Click to edit the document details