lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Repeatability of results
Date Thu, 05 Apr 2012 00:10:10 GMT
On Wed, Apr 4, 2012 at 4:18 PM, Michael McCandless
<> wrote:
> On Wed, Apr 4, 2012 at 6:15 PM, Alan Bawden <> wrote:
>> The key observation is that the differences in scores we see are always
>> down around the sixth decimal place -- down where 32-bit floating point
>> loses precision.

---->8 snip 8<----

> But, Lucene generally scores one document at a time, so in theory just
> changing its docid shouldn't alter the order of float operations.

Could this be an excess floating point precision problem?

    Fix excess precision problem affecting SortCollector on x86 platforms.
    Before this patch, scores which should have tied did not because the float
    score which came from the method call Matcher_Score() would have too much
    precision compared to the score which had been stored and then retrieved
    from the MatchDoc.  This could manifest as unpredictable sort orders for
    multi-level sorts incorporating scores.


    I'd like to welcome the newest members of the bug 323 community, where all
    x87 floating point errors in gcc come to die!

Marvin Humphrey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message