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

general set form #168

Closed
mlubin opened this Issue Jun 9, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@mlubin
Member

mlubin commented Jun 9, 2017

We've had some discussions and there seems to be a consensus on generalizing the conic format to allow affine expressions and quadratic expressions belonging to general user-defined sets. This requires replacing the cone symbols with general julia objects that can be interpreted by the solvers.

JuliaOpt/JuMP.jl#715
JuliaOpt/JuMP.jl#1037
#165
#163 (reorder exponential cone)
#70

While we do this, we should add a min/max sense for consistency with other interfaces which would help fix JuliaOpt/JuMP.jl#1003.

@chriscoey @blegat

@mlubin

This comment has been minimized.

Member

mlubin commented Jun 10, 2017

Question... would this format be general enough to subsume LPQP? Quadratic parts will obviously fit in. What about SOS, indicator constraints, etc?

@mlubin

This comment has been minimized.

Member

mlubin commented Jun 10, 2017

It would mean a bit more work in the solver interfaces, but I'm not seeing any reason why it would make it hard to get good performance, e.g, when modifying models. You can still dynamically add constraints, modify coefficients, add columns in this new format.

@mlubin

This comment has been minimized.

Member

mlubin commented Jun 10, 2017

It also removes a lot of complexity of all the translation layers between lpqp and conic. We would now push these translations onto the solvers.

@mlubin mlubin changed the title from generalize conic form to general set form Jun 10, 2017

@mlubin mlubin added the LPQP label Jun 10, 2017

@mlubin

This comment has been minimized.

Member

mlubin commented Jun 10, 2017

To make it easier on the solvers, we should specify in the format that each "type" of set will appear together in order. This would actually greatly simplify the ECOS and SCS wrappers because a lot of the code there is to account for the arbitrary order of cones in MPB format.

@mlubin

This comment has been minimized.

Member

mlubin commented Jun 10, 2017

This makes indicator (#155) and complementarity constraints (https://discourse.julialang.org/t/extending-mathprogbase-to-support-complementarity-constraints) trivial to express in MPB set form and with corresponding changes in JuMP, trivial to express in JuMP. Complementarity constraints usually appear in NLP though. We could think about allowing these general constraints on top of NLP form (e.g., via addconstraint!).

@adowling2

@chriscoey chriscoey added this to the 1.0 milestone Jun 11, 2017

@mlubin

This comment has been minimized.

Member

mlubin commented Jun 30, 2017

@mlubin mlubin closed this Jun 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment