Implementing Hash Code

Question

Hi all!
I found myself implementing hashCode and equals methods for a class, and googled a little bit looking for a good implementation.
I found that the most used is this one:
public int hashCode() {
            final int prime = 31;
            int result = 1;
            result = prime * result + ((Int1 == null) ? 0 : Int1.hashCode());
            result = prime * result + ((Int2 == null) ? 0 : Int2.hashCode());
            result = prime * result + ((Int3 == null) ? 0 : Int3.hashCode());
            result = prime * result + ((Int4 == null) ? 0 : Int4.hashCode());
            result = prime * result + ((Int5 == null) ? 0 : Int5.hashCode());
            result = prime * result + ((Int6 == null) ? 0 : Int6.hashCode());
            result = prime * result + ((Int7 == null) ? 0 : Int7.hashCode());
            return result;
      }Actually, this exact code was generated automatically by Eclipse tools for a test class I made.
What I found alarming, is that, in such an implementation, that prime variable, is multiplied by itself in every row!
This is what result equation would look like:
result = prime^7 + prime^6*Int7.hashCode() + prime^5*Int6.hashCode() + ... (where prime^n means a power).
And, translating it into numbers, we have that:
result > prime^7 = 31^7 = 27,512,614,111 > 2,147,483,647 = MAX VALUE OF JAVA PRIMITIVE INT!!!!
I don’t want to think about classes with 10 or 20 fields!!
I’m not sure about how java faces a value over its maximum, but, anyway I think that, over 6 fields, this implementation is a bit “HEAVY” for an int hashCode…
Obviously, you can change the 31 for a lower prime, but don’t think there would be much difference in that.
These would be the maximum valid number of fields for the corresponding primes:
31 – 6
29 – 6
23 – 6
19 – 7
17 – 7
13 – 8
A part from that, although it covers pretty fast the whole int range, there's no consistency about collisions, so it's far form being a "perfect" hash code ( an utopic hash code implementation that returns a unique value for each different instance of a class ).
So, thinking about a better implementation I came into this:
public int hashCode() {
            double result = Math.pow(2,((Int1 == null) ? 0 : Int1.hashCode()));
            result *= Math.pow(3,((Int1 == null) ? 0 : Int1.hashCode()));
            result *= Math.pow(5,((Int1 == null) ? 0 : Int1.hashCode()));
            result *= Math.pow(7,((Int1 == null) ? 0 : Int1.hashCode()));
            result *= Math.pow(11,((Int1 == null) ? 0 : Int1.hashCode()));
            result *= Math.pow(13,((Int1 == null) ? 0 : Int1.hashCode()));
            result *= Math.pow(17,((Int1 == null) ? 0 : Int1.hashCode()));
            return (int) result;
      }but I guess that, although there would be absolutely no collision its cost would be too much for optimizing hash tables searches.
So, what do you think about it?
Or better...Does anyone thought of it before? and Did you get into a better implementation?
Thanx, and good programming!

Answer 1

Well, let me explain...
And I don't know what exactly you mean by "HEAVY".I meant in terms of size of the value. Obviously, what I suggested is really a lot more expensive ( in temps of computation costs ), but it was only an example that guarantees unicity.
The algorithm you describe is widely used and usually considered to be the best general-purpose algorithm that can be applied to pretty much all classes.Chapter 3 of Effective Java (= the go-to-place for information on equals() and hashCode()) also describes that algorithm. >
Well, that's what I've seen, that this is the most commonly accepted algoritm, but what I wonder is why it is so common, and which is its Mathmatical consitency.
If you have a look at the expression I wrote, there's absolutelly no control over the unicity of that algoritm. Off course this is not a problem, as it fits the hash code contract, returning different values for different elements, but, I question why to make such a "big" product when there's plenty of collisions anyway!
Look at what you refered:
>
"The multiplication in step 2.b makes the hash value depend on the order of the
fields, which results in a much better hash function if the class contains multiple
similar fields. For example, if the multiplication were omitted from a String hash
function built according to this recipe, all anagrams would have identical hash
codes. The multiplier 37 was chosen because it is an odd prime. If it was even and
the multiplication overflowed, information would be lost because multiplication
by two is equivalent to shifting. The advantages of using a prime number are less
clear, but it is traditional to use primes for this purpose.""The multiplication in step 2.b makes the hash value depend on the order of the
fields, which results in a much better hash function if the class contains multiple
similar fields. For example, if the multiplication were omitted from a String hash
function built according to this recipe, all anagrams would have identical hash
codes. The multiplier 37 was chosen because it is an odd prime. If it was even and
the multiplication overflowed, information would be lost because multiplication
by two is equivalent to shifting. The advantages of using a prime number are less
clear, but it is traditional to use primes for this purpose.">
Even here it is said that there's absolutely no consistent reason for taking such an approach! (or, at least, I don't see it).
For example, in case of the class I was talking about, take a look at this:
public int hashCode() {
            int result = 2 * ((Int1 == null) ? 0 : Int1.hashCode());
            result += 3 * ((Int2 == null) ? 0 : Int2.hashCode());
            result += 5 * ((Int3 == null) ? 0 : Int3.hashCode());
            result += 7 * ((Int4 == null) ? 0 : Int4.hashCode());
            result += 11 * ((Int5 == null) ? 0 : Int5.hashCode());
            result += 13 * ((Int6 == null) ? 0 : Int6.hashCode());
            result += 17 * ((Int7 == null) ? 0 : Int7.hashCode());
            return result;
      }I really haven't calculated it, but I suspect that number of collisions would be equivalent to the given by the other algoritm, and its values would remain smaller than in the other case.
In fact, you could even change the prime numbers for the Integers succession: 2,3,4,5,6,7....
So, my question is...Why that algoritm? Which are the advatages of an algoritm that works with such a Big values?
thanks!