Benoît Legat

With `exponent::Real`, the exponent is not fully typed so it's going to cause inference issues. For the 3-d power cone, the exponent cannot be integer so in which case `T`...

It's not forced to be the same, in the `@model` macro, the sets that are put in the "typed vector sets" tuple will be typed by `{T}` where T is...

I can reproduce it without GLPK like so: ```julia model = MOI.Utilities.Model{Float64}() bridged = MOI.Bridges.Constraint.SemiToBinary{Float64}(model) MOI.Test.test_model_LowerBoundAlreadySet(bridged, MOI.Test.Config()) ``` The issue is that the bridge creates affine constraints: https://github.com/jump-dev/MathOptInterface.jl/blob/e51754fb12651eb230cb5fae8ea9812f3235b746/src/Bridges/Constraint/semi_to_binary.jl#L48-L56 Therefore, the...

It's still failing for some solvers, see, e.g., https://github.com/blegat/ICCOPT_SummerSchool_2022/blob/main/SimpleConicADMM/test/MOI_wrapper.jl. We could fix it now with `final_touch` but we might want to first discuss variable bounds. We start by reopening this...

Not sure since there is no `ZeroOne` in `test_model_LowerBoundAlreadySet`. We might need it for `ScalarFunctionizeBridge` as well.

This came across when working on https://github.com/jump-dev/SumOfSquares.jl/pull/249 Actually, a better fix is having a `convert_coefficient` defined in MOI. Currently, the SumOfSquares bridge works for any `AbstractVectorFunction` and without a function...

The first step does not require it but resolving the whole issue requires it.

Yes, MatrixOptInterface could be rewritten with MatrixOfConstraints and provide these `linprog`, `quadprog`, etc...

We could also have ```julia struct GenericScalarAffineFunction{T, VT

You can still define `const ScalarAffineColumnFunction{T} = GenericScalarAffineFunction{T, ...}` to facilitates dispatch