uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Eckart de Castilho (JIRA)" <...@uima.apache.org>
Subject [jira] [Updated] (UIMA-5637) JCasUtil.selectAt has different meaning than expected
Date Mon, 06 Nov 2017 10:55:00 GMT

     [ https://issues.apache.org/jira/browse/UIMA-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Richard Eckart de Castilho updated UIMA-5637:
    Fix Version/s: 2.3.1uimaFIT

> JCasUtil.selectAt has different meaning than expected
> -----------------------------------------------------
>                 Key: UIMA-5637
>                 URL: https://issues.apache.org/jira/browse/UIMA-5637
>             Project: UIMA
>          Issue Type: Bug
>          Components: uimaFIT
>    Affects Versions: 2.3.0uimaFIT
>            Reporter: Mario Juric
>             Fix For: 2.3.1uimaFIT
> I was wondering what exactly the semantics of JCasUtil.selectAt is supposed to be after
looking into the implementation, since the JavaDoc isn’t very precise. I initially thought
that it would select annotations of the given type with the exact begin and end, but this
is not the case when inspecting the implementation. The problem is in CasUtil.selectAt with
the following while loop:
> while (it.isValid()) {
>   AnnotationFS a = it.get();
>   // If the offsets do not match the specified offets, we're done
>   if (a.getBegin() != aBegin && a.getEnd() != aEnd) {
>     break;
>   }
>   it.moveToNext();
>   list.add(a);
> }
> I would have expected that either begin or end must be different to drop the item, i.e.
"if (a.getBegin() != aBegin || a.getEnd() != aEnd)" instead. This is obviously not the case,
and it does not have the same behaviour like selectCovered either, so what is the intend if
it’s not a bug?

This message was sent by Atlassian JIRA

View raw message