[
https://issues.apache.org/jira/browse/LUCENE-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16442798#comment-16442798
]
Adrien Grand commented on LUCENE-8249:
--------------------------------------
I like this approach better. I have some questions/notes:
- The implementation of {{MatchesIterator#term}} feels wrong. Should remove
that method or make it return a list of terms?
- I think {{PhraseMatcher#minFreq()}} should actually be called {{maxFreq}},
since it tries to give an upper bound of the frequency of this phrase?
- Is the implementation of {{SloppyPhraseMatcher#minFreq}} right? A single
term position can be used for two phrase positions with slops? For instance I
suspect that if you search for a phrase of two synonyms with a large slop, you
end up with a phrase frequency that is larger than the frequency of any
synonym? Maybe we should also make this a float rather than an int, it might
have potential to be greater than an int?
- I'm wondering whether we can simplify ExactPhraseMatcher to not have its
lead iterator being one position ahead all the time? This would eg. allow to
remove the {{if (exposeOffset)}} trick to remember the start offset.
- Should we try to implement freq() on top of the matchers? It's a bit weird
that it consumes the iterator when called.
> Add matches to exact PhraseQuery and MultiPhraseQuery
> -----------------------------------------------------
>
> Key: LUCENE-8249
> URL: https://issues.apache.org/jira/browse/LUCENE-8249
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Priority: Major
> Attachments: LUCENE-8249.patch, LUCENE-8249.patch
>
>
> ExactPhraseScorer can be rejigged fairly easily to expose a MatchesIterator
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
