Re: svn commit: r178059 - /lucene/java/trunk/src/java/org/apache/lucene/search/spans/SpanNearQuery.java

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r178059 - /lucene/java/trunk/src/java/org/apache/lucene/search/spans/SpanNearQuery.java

Erik Hatcher

On May 24, 2005, at 3:05 AM, Paul Elschot wrote:

>> +  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.

Ok, those adjustments are fine.  I let IDEA generate the .hashCode  
method in this case and left it at that - but I'll modify it with  
your suggestions.

Thanks,
     Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

I want to skip scoring of Hits

kapilChhabra
1. My application requires documents to be sorted on one of my indexed
fields everytime.
I use the hits.setSort() method to specify the field.
In short my application will never use the scores generated by lucene
search.
Is calculating scores a overhead? Can I skip the process somehow?

Regards,
Kapil


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Can we handle this?

kapilChhabra
In reply to this post by Erik Hatcher

let C = A or B

In a normal scenario, if A is true the value of B is not checked and C
is set to true. The value of B is checked only if A is false.

I guess this is not what lucene does as it has to calculate the score
for the document. Am i right?

If yes, I there any way I can do it using the normal scenario?

Thanks in anticipation.

Regards,
kC






---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r178059 - /lucene/java/trunk/src/java/org/apache/lucene/search/spans/SpanNearQuery.java

Paul Elschot
In reply to this post by Erik Hatcher
On Tuesday 24 May 2005 09:05, Paul Elschot wrote:

> Erik,
>
> On Tuesday 24 May 2005 03:35, [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]