lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-8010) fix or sandbox similarities in core with problems
Date Thu, 07 Dec 2017 22:51:00 GMT


Robert Muir commented on LUCENE-8010:

Thanks for hacking on these! I can run some relevance tests on the proposed changes, if you
can wait a few days, so we have a better idea of the impact. Obviously not concerned about
nextUp/nextDown-type fixes.

> fix or sandbox similarities in core with problems
> -------------------------------------------------
>                 Key: LUCENE-8010
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
>         Attachments: LUCENE-8010.patch
> We want to support scoring optimizations such as LUCENE-4100 and LUCENE-7993, which put
very minimal requirements on the similarity impl. Today similarities of various quality are
in core and tests. 
> The ones with problems currently have warnings in the javadocs about their bugs, and
if the problems are severe enough, then they are also disabled in randomized testing too.
> IMO lucene core should only have practical functions that won't return {{NaN}} scores
at times or cause relevance to go backwards if the user's stopfilter isn't configured perfectly.
Also it is important for unit tests to not deal with broken or semi-broken sims, and the ones
in core should pass all unit tests.
> I propose we move the buggy ones to sandbox and deprecate them. If they can be fixed
we can put them back in core, otherwise bye-bye.
> FWIW tests developed in LUCENE-7997 document the following requirements:
>    * scores are non-negative and finite.
>    * score matches the explanation exactly.
>    * internal explanations calculations are sane (e.g. sum of: and so on actually compute
>    * scores don't decrease as term frequencies increase: e.g. score(freq=N + 1) >=
>    * scores don't decrease as documents get shorter, e.g. score(len=M) >= score(len=M+1)
>    * scores don't decrease as terms get rarer, e.g. score(term=N) >= score(term=N+1)
>    * scoring works for floating point frequencies (e.g. sloppy phrase and span queries
will work)
>    * scoring works for reasonably large 64-bit statistic values (e.g. distributed search
will work)
>    * scoring works for reasonably large boost values (0 .. Integer.MAX_VALUE, e.g. query
boosts will work)
>    * scoring works for parameters randomized within valid ranges

This message was sent by Atlassian JIRA

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

View raw message