Benoît Legat

You can use a bridge layer on top of Dualization (e.g. with `MOI.Bridges.full_bridge_optimizer`) so that the square PSD constraint is automatically transformed to a triangle PSD one. Supporting square PSD...

Using bridges outside a DualizationOptimizer may not work as expected because of https://github.com/JuliaOpt/Dualization.jl/issues/77. IIRC, we use a bridge layer inside the DualizationOptimizer because when the optimizer did not support free...

That's indeed a valid workaround. `MOI.Bridges.Constraint.Square{Float64}` is a `Bridges.Constraint.SingleBridgeOptimizer`. This bridge optimizer bridges any constraint that can be bridged independently on whether the inner model supports it.

> Since everything is about to be converted to `NonlinearExpr` anyway, it'd be nicer if we just kept things as `NonlinearExpr`. In this case yes, but this performance issue could...

I don't see any objection then, I can see this being useful. About the naming, once we drop the legacy nonlinear interface, what would be left of the `nl` shortcut...

Can you reduce it to an example using the MOI wrapper directly without Convex ? Otherwise, it may be an issue with Convex. Trying a simple example work: ```julia julia>...

Any update ?

In MOI, we assume that the components of cones are real because some bridges operations wouldn't be valid for complex numbers (e.g., SlackBridge creates real numbers). About the SOC cone,...

> As for determining whether the expressions are real or complex, isn't it exactly what @odow did in https://github.com/jump-dev/JuMP.jl/pull/3695? Yes, you can see that it's considering that nonlinear expressions may...

So you could create I complex version `ComplexNormInfinityCone` that has `2n + 1` entries, the first being `t`, then the `n` real parts and then the `n` imaginary parts. The,...