title: Can hash tables really be O(1)?
body: <p>It seems to be common knowledge that hash tables can achieve O(1), but that has never made sense to me.  Can someone please explain it? Here are two situations that come to mind:</p>
  
  <p>A.  <strong>The value is an int smaller than the size of the hash table.</strong> Therefore, the value is its own hash, so there is no hash table. But if there was, it would be O(1) and still be inefficient.</p>
  
  <p>B.  <strong>You have to calculate a hash of the value.</strong> In this situation, the order is O(n) for the size of the data being looked up.  The lookup might be O(1) after you do O(n) work, but that still comes out to O(n) in my eyes.</p>
  
  <p>And unless you have a perfect hash or a large hash table, there are probably several items per bucket. So, it devolves into a small linear search at some point anyway.</p>
  
  <p>I think hash tables are awesome, but I do not get the O(1) designation unless it is just supposed to be theoretical.</p>
  
  <p>Wikipedia's <a href="http://en.wikipedia.org/wiki/Hash_table" rel="noreferrer">article for hash tables</a> consistently references constant lookup time and totally ignores the cost of the hash function.  Is that really a fair measure?</p>
  
  <hr>
  
  <p><strong>Edit:</strong> To summarize what I learned:</p>
  
  <ul>
  <li><p>It is technically true because the hash function is not required to use all the information in the key and so could be constant time, and because a large enough table can bring collisions down to near constant time.</p></li>
  <li><p>It is true in practice because over time it just works out as long as the hash function and table size are chosen to minimize collisions, even though that often means not using a constant time hash function.</p></li>
  </ul>