[
https://issues.apache.org/jira/browse/LUCENE-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985407#action_12985407
]
Robert Muir commented on LUCENE-2880:
-------------------------------------
Paul I agree, I think the only way it would work is to be in Spans itself,
which is the real 'Scorer' for spanqueries. Because its wrong for SpanOrQuery
to have a getLength() really... just like it would be wrong for BooleanQuery
to know anything about phrase slops of its subqueries!
we can just leave this issue open and see what happens with
LUCENE-2878, and maybe a good solution will then be more obvious.
> SpanQuery scoring inconsistencies
> ---------------------------------
>
> Key: LUCENE-2880
> URL: https://issues.apache.org/jira/browse/LUCENE-2880
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-2880.patch
>
>
> Spinoff of LUCENE-2879.
> You can see a full description there, but the gist is that SpanQuery sums up
> freqs with "sloppyFreq".
> However this slop is simply spans.end() - spans.start()
> For a SpanTermQuery for example, this means its scoring 0.5 for TF versus
> TermQuery's 1.0.
> As you can imagine, I think in practical situations this would make it
> difficult for SpanQuery users to
> really use SpanQueries for effective ranking, especially in combination with
> non-Spanqueries (maybe via DisjunctionMaxQuery, etc)
> The problem is more general than this simple example: for example
> SpanNearQuery should be consistent with PhraseQuery's slop.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
