[
https://issues.apache.org/jira/browse/UIMA-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16555053#comment-16555053
]
Marshall Schor edited comment on UIMA-5844 at 7/25/18 1:39 PM:
---------------------------------------------------------------
this is a bug, due to a conceptual confusion on my part. On the last update,
an FSIterator.size() and LowLevelIterator.getArray() methods were added. The
definition of these were not as clear as they should have been. Because
FSIterators go forwards and backwards, the size() and the getArray() methods
were implemented to return the full extent of the iterator, starting from the
first position thru the last one.
The "following" implementation incorrectly assumed that the getArray() would
return just the part of the array from the position (which was correctly set).
Thinking more about this I think I see other issues stemming from the
generality. For instance, the things that specify a starting position are
typically implemented via an interator.moveTo(positioning-FS) - and for
"equal" items, it moves to the left-most one.(optionally ignoring type
priorities).
-This I think interacts (currently) incorrectly with the backwards iterator.-
-I think the backwards iterator needs some special casing to handling moving to
the left-most among equals position, or, alternatively, things like this should
be disallowed (that is, if the iterator is a backwards iterator, don't have it
support a moveTo...) To avoid implementing features ahead of real need, I plan
to go this disallowed route, for repositioning a backwards iterator.- The
backwards impl aready looks like it supports moveTo.
For initially positioning it, the approach that makes the most sense to me is
to position the non-reversed iterator, and then wrap that with the reverse
moving iterator impl., so startAt and following and preceding still work, even
with backwards specified.
was (Author: schor):
this is a bug, due to a conceptual confusion on my part. On the last update,
an FSIterator.size() and LowLevelIterator.getArray() methods were added. The
definition of these were not as clear as they should have been. Because
FSIterators go forwards and backwards, the size() and the getArray() methods
were implemented to return the full extent of the iterator, starting from the
first position thru the last one.
The "following" implementation incorrectly assumed that the getArray() would
return just the part of the array from the position (which was correctly set).
Thinking more about this I think I see other issues stemming from the
generality. For instance, the things that specify a starting position are
typically implemented via an interator.moveTo(positioning-FS) - and for
"equal" items, it moves to the left-most one.(optionally ignoring type
priorities). This I think interacts (currently) incorrectly with the backwards
iterator.
-I think the backwards iterator needs some special casing to handling moving to
the left-most among equals position, or, alternatively, things like this should
be disallowed (that is, if the iterator is a backwards iterator, don't have it
support a moveTo...) To avoid implementing features ahead of real need, I plan
to go this disallowed route, for repositioning a backwards iterator.- The
backwards impl aready looks like it supports moveTo.
For initially positioning it, the approach that makes the most sense to me is
to position the non-reversed iterator, and then wrap that with the reverse
moving iterator impl., so startAt and following and preceding still work, even
with backwards specified.
> SelectFS.following doesn't work
> -------------------------------
>
> Key: UIMA-5844
> URL: https://issues.apache.org/jira/browse/UIMA-5844
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 3.0.0SDK
> Reporter: Richard Eckart de Castilho
> Priority: Major
> Fix For: 3.0.1SDK
>
>
> It seems as if the SelectFS following method doesn't work at all:
> {code}
> @Test
> public void testSelectFollowingPrecedingDifferentTypes() {
> this.jCas.setDocumentText("A B C D E");
> Token a = new Token(this.jCas, 0, 1);
> Token b = new Token(this.jCas, 2, 3);
> Token c = new Token(this.jCas, 4, 5);
> Token d = new Token(this.jCas, 6, 7);
> Token e = new Token(this.jCas, 8, 9);
> for (Token token : Arrays.asList(a, b, c, d, e)) {
> token.addToIndexes();
> }
> Sentence sentence = new Sentence(this.jCas, 2, 5);
> sentence.addToIndexes();
> // uimaFIT: selectFollowing(this.jCas, Token.class, sentence, 1);
> List<Token> following1 =
> jCas.select(Token.class).following(sentence).limit(1).asList();
> assertEquals(Arrays.asList("D"), JCasUtil.toText(following1));
> assertEquals(Arrays.asList(d), following1);
> {code}
> This fails with
> {code}
> java.lang.AssertionError: expected:<[D]> but was:<[A]>
> {code}
> It seems as if the `following` simply has no effect. If the `limit is
> removed`, the whole set of Tokens is returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
