[jira] [Comment Edited] (UIMA-5844) SelectFS.following doesn't work

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

    [ 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.  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)