[
https://issues.apache.org/jira/browse/LUCENE-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985347#action_12985347
]
Robert Muir commented on LUCENE-2880:
-------------------------------------
thinking about this one, for this to really work correctly with the current
setup (e.g. with SpanOrQuery),
this length might have to be in the Spans class...
but with LUCENE-2878 we nuke this class, so we can keep the issue open to think
about how
the slop should be computed for these queries, i think just using the end -
start is not the best.
> 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]
