Get maxtrix_cone_type without constructing the cone

[Zinoex]

By having a separate function to compute the type of the underlying cone for each matrix type, given the side dimension, constructing the cone and taking the typeof can be avoided. This has the benefit of enabling sparse cones for DSOS and SDSOS.

[codecov[bot]]

Codecov Report

Patch coverage: 91.66% and no project coverage change.

Comparison is base (44b40b4) 80.35% compared to head (b5bb288) 80.35%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #295 +/- ## ======================================= Coverage 80.35% 80.35% ======================================= Files 38 41 +3 Lines 2092 2123 +31 ======================================= + Hits 1681 1706 +25 - Misses 411 417 +6 ``` | [Impacted Files](https://app.codecov.io/gh/jump-dev/SumOfSquares.jl/pull/295?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=jump-dev) | Coverage Δ | | |---|---|---| | [src/Bridges/Constraint/utilities.jl](https://app.codecov.io/gh/jump-dev/SumOfSquares.jl/pull/295?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=jump-dev#diff-c3JjL0JyaWRnZXMvQ29uc3RyYWludC91dGlsaXRpZXMuamw=) | `100.00% <ø> (ø)` | | | [src/sos\_polynomial.jl](https://app.codecov.io/gh/jump-dev/SumOfSquares.jl/pull/295?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=jump-dev#diff-c3JjL3Nvc19wb2x5bm9taWFsLmps) | `81.63% <0.00%> (-3.48%)` | :arrow_down: | | [src/diagonally\_dominant.jl](https://app.codecov.io/gh/jump-dev/SumOfSquares.jl/pull/295?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=jump-dev#diff-c3JjL2RpYWdvbmFsbHlfZG9taW5hbnQuamw=) | `100.00% <100.00%> (ø)` | | ... and [9 files with indirect coverage changes](https://app.codecov.io/gh/jump-dev/SumOfSquares.jl/pull/295/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=jump-dev)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[blegat]

This has the benefit of enabling sparse cones for DSOS and SDSOS.

Could you elaborate on that ? Not sure to see why

[Zinoex]

As a concrete example, the function MOI.Bridges.Constraint.concrete_bridge_type for SOSPolynomialBridge needs to know the possible set of constraint and set types (UMCT and UMST respectively), hence why it previously constructed the cones and took typeof. Now, the design of a VectorAffineFunction-in-SparseDSOS constraint can be designed in one of two ways: only store the side dimension d on the cone or to save a vector of non-zero indices in the SparseDSOS cone. The latter is beneficial, as the constant term of the VectorAffineFunction implies that a vector the size of d * (d + 1) / 2 is stored if we only store the side_dimension on the cone, which is exactly what we want to avoid with SparseDSOS. Therefore, to construct the sparse cone, we would like to know the sparsity to construct a SparseDSOS cone and not just the side dimension as is done with the current matrix cones, which is not available when calling MOI.Bridges.Constraint.concrete_bridge_type. The other alternative would be to have a sparse constant vector for VectorAffineFunction but that would entail a modification or extension all the way down in MOI, or adding a SparseVectorAffineFunction.

[blegat]

I forgot about this, is it still up to date ?

[Zinoex]

I do not know if this is up to date. I haven't worked on it for ages as there was no progress with the PR. I also won't have time to work on it again any time soon, as we went with a different approach to our problem.