-
Notifications
You must be signed in to change notification settings - Fork 87
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 set for low-rank constrained SDP #2198
base: master
Are you sure you want to change the base?
Conversation
5defcea
to
f4f1c22
Compare
This is getting a little out of hand. Do we really need yet another PSD cone? Why isn't this just a solver enhancement where they detect and exploit low-rank structures in the general matrix? Because it's a constraint? |
You're right, maybe this isn't really a PSD think, we could generalize it for any cone. model = Model()
@variable(model, (AX[1:m], X[1:n, 1:n]) in ConeWithInnerProducts(A, PSDCone()))
@constraint(model, AX == b)
@objective(model, Min, dot(X, C)) and model = Model()
@variable(model, y[1:m])
@constraint(model, (y, C) in AffineSpanInCone(A, PSDCone()))
@objective(model, Max, dot(y, b))
That can be very expensive so it wouldn't be so useful in practice. It's also defeating the whole purpose of MOI of being able to transmit custom structure about the problem through JuMP. Even if we have an MOI meta solver that does that, it would need to define a new set to communicate the low-rank structure anyway. |
Do you have a numerical example of what the Also, |
No, the JuMP syntax won't work, it's just to give an idea. |
Other questions:
|
I try to keep the list in #2197
I think some special case might not be serializable but that's already the case for other parametrized sets like |
@mlubin's concern around the serialization wasn't parameterized sets, but if we allow
How would we serialize We need to think about doing something like:
|
If we have your former example, what prevents serializing |
Nothing. We could do that. But the point is that we'd need to pick the matrix type. We couldn't support arbitrary user-defined matrices. |
Maybe we could only pick the matrix type for the purpose of MOF and |
An additional point made by @mlubin that is worth writing down is that, for solvers supporting both low-rank solutions and low-rank constraints like SDPLR (and soon https://github.com/JuliaAlgebra/BMSOS.jl), you can start targeting SDP constraints |
Closes #2197
Note that once this is done, you can write an SDP in SDPA format directly in JuMP with something like
or
And
Dualization.dualize
should take you from one to the other one!Solvers implementing this:
Hypatia.LinMatrixIneqCone
:A1
PSD andA2, ..., A[m]
arbitraryHypatia.WSOSInterpNonnegativeCone
:A = u u'
(Rank-1 PSD)DSDP
:A = a * u * u'
(Rank-1) Add support for rank-1 constraints DSDP.jl#37SDPLR
:A = U * Diagonal(d) * U'
(Low-Rank) Add support for low rank constraint SDPLR.jl#26Basic
AbstractScalarSet
orAbstractVectorSet
tosrc/sets.jl
isbitstype(S) == false
, implementBase.copy(set::S)
isbitstype(S) == false
, implementBase.:(==)(x::S, y::S)
AbstractVectorSet
, implementdimension(set::S)
, unless thedimension is given by
set.dimension
.Utilities
AbstractVectorSet
, implementUtilities.set_dot
,unless the dot product between two vectors in the set is equivalent to
LinearAlgebra.dot
AbstractVectorSet
, implementUtilities.set_with_dimension
insrc/Utilities/matrix_of_constraints.jl
@model
macro at the bottom ofsrc/Utilities.model.jl
Documentation
along with an
## Example
block containing ajldoctest
docs/src/reference/standard_form.md
docs/src/manual/standard_form.md
Tests
_set(::Type{S})
method insrc/Test/test_basic_constraint.jl
and add the name of the set to the list at the bottom of that files
test/sets.jl
MathOptFormat
https://github.com/jump-dev/MathOptFormat
to addsupport for the new set {{ replace with link to the issue }} I don't think we should add any set specialization of that set or at least not yet
Optional
dual_set(::S)
anddual_set_type(::Type{S})
Test
submodule exercising your new set