RFC: Conic interface #31
Conversation
| in column-major form (lower triangle) or equivalently row-major form | ||
| (upper triangle). | ||
|
|
||
| .. function:: getconicsolution(m::AbstractMathProgModel) |
There was a problem hiding this comment.
Don't really need a separate getconicsolution
|
Just to clarify, this is the low-level interface. On top of this we can easily implement a single-shot |
| - ``:SOC``, the second-order (Lorenz) cone :math:`\{(p,x) \in \mathbb{R} \times \mathbb{R}^{n-1} : ||x||_2^2 \leq p^2, p \geq 0\}` | ||
| - ``:SOCRotated``, the rotated second-order cone :math:`\{(p,q,x) \in \mathbb{R} \times \mathbb{R} \times \mathbb{R}^{n-2} : ||x||_2^2 \leq 2pq, p \geq 0, q \geq 0\}` | ||
| - ``:SDP``, the cone of symmetric positive semidefinite matrices :math:`\{ X \in \mathbb{R}^{n\times n} : X \succeq 0\}` | ||
| - ``:ExpPrimal``, the exponential cone :math:`\{ (x,y,z) \in \mathbb{R}^3 : y > 0, y e^{x/z} \leq z \}` |
There was a problem hiding this comment.
Technically I think this should be the closure of what you wrote: http://www.seas.ucla.edu/~vandenbe/236C/lectures/conic.pdf
|
CCing @davidlizeng who's working with me on https://github.com/karanveerm/SCS.jl and https://github.com/karanveerm/CVX.jl |
|
Would projection operators or standard self-concordant barrier functions be implemented here, or need to be written elsewhere? |
|
@tkelman, they could be provided in MathProgBase, but that's mostly orthogonal to this interface. |
|
It may be worth separating inequality and equality constraints, since some solvers can exploit the distinction. It will make dual values a bit messier, though. |
|
Inequality constraints are a special case of specifying that a given affine expression is constrained to fall in a cone, which the current interface does not support. @madeleineudell argued that this transformation should be handled at the modeling level. |
|
Ping @madeleineudell @karanveerm @davidlizeng. Let me know if you guys are on board. |
|
It looks good to me, with a few small quibbles:
On Sat, May 31, 2014 at 11:25 AM, Miles Lubin [email protected]
Madeleine Udell |
Will do.
This works as well. Should we allow any iterable set to specify the indices or only allow ranges? Since solvers will already need to deal with permutations of the indices, I don't see the harm in allowing any iterable set. Regarding
Yes, I mean that the matrix is stored using
A number of solvers (Gurobi, CPLEX, Mosek) support |
|
The fundamental user-facing objects in Mosek are SDP matrices rather than groups of n(n+1)/2 scalar variables that live in a SD cone, so the n^2 form is more natural here. It also appears that the SDPA format that is used by many of the pure SDP solvers also works this way. I think the real question is what is most natural for conic modeling, however. (I hope to keep a separate SDP interface for pure SDP problems, much like we have for quadratic/SOC/SOCRotated constraints). @madeleineudell @karanveerm @davidlizeng what form is most natural for CVX? Perhaps we should go with that. |
|
I'd say the n^2 representation is most natural for CVX. On Mon, Jun 2, 2014 at 8:04 AM, Joey Huchette [email protected]
Madeleine Udell |
|
I've pushed changes to reflect this discussion. Ready to merge, unless there are any objections. |
|
looks great to me. On Tue, Jun 3, 2014 at 4:22 PM, Miles Lubin [email protected]
Madeleine Udell |
Addressing #29, here's a proposal for a general conic interface.
You can see the compiled documentation here: http://mathprogbasejl.readthedocs.org/en/conic/conic.html.
The major points are that the cones can be specified in any order and that we differ from SCS in the choice of the canonical primal problem. This format seems more natural for modeling, and is used, for example, by MOSEK.
I'm not very familiar with the exponential cones, so I'm not sure if it's appropriate to include both the primal and dual versions.
Feel free to suggest radical changes, but I wanted to put this down as a concrete proposal to get the discussion moving along.
CC: @IainNZ @joehuchette @juan-pablo-vielma @madeleineudell @karanveerm @ulfworsoe @tkelman @daviddelaat @jfsantos