[ 
https://issues.apache.org/jira/browse/UIMA-4094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marshall Schor updated UIMA-4094:
---------------------------------
    Description: 
Using moveTo(fs) where the fs is beyond the last element in the index 
incorrectly sets the iterator position to the 1st element.  It should set the 
iterator to (from the Javadocs) ""insertion point" for fs, i.e., to a point 
where the feature structure at that position is greater than fs and the fs at 
the previous position (if it exists) is less than fs

When the fs is > all the elements in the index should conceptually set the 
iterator to 1 past the end of the index, which isValid() will return "false" 
for. 

Because this change may break user code (in case users have worked around 
this), I think this change should be removable under a JVM property flag, 
something like uima.keep_wrong_moveTo_behavior.

UIMA-1601 introduced this behavior (8/19/2011).

UIMA-1601 was about moving to the left-most of equal FS hits in the index.  It 
did this in the PointerIterator, but that impl is not used if the index being 
iterated over has no subtypes.  Move this fixup code to the impls that 
LeafPointerIterator uses.  It uses one of 3 - one for bag, set, and sorted 
indexes.  The bag is a don't care - there are no "keys" and no notion of 
left-most.  The set uses the CompIntArrayRBT which has a comment saying it does 
already the right thing (I didn't test).  The sorted uses IntVectorIterator 
which has the problem.  Move the (fixed) code UIMA-1601 added from the 
PointerIterator to the IntVectorIterator, to insure it always returns the 
left-most one (among equals).

  was:
Using moveTo(fs) where the fs is beyond the last element in the index 
incorrectly sets the iterator position to the 1st element.  It should set the 
iterator to (from the Javadocs) ""insertion point" for fs, i.e., to a point 
where the feature structure at that position is greater than fs and the fs at 
the previous position (if it exists) is less than fs

When the fs is > all the elements in the index should conceptually set the 
iterator to 1 past the end of the index, which isValid() will return "false" 
for. 

Because this change may break user code (in case users have worked around 
this), I think this change should be removable under a JVM property flag, 
something like uima.keep_wrong_moveTo_behavior.

UIMA-1601 introduced this behavior (8/19/2011).


> moveTo(fs) where fs > all items in index is broken
> --------------------------------------------------
>
>                 Key: UIMA-4094
>                 URL: https://issues.apache.org/jira/browse/UIMA-4094
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 2.4.0SDK, 2.4.1SDK, 2.4.2SDK, 2.5.0SDK, 2.6.0SDK
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>             Fix For: 2.6.1SDK
>
>
> Using moveTo(fs) where the fs is beyond the last element in the index 
> incorrectly sets the iterator position to the 1st element.  It should set the 
> iterator to (from the Javadocs) ""insertion point" for fs, i.e., to a point 
> where the feature structure at that position is greater than fs and the fs at 
> the previous position (if it exists) is less than fs
> When the fs is > all the elements in the index should conceptually set the 
> iterator to 1 past the end of the index, which isValid() will return "false" 
> for. 
> Because this change may break user code (in case users have worked around 
> this), I think this change should be removable under a JVM property flag, 
> something like uima.keep_wrong_moveTo_behavior.
> UIMA-1601 introduced this behavior (8/19/2011).
> UIMA-1601 was about moving to the left-most of equal FS hits in the index.  
> It did this in the PointerIterator, but that impl is not used if the index 
> being iterated over has no subtypes.  Move this fixup code to the impls that 
> LeafPointerIterator uses.  It uses one of 3 - one for bag, set, and sorted 
> indexes.  The bag is a don't care - there are no "keys" and no notion of 
> left-most.  The set uses the CompIntArrayRBT which has a comment saying it 
> does already the right thing (I didn't test).  The sorted uses 
> IntVectorIterator which has the problem.  Move the (fixed) code UIMA-1601 
> added from the PointerIterator to the IntVectorIterator, to insure it always 
> returns the left-most one (among equals).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to