[
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.
Although this change may break user code (in case users have worked around
this), it's important to have this operate correctly. If this turns out to be
an issue, we can later issue a patch that removes this fix under a JVM property
flag, something like uima.jira_4094.keep_old_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).
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).
> 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.
> Although this change may break user code (in case users have worked around
> this), it's important to have this operate correctly. If this turns out to
> be an issue, we can later issue a patch that removes this fix under a JVM
> property flag, something like uima.jira_4094.keep_old_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)
