[jira] [Commented] (LUCENE-7968) AnalyzingSuggester's comparator compares incorrectly

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (LUCENE-7968) AnalyzingSuggester's comparator compares incorrectly

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16164001#comment-16164001 ]

Robert Muir commented on LUCENE-7968:

From what I can tell, since the stuff going into the FST (analyzed form, costs) is still in-order in this case, nothing detected it.

The surface forms are stored in a big byte[], so by being out of order it means suggester's results just come back in a bizarre order when there are ties on both the analyzed form and costs (rather than in fact being sorted by surface form).

E.G. if you used a stemmer and added both {{dog (cost=2)}} and {{dogs (cost=2)}}, suggester might sometimes return {{dog}} first, other times {{dogs}}.

> AnalyzingSuggester's comparator compares incorrectly
> ----------------------------------------------------
>                 Key: LUCENE-7968
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7968
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
>         Attachments: LUCENE-7968.patch
> Found by LUCENE-7966, but we should fix here separate.
> Currently the tie-break case of this comparator is buggy when {{hasPayloads=false}}, as it assigns *negative* lengths to the BytesRefs being compared. The current BytesRef.compareTo simply silently returns false in this case, hiding the bug.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]