Complete box constraint implementation about cosmo.jl HOT 8 CLOSED

@blegat The question is if this merging belongs to MOI or should be done by each solver wrapper individually. I guess solvers that support the standard cones do this implicitly by sorting the constraints and then constraining consecutive elements of the constraint primal variable to be in the zero cone, nonnegative orthant, etc... (like SCS)

@chriscoey I'll take a look. Thank you.

Apart from this discussion I still think it would be useful to have the box (higher-dimensional interval
l <= x <= u) as an available constraint set in MOI.

from cosmo.jl.

#61

from cosmo.jl.

#62 instead.

from cosmo.jl.

Implemented in 6a4d93e
What remains to be done is a merging step for multiple constraints that result in ZeroSet, Nonnegatives or Box when the problem is formulated via MOI

from cosmo.jl.

What remains to be done is a merging step for multiple constraints that result in ZeroSet, Nonnegatives or Box when the problem is formulated via MOI

cc @chriscoey I remember you were also interested in having all the Nonnegatives constraint grouped together (but I cannot find the issue in MOI where we discussed it)

from cosmo.jl.

I do this merging in Hypatia. @migarstka I'll add you to the repo

from cosmo.jl.

Hypatia can handle a multidimensional box with a single L_inf norm epigraph (conic) constraint. So there's a question of whether MOI have the box set or the box cone or both

from cosmo.jl.

I wouldn't be against adding a multidimensional box. Users may want to model with that (e.g. having the state belong to an hyperrectangle is useful in Control), and solvers supports it so it makes sense to add it to MOI.

Grouping constraints of the same cone together is what is currently done by ECOS, SCS, SeDuMi, CDCS in their wrappers, there is plan to make a utility for that, see jump-dev/MathOptInterface.jl#24 (comment)

from cosmo.jl.