-
-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add syntax for more general set inclusion constraints #715
Comments
na na na na na na na na POWER CONE! |
What would nice syntax for this look like? |
Maybe we should sit down and discuss this in the broader context of conic modeling in JuMP. |
For reference, here is Convex.jl's exp constraint: and the log and exp atoms: |
+1 |
Possible syntax idea:
would constrain |
it's a little weird but i guess it lines up somewhat with the the thing here is that very often you would be writing something like |
as an example, let's use this little convex.jl model from pajarito tests
I guess in JuMP it would be nice (for now) to write:
or to cut out
|
also, those cones would be n-dimensional rather than 3-dimensional, and would just automatically detect the number of indices of the "argument" (in this case u or y). however we also need to be able to parametrize some possible cones, like norm cones and product of power cones, and that may not work with the Symbol syntax eg |
Per discussion with @mlubin today, I suggest using a tuple of vectors. Parameters for parametrized cones should not go with the variables.
Typically, for homogeneous functions, there will be a 2-tuple of epi/hypo-graph variable and argument vector (no perspective variable needed), eg: For non-homogeneous functions, there may be a 3-tuple, as we want a perspective variable, eg: For the PSD cone, I would be interested to see a specific example of a cone that modelers would find useful that doesn't fit nicely into this abstraction. |
Why @constraint(m, (t, x) in Norm(2)) instead of @constraint(m, [t, x] in Norm(2)) ? Or @constraint(m, [t, x...] in Norm(2)) ? |
It's a good question and we should discuss it more. My reasoning for wanting a tuple in cone is that it can help prevent mistakes by the modeler. Say for example the modeler is using an n+2 dimensional exponential cone (not homogeneous, is convex, so it has an epigraph, a perspective, and an n dimensional argument x). They should write: If we had used the syntax: So I see it as both slightly more elegant to write, but more importantly, more resistant to errors by the modeler. |
For SOC, however, you'd want a tuple with 2 elements. For extensibility, we wouldn't want JuMP's parsing of the constraint to depend on knowing anything about the particular cone, so I'm having trouble seeing how we can catch the error for the Exp cone, besides giving two scalar elements when the minimum possible dimension is 3. |
This is not something I understand. I would like to learn why this is a problem and try to think of a way around it that preserves the mistake-detecting ability (and IMO, elegance) of the syntax above. We can talk offline if that's easier. |
Yes the dimension of the tuple depends on the cone. See what I was saying earlier about non-homogeneous (3) vs homogeneous (2) vs slices like PSD cone (1). |
Alternatively, maybe we don't want shortcuts - everything could be 3 dimensions. Perspectives of homogeneous functions could be dummy |
Actually unless someone can suggest a useful nonlinearity where that (perspective, epi/hypograph, argument) in cone syntax is insufficient, I am in favor of always using a 3-tuple. |
I have little desire to discuss this further before my thesis defense is completed. |
If you go with the perspective + epi/hypo-graph + argument abstraction for cones, it may not be much more work to just directly parse functions into conic form. |
Although you could ask why this syntax can't be used for general "in set"
constraints. If you want to go for generality, then perhaps the single
array notation is the best.
I think we'd need to have a big long group conversation. Maybe at the jump
development meeting.
…On Mar 30, 2017 1:48 PM, "Miles Lubin" ***@***.***> wrote:
I have little desire to discuss this further before my thesis defense is
completed.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#715 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJq0k3CAB04JuyDFoyAl0Nvzw9T-g6sGks5rq-rXgaJpZM4H4KLb>
.
|
I really like the idea of having a more generic conic constraint syntax. In fact, I would like to be even more ambitious. @constraint m, x >= 0, cone=:S, param=1
@constraint m, x >= 0, cone=S(param=1)
@constraint m, x in S(param=1) While the two first ones only make sense if S is a cone, the last one also makes sense if S is a set. |
Ok, the extension argument is convincing. Would it be sufficient for what you're thinking to support only affine expressions belonging to these sets? |
Bonus points for unifying this with a new variable syntax ala https://github.com/JuliaOpt/JuMP.jl/issues/692#issuecomment-251718478] |
Oh man |
Affine Expression would already be very useful. Quadratic expression might also come handy for, e.g. modeling BMIs with PolyJuMP. |
I think we should resurrect this discussion as it may be relevant to JuliaOpt/MathProgBase.jl#164 and to jump-dev/PolyJuMP.jl#10 first of all, what should these "set objects" look like? will there be an extensible library of them? cones will be a subset, but should they get special treatment or not? also, maybe, how should we think about primal-dual "set inclusion" problems? geometrically a dual on a set constraint might define a supporting hyperplane to the set. maybe this is a useful way to think that is more general than conic duality |
Why not just something like: immutable SOC end
@constraint(model, x in SOC()) |
I consider this resolved now with MOI. |
No description provided.
The text was updated successfully, but these errors were encountered: