general set form

[mlubin]

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.

jump-dev/JuMP.jl#715
jump-dev/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 jump-dev/JuMP.jl#1003.

@chriscoey @blegat

[mlubin]

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

[mlubin]

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]

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]

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 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

[mlubin]

This will be implemented in https://github.com/JuliaOpt/MathOptInterface.jl