Add dual cones for cones without them

[araujoms]

It seems that the problem is that MOI doesn't define its dual. Is that intentional or would the addition of the cone be welcome?

[joaquimg]

The initial recommendation is to create a separate package and play with the idea. Once stable, it might make sense to propose an addition to the MOI repo.

You would need to define the new cone and overload the function MOI.dual_set. Then Dualization would be able to dualize.

To connect that with solving, you need either: 1) a solver supporting the new cone (is there one?) or 2) bridges to convert the new cone into something supported by some solver (that can live in the separate package).

[araujoms]

I'm not creating any package, I'm just happy to help if you're interested in making the dualisation work.

As for solving, it's easy to bridge it to the geometric mean cone itself. The only point in adding it is to enable dualisation. In any case, Hypatia supports it directly.

[odow]

I'm going to say that this issue is out-of-scope for Dualization. There are few sets in MOI that we don't have dual sets for. My quick list: NormCone, GeometricMeanCone, RelativeEntropyCone, LogDetConeTriangle, LogDetConeSquare, RootDetConeTriangle, RootDetConeSquare, PositiveSemidefiniteConeSquare.

There's an argument about whether we should have sets for those, but we seem to be doing okay without them. We also typically require multiple solvers to support the set before we add it to MOI.

If a solver like Hypatia supports specific dual sets, then it can already implement dual_set and dual_set_type and work with Dualization.jl, so I don't know if there's anything we need to do here.

[araujoms]

How is an user supposed to know that they need to use Hypatia.HypoGeoMeanCone instead of MOI.GeometricMeanCone for dualisation to work? This is a terrible experience for no benefit. I think that yes, clearly if a cone is in MOI its dual should also be. Except for LogDetConeSquare, RootDetConeSquare, and PositiveSemidefiniteConeSquare; it was a mistake to introduce them so you shouldn't dig yourselves deeper in the hole.

Furthermore, the dual of these cones can be easily be bridged into the primal ones together with the nonnegative cone, so it's not as if you're demanding any extra solver support.

[blegat]

How is an user supposed to know that they need to use Hypatia.HypoGeoMeanCone instead of MOI.GeometricMeanCone for dualisation to work? This is a terrible experience for no benefit.

The fact we have cones without their dual is not by design, we just add things when there is sufficient need for it to justify the cost of implementing it + maintaining it. The fact that the user can already use the cone natively used by bridge without even having to modify MOI is a good thing IMO.

I think that yes, clearly if a cone is in MOI its dual should also be.

I agree. I would accept a PR that a) define the dual set in MOI, b) add the bridges that make it usable by solvers like SCS, c) map it to the native Hypatia cone.

Except for LogDetConeSquare, RootDetConeSquare, and PositiveSemidefiniteConeSquare; it was a mistake to introduce them so you shouldn't dig yourselves deeper in the hole.

Dualization should say that it does not support them so they should be bridged to the corresponding ...Triangle set before dualization so it should work.

[odow]

I've transferred this issue to MOI.

[odow]

Closing because the missing ones are now LogDetConeTriangle, LogDetConeSquare, RootDetConeTriangle, RootDetConeSquare, and PositiveSemidefiniteConeSquare. I don't think we have any plans to implement these.