When we first attempt create our web applications, most of us use a common printing phrase which starts with Lorem Ipsum words in our templates. Today while I was reading something in the Django documentation, and surprisingly I came across with this very useful module. Honestly, I didn’t even know Django has such a thing. After seeing this module, I again thought about how much I love Django :)

If you want to file something away for later retrieval, it can be faster if you file it numerically rather than by a long alphabetic key. A hashCode is a way of computing a small (32-bit) digest numeric key from a long String or even an arbitrary clump of bytes. The numeric key itself is meaningless and the hashCode functions for computing them can look a bit insane. However, when you go to look for something, you can do the same digest calculation on the long alphabetic key you are looking for, and no matter how bizarre an algorithm you used, you will calculate the same hashCode, and will be able to look up numerically with it. Of course there is always the possibility two different Strings will have the same digest hashCode. However, even then, all is not lost; it greatly narrows down the search, hence speeding it up. A Hashtable goes a step further, scrunching down the hashCode even further to an even smaller number that it can use to directly index an array, usually by dividing it by some (ideally prime) number and taking the remainder.

I saw this introduction in one of the site that I was surfing. The main idea of hashing was exactly this. In Java 1.0.x and 1.1, String.hashCode function was working by sampling every nth character. However, this was slowing down the Hashtable lookup. With Java 1.2, function has been improved to multiply the result by 31 then add the next character in sequence. This was much slower, but much secure to avoid the collisions. For Object.hashCode things were almost same. Then Sun came up with a much wider spec which 1.4 implementation made sense after.