lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <paul.elsc...@xs4all.nl>
Subject Re: svn commit: r178059 - /lucene/java/trunk/src/java/org/apache/lucene/search/spans/SpanNearQuery.java
Date Wed, 25 May 2005 07:36:40 GMT
On Tuesday 24 May 2005 09:05, Paul Elschot wrote:
> Erik,
> 
> On Tuesday 24 May 2005 03:35, ehatcher@apache.org wrote:
> > Author: ehatcher
> > Date: Mon May 23 18:35:13 2005
> ....
> > +  /** Returns true iff <code>o</code> is equal to this. */
> > +  public boolean equals(Object o) {
> > +    if (this == o) return true;
> > +    if (o == null || getClass() != o.getClass()) return false;
> > +
> > +    final SpanNearQuery spanNearQuery = (SpanNearQuery) o;
> > +
> > +    if (inOrder != spanNearQuery.inOrder) return false;
> > +    if (slop != spanNearQuery.slop) return false;
> > +    if (!clauses.equals(spanNearQuery.clauses)) return false;
> > +    if (!field.equals(spanNearQuery.field)) return false;
> > +
> > +    return true;
> > +  }
> > +  
> > +  public int hashCode() {
> > +    int result;
> > +    result = clauses.hashCode();
> > +    result = 29 * result + slop;
> 
> How about:
>  result += slop * 29;
> 
> > +    result = 29 * result + (inOrder ? 1 : 0);
> 
>  result +=  (inOrder ? 1 : 0); // or some other constants larger than 1
> 
> > +    result = 29 * result + field.hashCode();
> 
>  result ^= field.hashCode(); // bitwise exclusive or
> 
> > +    return result;
> > +  }
> >  }
> 
> ?
> The idea is to preserve and use as many of the earlier bits
> as possible. Multiplying by a large number by 29 can loose 4-5 
> of the original high bits.

Thanks for the commit. 

On second thoughts I'm not so sure
that bits are actually lost by multiplying by 29,
so I'm sorry for bringing this up too soon.

Multiplying by 32 would definitely loose the 5 high bits.
Multiplying by 29 is roughly the same as:

(r << 4) + (r << 3) + (r<<2) + (r<<0)

16         + 8           + 4          + 1            (for r == 1)

The last term keeps the low bits in the low position.

I'd have to dive in the theory of  bit randomness to verify
that multiplying by 29 does not loose bits, but this
last term could well indicate that no bits are lost.

Given that the code is generated I would also suppose that
enough care has been taken in designing the code
to produce a good hash.

Regards,
Paul Elschot.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message