setRHS is broken

[mlubin]

using JuMP

m = Model()
@defVar(m, x)
@setObjective(m, Max, x)

constr = @addConstraint(m, x + 5 ≤ 10)
@show JuMP.rhs(m.linconstr[1])
solve(m)
@show getValue(x)
chgConstrRHS(constr, 11)
@show JuMP.rhs(m.linconstr[1])
solve(m)
@show getValue(x)

prints

JuMP.rhs(m.linconstr[1]) => 5.0
getValue(x) => 5.0
JuMP.rhs(m.linconstr[1]) => 11.0
getValue(x) => 11.0

Most people would reasonably expect the second solution to be 6, not 11.

[joehuchette]

I mean,

julia> constr = @addConstraint(m, x + 5 ≤ 10)
x ≤ 5

I'm not sure how we can avoid this.

[mlubin]

Can we keep the constant terms in the AffExpr up until we pass it to the solver?

[IainNZ]

This was the same thing I was saying last night about the idea of asking for the "value" of a constraint is not very well defined

[mlubin]

For two-sided constraints we already parse the lower bounds and upper bounds separately. I think we need to do the same for simple constraints also. If the RHS isn't a constant, we shouldn't allow chgConstrRHS. If it is a constant, we should do the right thing.

[mlubin]

Gurobi has the same issue: https://groups.google.com/forum/#!topic/gurobi/CjZKKwvREKc

[joehuchette]

It seems kind of crazy, but maybe an addToRhs(::LinearConstraint,::Number) function makes more sense.

[mlubin]

That seems much simpler to explain

[mlubin]

Okay to drop from 0.10? Doesn't seem like anyone has complained about this behavior up to this point.

[joehuchette]

I know Seb was playing around with this type of thing, but I think he ended up just using the MPB level functions

[mlubin]

My favorite solution at this point is to tell people to use fixed variables and update the bounds. (Thanks @FransdR)

[mlubin]

We should consider completely removing this function

[mlubin]

setRHS doesn't exist anymore, so closing this