lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean
Date Tue, 19 May 2009 07:08:45 GMT

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

Shai Erera commented on LUCENE-1614:
------------------------------------

bq. A bigger question though, is if we should support skipTo(doc) where doc<=current at
all

I don't think we should support it and it wasn't the intention in the first place. If we do
want to support it than a different name for the method is required, such as seek(target)
or moveTo(target).

bq. Funny, but this is actually closer to "skip to" than "advance", since under this proposal,
the iterator would not always advance.

I actually don't see it like that. skipTo and advance both imply that the iterator moves forward
(as opposed to seek). However I don't think that when you say "advance to X" it means the
iterator should move. The result of that command should put the iterator on X or beyond (if
X does not exist). If the iterator is already on X, I don't think it should do anything.

bq. An implementation certainly shouldn't be required to carry state such that skipTo(10)
called twice will yield different results.

I'm not sure if by that you agree with me or disagree (maybe I'm misreading it). From the
iterators I've modified already, calling skipTo(10) multiple times always yields the same
result. Those are the ones that operate on BitSet. They never check their state, but just
skip to wherever they're requested.

In case you disagree, I'd like to ask why is it bad to request the implementation to remember
its state? I think that all implementations already store the doc Id in case doc() will be
called following skipTo, so in a sense they already remember their state. In addition, checking
if the current doc Id is not the target is something I believe most will do - if they don't
need to, like the bit-set variants, then they don't do it. If they cannot really skip to a
target, but are forced to call next() until target is reached, they already check their state
and so it does not add any overhead.

To me, calling skipTo or advance with the same target multiple times and get different result
every time is weird. I'd like to change that semantic, but if you strongly disagree, then
we should at least document it.

> Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead
of boolean
> ----------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1614
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1614
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Shai Erera
>             Fix For: 2.9
>
>
> See http://www.nabble.com/Another-possible-optimization---now-in-DocIdSetIterator-p23223319.html
for the full discussion. The basic idea is to add variants to those two methods that return
the current doc they are at, to save successive calls to doc(). If there are no more docs,
return -1. A summary of what was discussed so far:
> # Deprecate those two methods.
> # Add nextDoc() and skipToDoc(int) that return doc, with default impl in DISI (calls
next() and skipTo() respectively, and will be changed to abstract in 3.0).
> #* I actually would like to propose an alternative to the names: advance() and advance(int)
- the first advances by one, the second advances to target.
> # Wherever these are used, do something like '(doc = advance()) >= 0' instead of comparing
to -1 for improved performance.
> I will post a patch shortly

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message