Hello Itamar, I ported the TestConstantScoreRangeQuery test - and was able to find one small bug in the ConstantScoreRangeQuery. Should I send you the files per Email? I don't know how to generate a patch but I had to modify the TestRangeFilter.cpp because it defines the base class of my test.
Jiri PS: Btw. I think I understand the constant score now: The constant score queries return always the score 1.0, but if they are used as sub-queries than the boost factor is applied and so score of their matches in deed equals to the boost factor. -----Original Message----- From: Itamar Syn-Hershko [mailto:ita...@code972.com] Sent: Thursday, August 05, 2010 8:12 PM To: clucene-developers@lists.sourceforge.net Subject: Re: [CLucene-dev] ConstantScoreQuery / ConstantWeight problem Jiri, Thanks for the detailed reports. We are following Java Lucene's implementation quite strictly. If you'll compare \search\ConstantScoreQuery.java from 2.3.2 to CLucene's code you'll see we did exactly what the original code did, except for resolving Java/C++ difference in scoping (enclosedInstance). All of ConstantWeight's members are implementations of the pure virtual declarations in Weight (SearchHeader.h). This is why normalize is being implemented (and called) for ConstantWeight as well. We initialize queryWeight and queryNorm with 0 because unlike Java, C++ needs its variables initialized (and they are not initialized with 0 by default). This is a good practice, even if it isn't really necessary in this scenario. Regarding sumOfSquaredWeights, like normalize it should be called by the searcher or similarity classes. Java Lucene doesn't set queryWeight's value on construction, so we don't do this. I compared the original Java code (from 2.3.2) with our C++ implementation and found no difference at all (except for what I documented above). So either sumOfSquaredWeights isn't being called from wherever it should be called during search, or something else is going on (another misterious Java/C++ difference?). The best way to find out whats going on is with tests. Perhaps you could start with porting TestConstantScoreRangeQuery.java to our cl_test. Also, update your local copy of master, I pushed a few updates, mainly Veit's work. Itamar. On 5/8/2010 1:02 PM, Šplíchal Jiří wrote: > Hello, > > according to the description ConstantScoreQuery should return constant score > for each document matching the supplied filter. > The score should equal the query boost. > However I always get score equal 1.0. > > I tried to investigate a little bit and I found a place where the score gets > overwritten - from the query boost value to 1.0: > it's the method ConstantWeight::normalize (constantscorequery.cpp(92)). This > method is called from Query::weight(Searcher* searcher) method > and gets as a parameter a norm. > > The norm is if using the default similarity 1/sqrt(sumOfSquaredWeights ) > which is for ConstantScoreQuery > 1/sqrt(queryWeight * queryWeight ) = 1 / queryWeight. > So queryWeight is normalized with 1 / queryWeight and it gives 1. > > So the question is, why do you normalize CONSTANT score? Shouldn't it be just > always the same value? > > By the way the class ConstantWeight is somehow strange: > - in constructor you initialize the queryWeight with 0 and not the boost > factor of the parent query. > - the queryWeight is ALWAYS initialized with boost factor of the parent query > during the sumOfSquaredWeights call, so unless you call this method > getValue returns 0, after the sumOfSquaredWeights call it returns > different value. > > Jiri > > PS: I compared the ConstantScoreQuery implementation with the newest java > lucene version - and it seems to be the same... > So am I using the ConstantScoreQuery in a bad way? > ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ CLucene-developers mailing list CLucene-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/clucene-developers ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ CLucene-developers mailing list CLucene-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/clucene-developers
