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

[EMAIL PROTECTED] edited comment on LUCENE-914 at 9/8/08 4:20 AM:
-------------------------------------------------------------

I had another look at these lines in DisjunctionScorer.skipTo()  from 
LUCENE-413:
{code}
    if (target <= currentDoc) { // CHECKME: skipTo() semantics?
      return true;
    }
{code}
I think these lines can simply be dropped. The bug at LUCENE-413 was probably 
fixed
by the changes to SpanScorer then.

Dropping these lines also makes DisjunctionSumScorer advance (effectively use 
next())
when skipTo(target) is called, even when target <= doc().

Also, I'm changing my opinion on what to do when target <= doc(). I think a 
DocIdSetIterator
(and any Scorer) should always advance in that case, just like the javadocs of 
TermDocs.

When Scorers/DocIdSetIterators are combined, for example in disjunctions or 
conjunctions
or in the more complex cases of BooleanScorer2, the test for target <= doc() 
can simply
be done before calling skipTo() on any of the combined 
Scorers/DocIdSetIterators.

Now, if such a change surfaces some bugs like LUCENE-413, so be it. It's better 
to have
clearly defined semantics than to have lingering bugs due to explicitly 
undefined semantics
in the case of target <= doc().

Btw. there is a small bug in SpanScorer, the (freq != 0) test there should
be replaced by a boolean check for actual matches. See 
SpanScorer.setFreqCurrentDoc().
The bug would only surface when the Similarity used in SpanScorer returns 0 for 
sloppyFreq().


      was (Author: [EMAIL PROTECTED]):
    I had another look at these lines in DisjunctionScorer.skipTo()  from 
LUCENE-413:
{code}
    if (target <= currentDoc) { // CHECKME: skipTo() semantics?
      return true;
    }
{code}
I think these lines can simply be dropped. The bug at LUCENE-413 was probably 
fixed
by the changes to SpanScorer then.

Dropping these lines also makes DisjunctionSumScorer advance (effectively use 
next())
when skipTo(target) is called, even when target <= doc().

Also, I'm changing my opinion on what to do when target <= doc(). I think a 
DocIdSetIterator
(and any Scorer) should always advance in that case, just like the javadocs of 
TermDocs.

When Scorers/DocIdSetIterators are combined, for example in disjunctions or 
conjunctions
or in the more complex cases of BooleanScorer2, the test for target <= doc() 
can simply
be done before calling skipTo() on any of the combined 
Scorers/DocIdSetIterators.

Now, if such a change surfaces some bugs like LUCENE-413, so be it. It's better 
to have
clearly defined semantics than to have lingering bugs due to explicitly 
undefined semantics
in the case of target <= doc().

Btw. such a change would leave a small bug in SpanScorer, the (freq != 0) test 
there should
be replaced by a boolean check for actual matches. See 
SpanScorer.setFreqCurrentDoc().
The bug would only surface when the Similarity used in SpanScorer returns 0 for 
sloppyFreq().

  
> Scorer.skipTo(current) remains on current for some scorers
> ----------------------------------------------------------
>
>                 Key: LUCENE-914
>                 URL: https://issues.apache.org/jira/browse/LUCENE-914
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Search
>            Reporter: Doron Cohen
>            Priority: Minor
>         Attachments: lucene-914.patch
>
>
> Background in http://www.nabble.com/scorer.skipTo%28%29-contr-tf3880986.html
> It appears that several scorers do not strictly follow the spec of 
> Scorer.skipTo(n), and skip to current location remain in current location 
> whereas the spec says: "beyond current". 
> We should (probably) either relax the spec or fix the implementations.

-- 
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]

Reply via email to