On Thursday 06 October 2005 22:46, Hoss Man (JIRA) wrote: > [ http://issues.apache.org/jira/browse/ 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. Regards, Paul Elschot. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
