Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 1 May 2009 14:59:33 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: java-user@lucene.apache.org
Subject: Re: lucene score and float precision
In-Reply-To: <4655F93B69E345CB9B187A7C5C09AC6A@perazin>
Message-ID: <Pine.LNX.4.64.0905011452550.17125@radix.cryptio.net>
References: <4655F93B69E345CB9B187A7C5C09AC6A@perazin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: in some cases we have the problem that for a document the ScoreDoc score
: differs at the last digit of the float from the score reported by the
: explanation functionality of lucene. For example: 
: 
: ScoreDoc: 16.770466 -- Explanation: 16.770468 = (MATCH) sum of: ...
: ScoreDoc: 21.118656 -- Explanation: 21.118654 = (MATCH) sum of: ...
: 
: The explanation function reports a score as expected, compared to the other
: results of the search, while the ScoreDoc score is a bit to low or to high. 
: 
: Does anyone have an idea? 

The nature of an Explanation object is that it gets built up using a code 
path that keeps track of all the intermediate values while computing a 
score for a single document, while the actaul score is typically generated 
using a differnet code path that can be optimized for speed.  the 
different code paths might be mathematicly equivilent, but if the order of 
operations is different, floating point truncation errors could result in 
slightly differnet scores (ie: "(a/b)*c" is in theory equal to "(a*c)/b" 
but in practice minor iscrepencies can be introduced)

This is why the tests for Excplanations use CheckHits.EXPLAIN_SCORE_TOLERANCE_DELTA


-Hoss


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