Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 59165 invoked from network); 6 Oct 2005 21:05:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Oct 2005 21:05:48 -0000 Received: (qmail 81992 invoked by uid 500); 6 Oct 2005 21:05:46 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 81954 invoked by uid 500); 6 Oct 2005 21:05:45 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 81943 invoked by uid 99); 6 Oct 2005 21:05:45 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2005 14:05:45 -0700 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [194.109.24.32] (HELO smtp-vbr12.xs4all.nl) (194.109.24.32) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2005 14:05:48 -0700 Received: from k8l.lan (porta.xs4all.nl [80.127.24.69]) by smtp-vbr12.xs4all.nl (8.13.3/8.13.3) with ESMTP id j96L5MGe026847 for ; Thu, 6 Oct 2005 23:05:22 +0200 (CEST) (envelope-from paul.elschot@xs4all.nl) From: Paul Elschot To: java-dev@lucene.apache.org Subject: Re: [jira] Commented: (LUCENE-395) CoordConstrainedBooleanQuery + QueryParser support Date: Thu, 6 Oct 2005 23:05:21 +0200 User-Agent: KMail/1.5.4 References: <971190521.1128631608302.JavaMail.jira@ajax.apache.org> In-Reply-To: <971190521.1128631608302.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510062305.21974.paul.elschot@xs4all.nl> X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org