Thilo Goetz wrote: > Thilo Goetz wrote: > >> Marshall Schor wrote: >> >>> Thilo Goetz wrote: >>> >>>> Marshall Schor wrote: >>>> >>>> >>>>> Thilo Goetz wrote: >>>>> >>>>> >>>>>> See the Jira issue for the cause of the problem. More >>>>>> comments below. >>>>>> >>>>>> Marshall Schor wrote: >>>>>> >>>>>> >>>>>> >>>>>>> So, there may be 2 things to look at here - the actual error, described >>>>>>> above, and the more philosophical question on the behavior of moveTo - >>>>>>> this seems to require a sorting order if the item "moved to" is not >>>>>>> present in the index. Perhaps this needs to be documented better. And >>>>>>> >>>>>>> >>>>>>> >>>>>> I'm not sure I understand your point about moveTo(). It requires the >>>>>> index to be sorted to make any sense (and the BagIndex moveTo() is >>>>>> broken, >>>>>> but that's a different issue >>>>>> >>>>>> >>>>> Will you be fixing this too? >>>>> >>>>> >>>> We enter the realm of philosophy again. What's the right >>>> behavior for moveTo() when the underlying index isn't sorted? >>>> In particular, what should happen when no proper element >>>> is found? The javadocs say: >>>> >>>> Note that any operation like find() or FSIterator.moveTo() will not produce >>>> useful results on bag indexes, since bag indexes do not honor comparators. >>>> Only >>>> use a bag index if you want very fast adding and will have to iterate over >>>> the >>>> whole index anyway. >>>> >>>> >>> I like systems where user errors are reported :-). If find() and >>> moveTo() don't work on bag indexes, I would prefer they throw an >>> exception, perhaps like UnsupportedOperationException or our equivalent >>> in UIMA. >>> >> Fine with me. >> > > I take that back. find() works anyway. The question with > moveTo(fs) is simply what the behavior should be in case > fs is not in the index. If it is in the index, the cursor > will be positioned there, even for bag indexes. If it's > not there, the cursor will currently be positioned at an > arbitrary point. This is a left-over from the days when > bag indexes were also sorted and simply a bug, to my mind. > My intuition is that moveTo(fs) should make the iterator > invalid if fs is not in the index. >
+1 for having the iterator "invalid" if the fs is not in the index. > NB that the notion of equality here is FS identity. Not > sure this is clear from the documentation. > I'm not sure what FS identity means. I thought that (for Set indexes) the comparison for equality was index-dependent, and used whatever keys were declared in the index. Do you mean that the FS "address" in the heap must be the same (by FS identity), and does this test apply just for Bag indexes? -Marshall > --Thilo > > > >
