Closed madeleineudell closed 9 years ago
I am not sure why we're doing this. I thought the goal of having a unified conic interface through mathprogbase was to make CVX.jl agnostic of issues like these? If anything, ECOS.jl, SCS.jl etc should have to worry about this and not us.
As such, we need to rethink certain design decisions anyway when we move to supporting exponential, SDP constraints etc and I am not sure how this would make it any easier.
I think the Problem interface should stay the way it currently is. The job of the Problem type is to parse the problem into a canonical form that we think makes sense. We should however, separate solver specific functionality like stuffing matrices into different files. It makes sense to have something that translates from the canonical forms stored in problems to ECOS specific arguments or to some standard Conic interface that MathProgbase may want to see. These solver specific items should probably go under the solvers folder and not under problems.
In the far, far future, we may need to have different ways of building canonical forms, such as if we want to be able to use an ADMM based backend. When we get to that point, we will probably have to redesign the Problem type. But not until then.
Yes, I think ultimately the code currently in conicproblem.jl should reside in MathProgBase. But we want our problem.jl interface to be solver agnostic, which currently it is not. (Witness the number of functions beginning with "ecos_" in that file.) For now, to factor out ECOS from our problem.jl file, it seems like we need our own translator back to ECOS format. It will also be important to be able to perform that translation to hook in SCS. Ideally, we can ultimately contribute our translator as a PR to MathProgBase.
Ultimately, the solve method should abstract the solver away as much as possible. It could look something like this:
function solve!(problem::Problem, method=:ecos)
# maximize -> minimize
if problem.head == :maximize
problem.objective = -problem.objective
end
cproblem, mapping_to_standard_form = ConicProblem(problem)
if method == :ecos
solution = solve(ECOSConicProblem(cproblem))
elseif method == :glpk
solution = MathProgBase.???(cproblem)
else
println("method $method not implemented")
end
# minimize -> maximize
if (problem.head == :maximize) && (solution.status == "solved")
solution.optval = -solution.optval
end
# Populate the problem with the solution
problem.optval = solution.optval
problem.status = solution.status
problem.solution = solution
if problem.status == "solved"
populate_variables!(problem, mapping_to_standard_form)
populate_constraints!(problem, mapping_to_standard_form)
end
end
We should make sure that the solver specific functionality (any ecos_ function) lives in solvers/ecos.jl. Right now, it's gross that the mapping to conic form goes via "create_ecos_matrices". We need a generic version that targets the standard cone form we agreed on with the MathProgBase team:
type ConicProblem
c::Array{Float64, 1}
A::Array{Float64, 1}
b::Array{Float64, 1}
cones::Array # Array of (Symbol,Range) or (Symbol,Array{Integer}) tuples
end
We can get this as a translation from ECOSConicProblem, but it will be at the cost of introducing as many new variable as we had constraints. Which is maybe not so bad for now.
Hey CVX.jl team, Chatted to Miles and Joey today about how we can help you out. I'm going to give the following a go some time in the next week
I think this is probably the most efficient use of everyones time, and once you have this you'll be able to copy-paste it/expand on it for SCS.
One other thing: I'd really like to move ECOS.jl to the JuliaOpt organization (if this is OK with @jfsantos) as it makes it easier for us to collaborate on and keeps all solver wrappers in one place. I personally don't have a problem with CVX.jl staying in cvxgrp, but if you ever want to move it over that'd be cool too. It'll be on the JuliaOpt site regardless.
I am completely fine with moving ECOS.jl to JuliaOpt. Unfortunately I still did not had the opportunity to work in the conic interface, but I am still interested in collaborating.
No problem @jfsantos , you've done plenty :)
This issue is moot; conic form interfaces now live in MathProgBase.
Fill in the functions in conic problem.jl to correctly translate between three different standard cone formats, and from the Problem form into each standard cone form:
1) ConicProblem, following the standard described here
2) IneqConicProblem, following the same standard but allowing generalized inequality constraints Gx \leq h, so the indices in the variable cones refer to constraints rather than variables.
3) ECOSConicProblem, which is described here. (A translation from Problem to ECOSConicProblem is already implemented.)