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