update atom documentation - state required cone types #574
Consider the following SOCP (per @wkschwartz)
Clearly, we could equivalently formulate the problem as a QP
Right now if a user tries to call
However it would be very nice if cvxpy automatically performed the reduction from SOCP to QP when a user specifies a QP-only solver.
The text was updated successfully, but these errors were encountered:
this is a long standing issue, and quite likely the reason why
i vote for closing this.
If cvxpy's goal is to make convex optimization more accessible, then this is a good enhancement. Taking the position that
this is stupid. you are arguing to introduce a small bug (which is not an issue per se), but it is one, because
for example, the
cvxpy has gotten complicated, it's true. It's more modular than it appears, but probably less accessible than before. The solver interfaces are more ad hoc now. Having one way of representing solver information wasn't working. I don't work personally on the commercial solver interfaces. Those are contributed by others, which is working fine for now. It would be well worth cleaning out all the legacy solver interfaces so the approach is clearer.
In terms of this issue, if we were to add SOCP to QP conversion I would not do it in an ad hoc way such as by catching norm2, converting it to sum_squares, but catching all possible cases. People in Boyd's group have looked at this and it's somewhat involved. I guess we can keep this issue open, but it's not something I see getting into cvxpy any time soon.
thanks @SteveDiamond . i fear we can not succumb to complexity though.
to compile to QP form, me (and @moehle , and @takapoui ) had identified the changes necessary to @jaehyunp 's LS compiler. it was a couple of hundred of lines of changes. (i never understood that weird cs-theoretical thing you put in the paper, although i believe the thing uses my code stub).
so, why don't we just branch cvxpy 0.4 and make a cvxpy 2.0? without all that giant crapload of c++ (shouldn't that have gone to code garbage a few years ago), without support for imagenary numbers (i thought we had got over those), and without caring a gram of shit about the stupid commerical solvers!!!!
(btw, @rileyjmurray comment in another thread is right. we should use
@enzobusseti the C++ code present in cvxpy 1.0 was already present in cvxpy 0.4, just under a different name (cvxcanon instead of cvxcore). The long-term plan is to remove the dependence on cvxcore and make a different high-speed backend designed only with cvxpy in mind. However for now, it is simply not possible to "branch cvxpy 0.4 and make cvxpy 2.0 without C++".
On a second note- It's not clear to me how or where commercial solvers entered the design process for cvxpy 1.0. Certainly cvxpy 1.0 was not written in a way that made it easy for me to write the 1.0 MOSEK interface, and the CPLEX interface is currently a 1.0 wrapper around an old 0.4-style interface. It is true that cvxpy 1.0 is written with a less-specific canonical form in mind (relative to 0.4), but that generality has nothing to do with any one solver. YALMIP similarly has flexible problem representations and supports a huge range of commercial and open-source solvers.
All the above said, I have done more thinking about SOCP to QP conversion and I realize now where the problem lies.
Here's one way to look at it: It can be shown that supporting the second-order cone is equivalent to supporting constraints of the form
Here is another way to look at it: start with the scalar function
This is all to say: an SOCP with nontrivial linear term (a-la
In view of these fundamental obstacles, I am now open to closing this issue.
@rileyjmurray you're right, it's more complicated than it first looks. we had figured out that the QP-representable problems have inequality constraints involving quadratic-of-piecewise-affine functions. (let me know if you want to write a paper about it.)
I'm reworking the documentation a bit. Rather than saying "use quad_form when working with OSQP" (which is very specific and didn't really have a natural place to mention), I added a column on the
I did use the facts that (1) all LPs are compatible with SOCP, QP, and EXP solvers, and (2) all SOCPs are compatible with SDP solvers.
@rileyjmurray I missed your update to the atoms table. This makes a lot of sense, and is similar to the Convex.jl documentation. I guess I left it out before because we only had cone programs, and I didn't think users would understand.
@enzobusseti thanks for clarifying. cvxpy can always be improved, substantially in some ways, but I don't have the time and energy that I used to have for such large alterations.