-
-
Notifications
You must be signed in to change notification settings - Fork 399
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
Norms! #465
Norms! #465
Conversation
# Container for expressions containing Norms and AffExprs | ||
type NormExpr | ||
norm::Norm | ||
coeff::Float64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is coeff
? Needs more comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
coeff*||norm.terms|| + aff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, just add that as a comment :)
Nice! What do you think about switching to the conic interface if norms are present? I guess this would need the SDP branch merged in first. |
I was thinking this gets merged before SDP, so I can add the conic stuff for SOC there. The default solver stuff for conic problems needs to be rethought at some point. |
Sounds good. |
Also, do we need to store the |
If it's negative, we want to recognize that something like |
Or we could not and let users write it with a positive coefficient. We're not Convex.jl after all |
With the way we parse expressions, I think something like |
Fair enough |
Any hope for other norms? Or are we committing ourselves to L2? |
It should be pretty easy to make |
1 and inf norms would be super useful (yes I know it's easy to reformulate those but the code looks prettier when I don't have to) |
Agreed. What would nice syntax look like? |
That would probably be good enough, yeah. Extra args inside |
I would make the syntax something like |
This is some back-seat designing, but could be good to have |
Good point, that doesn't generalize nicely with arbitrary norms. |
@@ -474,6 +478,40 @@ end | |||
getValue(arr::Array{QuadExpr}) = map(getValue, arr) | |||
|
|||
########################################################################## | |||
# Norm | |||
# Container for √(∑ expr) | |||
type Norm{T} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, can we make this parametric on the expression:
type Norm{T,E<:GenericAffExpr}
terms::Vector{E}
end
So I can use it for JuMPeR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing
+1 |
73f3f68
to
0623f06
Compare
cc @smukoehler |
@joehuchette, could you rebase? |
for (mac,sym) in [(:LinearConstraints, symbol("@LinearConstraint")), | ||
(:QuadConstraints, symbol("@QuadConstraint"))] | ||
(:QuadConstraints, symbol("@QuadConstraint")), | ||
(:SOCConstraints, symbol("@SOCConstraint"))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alignment, if you care
I think this needs an update for the |
Nvm, master is broken |
OK, I'm gonna merge this in the next day or so if there aren't any outstanding concerns. Operator coverage should be 100%, and the printing code is ugly but functional. |
Conic duals don't work either, but I think that'll take more work throughout the stack that's sufficiently orthogonal from this PR. |
@defVar(m, L1[1:d]) | ||
@addConstraint(m, L1 .== (μ-μhat)) | ||
@addConstraint(m, sum{L1[i]^2, i=1:d} <= t1^2) | ||
@addConstraint(m, t1 <= Γ1(𝛿/2,N)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we leave these in as a separate test? Always good to test multiple ways of doing the same thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sure
LGTM. |
Printing tests are failing on travis |
Yeah, it's gonna be a mess to fix... |
What's wrong? |
It looks like |
Is this a recent change in master or just this branch? |
Master as well, I'm pretty sure |
Oh fun. Maybe we can propose to add these definitions for |
|
I can add |
OS X release is failing Travis because of an old build, I ran it locally and everything passes. |
💯 |
Good stuff Joey! |
@@ -105,6 +105,17 @@ you would a linear objective:: | |||
|
|||
status = solve(m) | |||
|
|||
Second-order cone constraints |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be in the "Expressions and Constraints" section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that'd make sense
Still need to plug the solvers in.