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 <
notifications@github.com> 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
#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. notifications@github.com 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
#90 (comment),
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" notifications@github.com 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. notifications@github.com
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
<#90 (comment)
,
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
#90 (comment),
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 #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 #297 since this is really the same thing: add various power cone atoms.