On Wed, Apr 4, 2012 at 4:18 PM, Michael McCandless
<luc...@mikemccandless.com> wrote:
> On Wed, Apr 4, 2012 at 6:15 PM, Alan Bawden <a...@basistech.com> 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?
http://www.rectangular.com/cgi-bin/viewvc.cgi?view=rev&root=kinosearch&revision=6277
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.
Also:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c92
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: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
