On 13. Nov 2020, at 12:08, Mario Juric <[email protected]> wrote:
>
> We have no use cases where something like shift is used, especially negative
> shifts, so it’s hard for me to have a qualified opinion about this. The
> closest thing it reminds me of are negative list indexes in Python, and I am
> not sure that is comparable. I guess, invalidating or sending out warnings in
> some of the mentioned edge cases seems reasonable for now.
While writing up some migration notes related to behavioral changes in the next
UIMA version, I came across this again.
So, right now (after the changes we discussed), using a negative shift with a
bounding operator like "following" or "coveredBy"
would return an empty list:
----
select().shifted(-1).following(t3) => {}
----
Using it without the negative shift, it would return this result e.g.:
----
select().following(t3) => {t4, t5}
----
So I am thinking now that it might make more sense to simply internally set the
shift from the negative number to 0 when used
in such a situation:
----
select().shifted(-1).following(t3) => {t4, t5} // internally shifted is capped
to 0
select().following(t3) => {t4, t5}
----
However, that would/should then introduce interaction with the `limit()`
operator, e.g.
----
select().shifted(-1).following(t3) => {t4, t5} // internally shifted
is capped to 0
select().shifted(-1).following(t3).limit(2) => {t5}
----
We shift by -1, do not return the result because it is outside the bounds, but
still limit the
forward move operations. So effectively, the negative shift would need to be
subtracted from
the limit in this case.
Any thoughts?
Cheers,
-- Richard
