Convex.jl
Convex.jl copied to clipboard
jump-dev
geomean: Support for vectors
The CVX documentation of geomean at http://cvxr.com/cvx/doc/funcref.html defines the function geo_mean over a vector with the definition (x1*...*xN)^(1/N). This allows the slower logarithm based functions to be rewritten in terms of the faster geometric mean, resulting in an SDP, which is sometimes faster to solve via a few custom solvers.
The current version of geomean is restricted to two variables, i.e., geomean(x,y) with the definition sqrt(x*y) and cannot be extended in a Julia program to vectors.
Hence, this is a request to extend geomean to vectors and update the corresponding documentation.
Note: Can be assigned to me if short expert hints on how to solve the problem are available. I am aware of a straightforward fix which perhaps works with SCS but am not sure if the fix generalizes. I am new to Julia.
The fix would be to encode it as an MOI GeometricMeanCone constraint directly and not do the transformation in Convex.jl.
Then the GeoMeanBridge would transform it into SOC constraints if the solver does not support the GeometricMeanCone.
I agree with @blegat that that's the way to go. Right now, in https://github.com/JuliaOpt/Convex.jl/blob/a7d385a957cecd6646d31b43f87a8cf64c2e9521/src/solution.jl#L138, Convex.jl loads up a MathOptInterface model (MOI) with the objective function and constraints. The way it does it now is a little odd but comes from the interface layer that existed before MOI, namely MathProgBase. That layer expected a specific standard form and so Convex.jl was designed around generating that standard form. So now we just generate the same standard form but pass it to MOI instead.
MOI is much more flexible and doesn't need a standard form in the same way; it accepts many types of constraints, such as a function belonging to the GeometricMeanCone linked above. But right now we don't have a way to make use of this flexibility, since Convex just generates this one standard form and passes it to MOI.
I don't really know the best way to improve the design to let take advantage of this flexibility, so if you have any ideas I'm happy to listen or try to provide pointers or suggestions. I think Convex could actually benefit from a big rewrite to more closely just provide a nice frontend to MOI rather than doing so many reformulations in Convex itself. But that's a bigger project...
Ok, I'll think about it and make a proposal. At the very least, I think this package must support the functions listed in http://cvxr.com/cvx/doc/funcref.html
@ericphanson I took a look at the old interface and the new MathOptInterface. You're right, making a good fix is not easy, and making a quick fix turns out to be messy. Do you have any ideas how to go about this? Is there any plan to change Convex.jl to MathOptInterface completely?
Do you have any ideas how to go about this?
I’ve thought about this a little, and I think the simplest way to start would be some kind of hybrid system that allows adding features using MOI directly but still uses the old way for the existing stuff. Then we could slowly move things over instead of all at once.
I started working on this a few months ago but had to switch to other things. I’ve just pushed my branch hybrid which is very messy, but if I’m remembering right the idea was to have a way to convert from ConicObjs to a new MOI based ConicObjVAF, and to be able to convert from ConicConstr to an MOI constraint.
Then have the model creation stuff be more naturally MOI oriented.
I don’t think I had totally thought everything through though, it was just more of a sketched plan.
One of the issues with the current system is type stability, and I was hoping to fix some of that along the way. In other words, pre-converting to MOI objects it’s unstable (or knowing you have a ConicObj does not tell you the memory layout of what is inside) but after conversion to MOI (which hits a dynamic dispatch) it would be. Then we could slowly push the MOI stuff all the way back to the surface at some point, getting type stability and improving (model formulation) performance a lot, I hope.
Is there any plan to change Convex.jl to MathOptInterface completely?
There is no concrete plan really; I was hoping to work more on this but now I’m not sure when/if I’ll be able to. I do think it’s the next step for Convex in terms of flexibility and performance but it’s a lot of work.
@ericphanson Ok, I just checked that I have access to the 'hybrid' branch. I'll take a look and get back here with a plan. Initially, I too thought of a hybrid approach, but then felt that like all other hybrid approaches, it will be eternally messy. But it is probably the only practical solution apart from a complete rewrite. Talk to you in a bit.
Just to say I've been looking at an alternate way in the eph/moi2 branch (see the ConicFormProblem.jl file; it's called that since I had a ConicFormProblem struct in there at some point but I removed that so now the name is just a bit strange!), which I discuss here a bit: https://github.com/jump-dev/Convex.jl/issues/390#issuecomment-665365051
@ericphanson Eric, I'd like to take this up now since I'm also doing some bits of linear algebra for Julia. Do you have any pointers on where to start and what to do?
No pointers on where to start. I think this is pretty difficult to do at the moment because Convex doesn't hook directly into MathOptInterface, so we can't pass MOI.GeometricCone.
So a start would be: https://github.com/jump-dev/Convex.jl/pull/393. But that's a lot of work.
Note also that https://github.com/jump-dev/Convex.jl#please-read-convexjl-needs-a-new-maintainer.
Have you considered just using JuMP instead?
@odow Thank you very much for this information! Indeed, I have started using JuMP, but I still have a soft corner for DCP and Convex.jl. I had a look at #393, and it is definitely quite involved for a beginner like me. I will wait with this task until someone familiar with Convex.jl decides to integrate the new framework in. Take care.
but I still have a soft corner for DCP and Convex.jl
We have a goal to slowly move JuMP towards a DCP interface.