[
https://issues.apache.org/jira/browse/LUCENE-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985388#action_12985388
]
Paul Elschot commented on LUCENE-2880:
--------------------------------------
The getLength() method may not be straightforward.
Does the getLength() method in SpanQuery also work in the nested case when
there is an spanOr over two spanQueries of different length?
It may be necessary to add this length to Spans because of this.
Some reasons for a negative match length:
- multiple terms indexed at the same position,
- span distance queries with the same subqueries.
I wish I had a good solution for this, but I did not find one yet.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
