Set bridges

[blegat]

I just went through the new doc in the break_everything branch. I like the new constraints and variables design ! If I understand correctly, we are merging LPQP and conic into AbstractModel, love it !

Would you think that it make sense to implement something like set fallbacks (it would be like the bridges but it is now constraint-wise and not model-wise) ?

For instance, CSDP and SDPA like their SDP cone unscaled by sqrt(2) while Mosek and SCS like it scaled (if I am not mistaken). On the other size, JuMP has it unscaled at the start. Therefore we could have

# Translated is there to avoid the infinite recursion in case the solver does not implements SD
# and also to let the PSD -> SOC fallback be called
struct PSDCone{Scaled, Translated}
    n::Int
end
# We hide Translated for the 99% of user that do not care about this technical detail
function PSDCone{Scaled}(n::Int) where {Scaled}
    PSDCone{Scaled, false}(n)
end
function addconstraint!(..., ::PSDCone{true, false})
    ...
    SDunscaleBridge(addconstraint!(..., PSDCone{false, true}(...)))
end
function addconstraint!(..., ::PSDCone{false, false})
    ...
    SDscaleBridge(addconstraint!(..., PSDCone{true, true}(...)))
end

The bridge is there to translate the duals, ...

As another example, CSDP and SDPA currently do not implement the SOC cone but do implement the SD cone so we could define

function addconstraint!(..., ::SOCCone)
    ...
    SOCtoSDBridge(addconstraint!(..., PSDCone))
end

We could also have

function addconstraint!(..., c::PSDCone{false})
    if c.n <= 1
        # translate to linear cone
    elseif c.n == 2
        # translate to second order cone
    else
        error("Sorry, this solver does not implement SDP, go to juliaopt.org and pick another one")
    end
end

so the user will be able to use 1x1 and 2x2 PSD matrices in JuMP using a SOC solver as he would expect !

Of course some bridges could be done by extension. For example, SumOfSquares could implement

function addconstraint!(..., ::SOSCone)
    ...
    SOStoSDBridge(addconstraint!(..., PSDCone{false}))
end

In fact, we could make it possible that, any package just needs to add MPB to the require file and do

function MPB.addconstraint!(..., ::CustomSet)
    ...
end

for the set to be useable both directly in MPB and in JuMP with

@constraint m expr in CustomSet()

[mlubin]

These bridges are not sufficient because we also need to translate constraint dual and primal solutions back to the old set after the solve. I think this translation should happen in the solver wrapper, and we could provide a standard set of utilities to make it easier to implement.

…

On Jun 16, 2017 04:19, "Benoît Legat" ***@***.***> wrote: I just went through the new doc in the break_everything branch. I like the new constraints and variables design ! If I understand correctly, we are merging LPQP and conic into AbstractModel, love it ! Would you think that it make sense to implement something like set fallbacks (it would be like the bridges but it is now constraint-wise and not model-wise) ? For instance, CSDP and SDPA like their SDP cone unscaled by sqrt(2) while Mosek and SCS like it scaled (if I am not mistaken). On the other size, JuMP has it unscaled at the start. Therefore we could have # Translated is there to avoid the infinite recursion in case the solver does not implements SD# and also to let the PSD -> SOC fallback be calledstruct PSDCone{Scaled, Translated} n::Intend# We hide Translated for the 99% of user that do not care about this technical detailfunction PSDCone{Scaled}(n::Int) where {Scaled} PSDCone{Scaled, false}(n)endfunction addconstraint!(..., ::PSDCone{true, false}) ... SDunscaleBridge(addconstraint!(..., PSDCone{false, true}(...)))endfunction addconstraint!(..., ::PSDCone{false, false}) ... SDscaleBridge(addconstraint!(..., PSDCone{true, true}(...)))end The bridge is there to translate the duals, ... As another example, CSDP and SDPA currently do not implement the SOC cone but do implement the SD cone so we could define function addconstraint!(..., ::SOCCone) ... SOCtoSDBridge(addconstraint!(..., PSDCone))end We could also have function addconstraint!(..., c::PSDCone{false}) if c.n <= 1 # translate to linear cone elseif c.n == 2 # translate to second order cone else error("Sorry, this solver does not implement SDP, go to juliaopt.org and pick another one") endend so the user will be able to use 1x1 and 2x2 PSD matrices in JuMP using a SOC solver as he would expect ! Of course some bridges could be done by extension. For example, SumOfSquares <https://github.com/JuliaOpt/SumOfSquares.jl> could implement function addconstraint!(..., ::SOSCone) ... SOStoSDBridge(addconstraint!(..., PSDCone{false}))end In fact, we could make it possible that, any package just needs to add MPB to the require file and do function MPB.addconstraint!(..., ::CustomSet) ...end for the set to be useable both directly in MPB and in JuMP with @constraint m expr in CustomSet() — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#186>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABp0M3XwnQjDxzwI0avaaORZ--o09glqks5sEjqXgaJpZM4N8KcQ> .

[blegat]

The bridge will be able to get the dual by asking the dual of the actual constraint given to the solver and then doing the translation.
The advantage of not asking the solvers to do this explicitly is that the solver could support sets it doesn't even know about, e.g. created by extensions.

[mlubin]

This should be reopened at MathOptInterface, still a very important question