Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
From: Paul Elschot <paul.elschot@xs4all.nl>
To: lucene-dev@jakarta.apache.org
Subject: Re: Boolean Scorer
Date: Sat, 11 Dec 2004 23:04:40 +0100
User-Agent: KMail/1.5.4
References: 
 <E3381E0825F1954D953A4E347017BB1C02BF14BB@reh001-1.REX001.ExchangeByRegister.com>
In-Reply-To: 
 <E3381E0825F1954D953A4E347017BB1C02BF14BB@reh001-1.REX001.ExchangeByRegister.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200412112304.40685.paul.elschot@xs4all.nl>

Chuck,

On Friday 10 December 2004 23:12, Chuck Williams wrote:
> Paul,
> 
> Would there be a way to get the best of both worlds?  E.g., could you
> factor the specializable score combination differently, so that one
> method was called with each new score to generate a state entity, while
> a final method computed the score from the state.  For both sum and max,
> the state entity could just be a float, not requiring an array.  The
> final operation for the sum with coord case would do the coord.  I
> haven't looked at the code carefully enough to see if this actually
> works, but it seemed worth mentioning.

It's simple enough to do some abstract method call instead of initializing
a sum or adding to it. The problem is that as long as such a call is not
effectively inlined by the JVM, it will cause a performance hit for the sum
case.

The latest version of the advanceAfterCurrent method that computes the
score is java protected. It can be overridden to make the best
of it in another world.

Regards,
Paul Elschot


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