Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Date: Sun, 19 Nov 2006 12:34:07 -0800 (PST)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: java-user@lucene.apache.org
Subject: Re: Boost Document
In-Reply-To: <359a92830611180752o7fae0074j5a057c9ae05fbdf0@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0611191222340.6468@hal.rescomp.berkeley.edu>
References: <7405959.post@talk.nabble.com>
  <Pine.LNX.4.58.0611171040310.30605@hal.rescomp.berkeley.edu>
  <7417101.post@talk.nabble.com>
 <359a92830611180752o7fae0074j5a057c9ae05fbdf0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: with scoring.  Each time you index a document, it get a doc id greater than
: any already in the index, and they get reassigned if you delete docs and
: optimize.... They *may* be used when scoring to break ties but that doesn't
: do you any good.......

they aren't really used to break ties -- that implies there is code
somewhere that deliberately wants the order to be deterministic and when
it sees two identicle scores, then does a sort on docid.  In reality, the
fact that docs come back in docid order is just a side effect of the fact
that the Scorers iterate over documents in order and that the sorting code
generates a "stable sort"

Looking at why the scores are teh same...

: > ----- DOC 222-----home-
: >   40960.0 = fieldNorm(field=WORD, doc=0)

: > ----- DOC 111-----home-
: > 40960.0 = fieldWeight(WORD:home in 1), product of:
: >   40960.0 = fieldNorm(field=WORD, doc=1)

: > > :             doc1.setBoost(3163);

: > > :             doc2.setBoost(3150);

...norms (which is where field and doc boosts go) get encoded as a single
byte, so they loose a lot of precision, unfortunately the methods used to
translate from float->byte->float aren't subclassable (see
Similarity.encodeNorm) if you write a bit of test code to call those
mehtods on various values and see what you'll get you'll notice that
bigger numbers are more affected then smaller numbers, so you may wnat to
just use smaller boosts (ie: divide by 100) and see if that helps.

alternately: stop using boosts to approach this problem, add these numbers
as a new field, and use the FunctionQuery class from Solr to achieve your
goal (search the list archives for more detailed Discussions of
FunctionQuery)


-Hoss


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