lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: [jira] Commented: (LUCENE-395) CoordConstrainedBooleanQuery + QueryParser support
Date Thu, 06 Oct 2005 21:05:21 GMT
On Thursday 06 October 2005 22:46, Hoss Man (JIRA) wrote:
>     [
LUCENE-395?page=comments#action_12331531 ] 
> Hoss Man commented on LUCENE-395:
> ---------------------------------
> I freely admit that I didn't give a lot of thought to incrimenting maxCoord.  
I did it only because if I didn't, coordinator.coordFactor() generated 
ArrayIndexOutOfBoundsExceptions  -- it assumes that the number of counted 
matches (nrMatchers) should be used to determine which element of coordFactor 
should be used, so I assumed that maxCoord allways needed to be equal the the 
maximum number of potential counted matches.
> Likewise, I put the code in Coordinator.init() instead of 
initCountingSumScorer() for the sole reason that since i was incrimenting 
maxCoord, I needed to do it before coordFactors[] was initialized.  
(allthough, I suppose it could have happened in initCountingSumScorer(), 
prior to the call to coordinator.init()).
> Did I mention I'm way over my head as far as this patch goes? ... I don't 
honestly understand the meaning/purpose of "coordination" -- I just kind of 
did what I did because it seemed to work (and made some sense in the context 
of hte existing code).

The purpose of the coordination factor is to score higher when more
subqueries match. Requiring a minimum number of matchers
is somewhat like requiring a minimum amount of coordination.
However by default the coordination factor can be easily "overwhelmed"
by other factors.

Paul Elschot.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message