title: Why Don't Hash Tables for Strings Simply Use This Collision-Less Function? (included below)
body: <p>So I have a collision-less hash function (a very simple one) and I'm wondering why collision-less hash functions like this aren't used. I'm guessing that the reason must be that it takes up too much space or something, but I'd like to know the real answer.</p>
  
  <p>Here's the function:</p>
  
  <p>If you have a word w composed of n+1 characters ß<sub>n</sub> ß<sub>n-1</sub> ... ß<sub>1</sub> ß<sub>0</sub>, then define the hash function </p>
  
  <p><b>H(w) = 26<sup>n</sup> * ß<sub>n</sub> + 26<sup>n-1</sup> * ß<sub>n-1</sub> + ... + 26 * ß<sub>1</sub> + ß<sub>0</sub>.</b></p>
  
  <p>where, for instance, a = 1, b = 2, c = 3, ..., z = 26.</p>
  
  <p>This function has no collisions, as it defines a one-to-one mapping between a String and the integers.</p>
  
  <p>The issue of course is that as the length of the word increases, the hash code becomes very large.</p>
  
  <p>A possible solution to this would be: split up long words and make each hash code a vector, with the second element pointing to the rest of the word (which in turn could point to another part of the word if it was split up more than once).</p>
  
  <p>So my question is: why is this not implemented? Was the extra cost of memory not worth avoiding collisions? Was this method found to be poor for another reason? <del>Am I the first one to think of doing it this way?</del> (Just kidding about that last one.)</p>