-
Notifications
You must be signed in to change notification settings - Fork 87
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
indicator to SOS bridge #877
Conversation
Codecov Report
@@ Coverage Diff @@
## master #877 +/- ##
==========================================
- Coverage 95.22% 95.15% -0.07%
==========================================
Files 84 86 +2
Lines 8978 9167 +189
==========================================
+ Hits 8549 8723 +174
- Misses 429 444 +15
Continue to review full report at Codecov.
|
this should be good for review |
I believe they're on vacation. Have you tried this with some solvers? E.g., GLPK? |
thanks that's why it's all quiet around here! Not yet I wanted to be sure the whole thing was not off, I'll give it a try |
Seems okay to me. The only style question is whether to include it in |
GLPK does not seem to support SOS constraints. The other indicator bridge defined is for activated on 0 => activated on 1, it's not awfully big |
Oh. I always forget that. Gurobi then? |
Cbc seems ok, I'm trying to use only the FOSS ones for tests |
So, it seems tricky, I'm not sure this is supposed to behave as ignoring the bridge, needs more investigation |
There seems to be a problem, but I haven't figured out what exactly. I still haven't figured how to check exactly the newly formulated problem |
Try saving to MathOptFormat? |
Ah yes thanks, I was looking for an excuse to try it :)
…On Fri, Sep 13, 2019, 17:39 Oscar Dowson ***@***.***> wrote:
I still haven't figured how to check exactly the newly formulated problem
Try saving to MathOptFormat?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#877>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB2FDMVX3RBFWJGXXFUKCWTQJOX4TANCNFSM4IVUBPFQ>
.
|
src/Bridges/Constraint/indicator.jl
Outdated
`EqualTo` constraints are handled without a bound constraint: | ||
``z \\in \\mathbb{B}, z == 1 \\implies f(x) == b`` is reformulated as: | ||
``z \\in \\mathbb{B}, w \\text{ free}, f(x) + w == b, SOS1(w, z)``. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not always add a free w
so that it works for any indicator constraint (also MOI.Interval
, ...) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a free
fallback with all constraints but LessThan
, GreaterThan
, otherwise we add a free, which has to be re-bounded by two variables for LP
& MILP
solvers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understood "which has to be re-bounded by two variables"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry yes, if we create the variable w
free, it will be replaced by w+ >= 0, w- >= 0, w = w+ + w-
instead of creating a bounded w
right away
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's also the case for SDP solvers with the Variable.FreeBridge
. Which LP solver does not support free variables ? This transformation is done internally ?
For a solver supporting free variables such constraints may increase the size of the problem, we should probably have informative constraints but that's out of the scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which LP solver does not support free variables ? This transformation is done internally ?
All solvers (that I am aware of) support free variables, but the transformation needs to be done internally somehow. The simplex algorithm does require positive variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to use the standard form you have equality constraints and nonnegative variables but then the dual has free variables. Some solvers might solve the dual using the simplex in which case they need all variables to be free. Although that's the textbook simplex so I don't know whether solvers might use a more sophisticated one supporting mixing free and non-free ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to use the standard form you have equality constraints and nonnegative variables but then the dual has free variables.
My understanding is that the standard form is a form A x <= b, x >= 0
transformed in Ax + s = b, x, s >= 0
. You need to have basic columns in the equality, so starting from a generic A x = b
, it will need to change the variable system in [A; -A] x <= [b; -b]
and then add slacks, in order to have as many basic columns as constraints.
test/Bridges/Constraint/indicator.jl
Outdated
@@ -53,3 +53,92 @@ include("../utilities.jl") | |||
@test t.coefficient ≈ 1.0 | |||
end | |||
end | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also have a test with basic_constraint_test
(see #750) and a test against indicator1
, indicator2
or indicator3
(https://github.com/JuliaOpt/MathOptInterface.jl/blob/98a0e472e1757db14b849bbba8fe84597856def2/src/Test/intlinear.jl#L609-L611) with test_model_equals
(see #820)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't manage to make that work (yet)
@blegat I can't figure out what is off here. Any tips on a debugging process for that? |
You mean for making |
The constraints defined in the bridge seem not to be activated. |
Yes :) |
if attr.N == 1 | ||
return MOI.get(model, MOI.VariablePrimal(), bridge.z_variable_index) | ||
end | ||
wv = MOI.get(model, MOI.VariablePrimal(), bridge.w_variable_index) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be MOI.VariablePrimal(attr.N)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how come? w is a scalar variable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the N
th result, you have VariablePrimal(N)
, ConstraintPrimal(N)
and ConstraintDual(N)
. The value of ConstraintPrimal(N)
is the value of the function when the variables have values VariablePrimal(N)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, that's not really intuitive, I thought ConstraintPrimal(N)
would be the primal of the N
-th function in the vector function. I'll update that
@blegat after thoughts, not sure Getting primal attributes: Error During Test at /home/mbesancon/.julia/dev/MathOptInterface/test/Bridges/Constraint/indicator_sos.jl:179
Got exception outside of a @test
ArgumentError: `supports` is not defined for MathOptInterface.ConstraintPrimal(1), it is only defined for attributes such that `is_copyable` returns `true`.
Stacktrace:
[1] supports(::MathOptInterface.Utilities.Model{Float64}, ::MathOptInterface.ConstraintPrimal, ::Type{MathOptInterface.ConstraintIndex{MathOptInterface.ScalarAffineFunction{Float64},MathOptInterface.LessThan{Float64}}}) at /home/mbesancon/.julia/dev/MathOptInterface/src/attributes.jl:197
[2] set(::MathOptInterface.Utilities.UniversalFallback{MathOptInterface.Utilities.Model{Float64}}, ::MathOptInterface.ConstraintPrimal, ::MathOptInterface.ConstraintIndex{MathOptInterface.ScalarAffineFunction{Float64},MathOptInterface.LessThan{Float64}}, ::Float64) at /home/mbesancon/.julia/dev/MathOptInterface/src/Utilities/universalfallback.jl:356
|
If you set the variable values, the mock optimizer uses them to compute ConstraintPrimal using |
Alright |
Based on the comment on indicator constraints in the SCIP documentation: