The pseudocode for rehashing is as follows:
for each bucket b:
for each element e in b:
put e into the new array
Given that the two outer loops are nested, why is the naive runtime analysis (Take 1 from the lecture video) \(O(C + n^2)\) instead of \(O(Cn^2)\)?
What collision resolution scheme would you use if you need pretty fast runtime but have a very strict memory budget, and why?
What’s the minimum and maximum load factor of a hash table that uses open addressing for collision resolution?
Here’s the pseudocode for put
with open addressing using linear probing that we saw in class:
put(key):= hash(key);
h while A[h] is full:
= (h+1) % N
h = value A[h]
Notice that we know to stop searching when we encounter an empty bucket. What could go wrong if we naively remove
a value from our table by simply setting its bucket to empty? Can you devise a scheme to solve this problem?
Suppose that you want to print a tabular representation of a hashmap as you did in Exercise 3. But now, you need to guarantee that keys are printed in the order they were added to the map. Can you do this with a hash map such as the one we’ve described? If so, give pseudocode. If not, can you think of a way to modify the hash map to make this is possible.
Suppose the set of possible keys to be stored in your hash table is known ahead of time; it has size \(K\), and you have access to all \(K\) keys. Given O(n) time and space to perform some initial setup, can you devise an approach that will have worst-case O(1) hash table operations? You should assume that you have enough memory to have a table size \(C\) such that \(K/C\) is a constant.