Protect against weird bounds combinations #30
Conversation
| setvariablebound!(m, v, set) | ||
| m.last_constraint_reference += 1 | ||
| ref = SVCI{S}(m.last_constraint_reference) | ||
| ref = SVCI(v, set) |
There was a problem hiding this comment.
Doesn't this impact the requirement to return constraints in the order that they were created?
LinQuadOptInterface.jl/src/constraints.jl
Line 85 in 11fb079
There was a problem hiding this comment.
Yes it does.
I am proposing that this rule is not applied to Single variable constraints since we only have one of each - since they are tied to the variable reference they will be unique...
There was a problem hiding this comment.
the well ordering on variables will keep these in some fixed order
There was a problem hiding this comment.
I see the issue with http://www.juliaopt.org/MathOptInterface.jl/latest/apireference.html#MathOptInterface.ListOfConstraintIndices. We definitely want the constraint indices to be tied to the variable indices for bound-type constraints. On the other hand, we should be consistent with how constraints work across all classes of constraints. What about using an OrderedSet to maintain the list of constraints in the order they're added?
Alternative protection for weird bound combination (temp replace for #30)
Fixes #21
There are a few test fails, two main kinds:
adding multiple constraints of the same type, which will be blocked by this.
ordered indices, we could add a version fo that ignoring SingleVariable constraints
For all the linquad solvers these constraints are special...