Uploaded image for project: 'UIMA'
  1. UIMA
  2. UIMA-4094

moveTo(fs) where fs > all items in index is broken

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.4.0SDK, 2.4.1SDK, 2.4.2SDK, 2.5.0SDK, 2.6.0SDK
    • Fix Version/s: 2.7.0SDK
    • Component/s: Core Java Framework
    • Labels:
      None

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

        Issue Links

          Activity

          Hide
          schor Marshall Schor added a comment -

          OK - I see have that note in my email still highlighted, but it did fall thru the cracks!

          Show
          schor Marshall Schor added a comment - OK - I see have that note in my email still highlighted, but it did fall thru the cracks!
          Hide
          pkluegl Peter Klügl added a comment -

          No, I did not open an issue for it because I was not sure if it is a reasonable behavior since I did not debug it. I only wrote a mail to the dev list with the header "Annotation iterator with pointer" (30.05.2014)

          Show
          pkluegl Peter Klügl added a comment - No, I did not open an issue for it because I was not sure if it is a reasonable behavior since I did not debug it. I only wrote a mail to the dev list with the header "Annotation iterator with pointer" (30.05.2014)
          Hide
          schor Marshall Schor added a comment -

          Is there an earlier Jira for this issue? (I may have missed it...; given that you've noticed this and had put in a work-around)

          Show
          schor Marshall Schor added a comment - Is there an earlier Jira for this issue? (I may have missed it...; given that you've noticed this and had put in a work-around)
          Hide
          pkluegl Peter Klügl added a comment -

          Great, then I can remove the workaround in ruta, which makes it a bit faster again for certain use cases

          Show
          pkluegl Peter Klügl added a comment - Great, then I can remove the workaround in ruta, which makes it a bit faster again for certain use cases

            People

            • Assignee:
              schor Marshall Schor
              Reporter:
              schor Marshall Schor
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development