sum of powers

[gajjanag]

I am interested in maximizing a sum of powers p_i^a subject to some affine equality and inequality constraints, where a < 1. Note that this function is concave, i.e its negative is convex. However, checking http://convexjl.readthedocs.org/en/latest/operations.html shows that my closest candidates are norm(x, p) (requires p >= 1) and sum_squares. Could we have an atom to support this use case, e.g sum_powers?

[madeleineudell]

Definitely, it's in the works. The next step is to add a new kind of conic constraint --- the power cone --- to Convex.jl, modeled after the exponential cone constraint. Then we can call the SCS solver directly on the conic problem formulated in terms of the power cone. Using power cones, when available, should be faster and more accurate than the current implementation of p-norms as well.

This does raise an interesting question about whether / how to use the fact that we (will) have two different formulations of p-norms that we might use to transform the problem to conic form: one involving power cones and one by reduction to SOCPs. When and how should the decision be made about which formulation to use?

On Sat, Jun 27, 2015 at 11:16 AM, Ganesh Ajjanagadde < [email protected]> wrote:

I am interested in maximizing a sum of powers p_i^a subject to some affine equality and inequality constraints, where a < 1. Note that this function is concave, i.e its negative is convex. However, checking http://convexjl.readthedocs.org/en/latest/operations.html shows that my closest candidates are norm(x, p) (requires p >= 1) and sum_squares. Could we have an atom to support this use case, e.g sum_powers?

— Reply to this email directly or view it on GitHub https://github.com/JuliaOpt/Convex.jl/issues/90.

Madeleine Udell www.stanford.edu/~udell

[chriscoey]

@mlubin and I were talking about how there will be a decision between using the power cone formulation or the SOCP formulation. The power cone formulation would typically be smaller, but only SCS supports power cones, though many solvers support SOCs. Perhaps there could be a new option for translating into power cones versus SOCs.

[madeleineudell]

Good point. Is that a piece of functionality that we should put in MathProgBase, or in the modeling layer (Convex and JuMP)?

On Fri, May 27, 2016 at 10:02 AM, Chris C. [email protected] wrote:

@mlubin https://github.com/mlubin and I were talking about how there will be a decision between using the power cone formulation or the SOCP formulation. The power cone formulation would typically be smaller, but only SCS supports power cones, though many solvers support SOCs. Perhaps there could be a new option for translating into power cones versus SOCs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JuliaOpt/Convex.jl/issues/90#issuecomment-222199903, or mute the thread https://github.com/notifications/unsubscribe/AAyp9MWRDd_wcohghCLQnMrSbp7JudLiks5qFyOcgaJpZM4FNTL_ .

Madeleine Udell Postdoctoral Fellow at the Center for the Mathematics of Information California Institute of Technology https://courses2.cit.cornell.edu/mru8 https://courses2.cit.cornell.edu/mru8 (415) 729-4115

[mlubin]

Modeling layer, since SOC solvers are not responsible for supporting power cones. But there could be standard utilities in MathProgBase that the modeling layer uses to convert power cones into SOCs. On May 27, 2016 13:29, "Madeleine Udell" [email protected] wrote:

Good point. Is that a piece of functionality that we should put in MathProgBase, or in the modeling layer (Convex and JuMP)?

On Fri, May 27, 2016 at 10:02 AM, Chris C. [email protected] wrote:

@mlubin https://github.com/mlubin and I were talking about how there will be a decision between using the power cone formulation or the SOCP formulation. The power cone formulation would typically be smaller, but only SCS supports power cones, though many solvers support SOCs. Perhaps there could be a new option for translating into power cones versus SOCs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/JuliaOpt/Convex.jl/issues/90#issuecomment-222199903 , or mute the thread < https://github.com/notifications/unsubscribe/AAyp9MWRDd_wcohghCLQnMrSbp7JudLiks5qFyOcgaJpZM4FNTL_

.

Madeleine Udell Postdoctoral Fellow at the Center for the Mathematics of Information California Institute of Technology https://courses2.cit.cornell.edu/mru8 https://courses2.cit.cornell.edu/mru8 (415) 729-4115

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JuliaOpt/Convex.jl/issues/90#issuecomment-222206419, or mute the thread https://github.com/notifications/unsubscribe/ABp0M8lKT4qIwkyw2hwNgv44wuiTw7TJks5qFyoQgaJpZM4FNTL_ .

[chriscoey]

Yeah. Though I think perhaps the ultimate goal is to encourage more conic solvers themselves to support a wider range of cones including these unsymmetric power cones.

[odow]

Now that https://github.com/jump-dev/Convex.jl/pull/590 is merged, this issue can be resolved by adding support for atoms that create the various GenericConstraint{MOI.PowerCone} constraints.

[odow]

Closing in favor of https://github.com/jump-dev/Convex.jl/issues/297 since this is really the same thing: add various power cone atoms.