This preview shows pages 1–2. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: 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 wont 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.factoring in the time it takes to resize the table....
View Full Document
- Spring '11