Moving this to devel...
Andriy,
As you may have noticed I relied on HashCodeBuilder in the new
implementation . The main reason was to have a generic implementation
for all kinds of values in the map... Those can realistically be
Strings, Numbers, BigDecimal, byte[], Date (yikes!), etc. Do you think
it is worthwhile revisiting this? BTW, since ObjectId is immutable, I
am caching a hashCode computed on demand during the first call to
"hashCode()"
Andrus
On Thursday, October 23, 2003, at 03:36 AM, Andriy Shapochka wrote:
> Exactly so, and for arrays of Objects it is true as well.
> Don't know whether it helps but for arrays the following hashing and
> equality algorithms may be used (taken from the Trove docs, see my
> earlier
> posting):
>
> public int computeHashCode(Object o) {
> char[] c = (char[])o;
> // use the shift-add-xor class of string hashing functions
> // cf. Ramakrishna and Zobel, "Performance in Practice of
> String
> Hashing Functions"
> int h = 31; // seed chosen at random
> for (int i = 0; i < c.length; i++) { // could skip
> invariants
> h = h ^ ((h << 5) + (h >> 2) + c[i]); // L=5, R=2
> works well
> for ASCII input
> }
> return h;
> }
>
> public boolean equals(Object o1, Object o2) {
> char[] c1 = (char[])o1;
> char[] c2 = (char[])o2;
> if (c1.length != c2.length) { // could drop this check for
> fixed-length keys
> return false;
> }
> for (int i = 0, len = c1.length; i < len; i++) { // could
> skip
> invariants
> if (c1[i] != c2[i]) {
> return false;
> }
> }
> return true;
> }
>
> Pretty sure, byte[] can use the same numbers for hashing. Whether the
> distribution of hash key values generated by this algorithm better
> than that
> in Apache Commons' HashCodeBuilder or not is difficult to say, it
> should
> work faster
> though.
>
This archive was generated by hypermail 2.0.0 : Thu Oct 23 2003 - 11:35:09 EDT