Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SpanLabelView may not enforce non-overlap constraint #665

Open
mssammon opened this issue Jul 4, 2018 · 4 comments
Open

SpanLabelView may not enforce non-overlap constraint #665

mssammon opened this issue Jul 4, 2018 · 4 comments
Assignees

Comments

@mssammon
Copy link
Contributor

mssammon commented Jul 4, 2018

It looks like if you call addConstituent() it sidesteps the span check:
https://github.com/CogComp/cogcomp-nlp/blob/master/core-utilities/src/main/java/edu/illinois/cs/cogcomp/core/datastructures/textannotation/SpanLabelView.java#L62
This should perform a bounds check unless there is a good reason not to; otherwise, documentation should reflect the intention.

@mssammon
Copy link
Contributor Author

mssammon commented Jul 4, 2018

Incidentally: making the Constituents field of View a TreeMap would address an inefficiency in the current code (see https://github.com/CogComp/cogcomp-nlp/blob/master/core-utilities/src/main/java/edu/illinois/cs/cogcomp/core/datastructures/textannotation/SpanLabelView.java#L65)

@ChaseDuncan
Copy link
Contributor

These seem like two separate issues. Should the second issue be handled in another ticket?

Regarding the first issue, I think the fix is to simply move the bounds check from addSpanLabel(int, int, String, double) into addConstituent(Constituent) before the call to the super.addConstituent(Constituent) is made. Does that work?

@mssammon
Copy link
Contributor Author

They are separate issues, but changing to treemap would automatically fix the duplication problem. Given that we want to order constituents for return via View.getConstituents() anyway (and we impose ordering on insertion explicitly -- see note above) it seems redundant to do both if the TreeMap change is sensible. Can you take a look and see what's involved? I assume we will need a QueryableMap class to take the place of QueryableList (currently used to hold constituents)

@mssammon
Copy link
Contributor Author

sorry, wires crossed. Was thinking about a separate issue that I think also touches on span overlap -- duplicate constituents. Agree with your proposed solution -- moving bounds check.

@danyaljj danyaljj mentioned this issue Aug 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants