Re: hashCode() for Custom classes
Roedy Green wrote:
On Fri, 18 Apr 2008 23:34:39 GMT, Mark Space
<markspace@sbc.global.net> wrote, quoted or indirectly quoted someone
who said :
As others have mentioned you should probably XOR these values together
instead of add them.
I use XOR primarily as a sort of documentation that I am actually just
combining hashcodes.
I wonder if anyone has actually thought out if XOR actually has any
advantage. I know XOR is at least as good as plus, but I am not sure
it is actually better. In theory it could be faster to compute since
there are no carries, but in actuality all modern machines would
handle them both in 1 cycle.
What about cycling through a series of multiplications by a prime (e.g., 37),
as others have suggested?
Lasse Reichstein Nielsen wrote:
The point of a hash code is not that it speeds up
equality comparison (it doesn't, equality takes the time equality takes,
hash code or not).
Rather it allows you to reduce the number of candidates for an
equality-test.
I guess then the choice is XOR vs. + for the new term in each cycle:
int hash = INITIAL_HASH ^ firstElement.hashCode();
hash = HASH_MULTIPLIER * hash ^ secondElement.hashCode();
...
hash = HASH_MULTIPLIER * hash ^ nthElement.hashCode();
What I've read suggests that the point of the multiply-add is to overflow the
32-bit int, thus performing the 'mod 2^^n ' part of the algorithm. The hash
code algorithm is numeric.
Another point is that hashes are explicitly ints, not bitmaps. It's more
natural and self-documenting to use integer operations on them.
--
Lew