uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: Adjusting the behavior of SelectFS limit and shifted operations
Date Thu, 19 Nov 2020 08:07:58 GMT
On 13. Nov 2020, at 12:08, Mario Juric <mario.juric@cactusglobal.com> 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
forward move operations. So effectively, the negative shift would need to be subtracted from
the limit in this case.

Any thoughts?


-- Richard
View raw message