Temporary constraint

[sebheger]

I would suggest introducing a temporary constraint object when setting the "equality/inequality sense" to a linear expression.

m = Model("Test", solver_name="cbc)
x = m.add_var(name="x")
tc = x <= 1

tc should be now a temporary constraint instead of a linear expression. What someone might do now:

A)

y = m.add_var(name="y")
tc = tc + y

or even

B)

tc = tc <= 2

would - in my eyes lead - be undefined/unclear (A) or infeasible (B) operations. At the moment both operations are feasible. I would introduce separate functions to add "something" to the linear expression part (LHS) of the temporary constraint or to update the constant.

[jurasofish]

How do you see someone accidentally doing either of those things? I would argue that if the programmer starts adding things to constraints or trying to make new constraints out of existing constraints then they've well and truly lost track of what they're doing and there's really no helping them.

The current implementation has traded simplicity of implementation for a slight onus on the programmer to keep track of their constraint objects, and I think that's probably a good balance.

Another option might be to make a "temporary constraint" class which is a subclass of LinExpr with no modifications. That way, type checking might catch some of these issues. Although that probably wouldn't be enough.

[sebheger]

I agree, that my cases are worst-case scenarios. But I am not primarily thinking of programmers doing mistakes/stupid things. It is just a proposal to separate different logics and make things more clear. For sure, this is not a prio 1 topic. The idea was born when I was faced again with the issue, that cbc does not consider constraints when the term of the linear expression is empty.

[sebheger]

@jurasofish After having written a bunch tests for lin_expr handling and dived through some issues, it seems very necessary to split the logic of a lin_expr. In gurobipy they also added a similar class when they allowed such operations like

x + y <= 5
<gurobi.TempConstr: <gurobi.LinExpr: x + y> <= 5>

The main reason - also @h-g-s mentioned this a few times - is that manipulation of the expression of a constraint is technically difficult (and yet not fully supported through mip). And users trying to manipulate it and are not getting expected results. In the moment you are forming a constraint (equation or inequality) - even if not added to the model - the manipulation and arithmetic of this new object is already some kind of restricted.