increase cost of DualGeoMeanBridge and DualRelativeEntropyBridge

[araujoms]

Otherwise Hypatia uses them instead of FunctionConversionBridge and the supported cones DualGeometricMeanCone and DualRelativeEntropyCones, which is much less efficient.

The reason is that they generate VectorAffineFunction constraints, which Hypatia supports directly.

In constrast, Hypatia doesn't use GeoMeanBridge and RelativeEntropyBridge because they introduce VectorOfVariables constraints, which would need a FunctionConversionBridge anyway.

Another possibility would be to reduce the cost of transforming VectorOfVariables into VectorAffineFunction, for example by doing

function conversion_cost(
    ::Type{<:MOI.ScalarAffineFunction},
    ::Type{MOI.VariableIndex},
)
    return 0.9
end

That works, but I don't know if it has undesirable consequences.

[odow]

Here's a reproducible example of what is happening:

(hyp) pkg> st
Status `/private/tmp/hyp/Project.toml`
  [b99e6be6] Hypatia v0.10.1 `https://github.com/jump-dev/Hypatia.jl.git#araujoms/dualgeomean`
  [b8f27783] MathOptInterface v1.53.0 `https://github.com/jump-dev/MathOptInterface.jl.git#od/1.53`

julia> import Hypatia

julia> import MathOptInterface as MOI

julia> begin
           model = MOI.instantiate(Hypatia.Optimizer; with_bridge_type = Float64)
           x, c = MOI.add_constrained_variables(model, MOI.DualGeometricMeanCone(5))
           MOI.Bridges.print_active_bridges(model)
       end
 * Supported objective: MOI.ScalarAffineFunction{Float64}
 * Unsupported constraint: MOI.VectorOfVariables-in-MOI.DualGeometricMeanCone
 |  bridged by:
 |   MOIB.Constraint.DualGeoMeanBridge{Float64, MOI.VectorAffineFunction{Float64}, MOI.VectorOfVariables}
 |  may introduce:
 |   * Supported constraint: MOI.VectorAffineFunction{Float64}-in-MOI.Nonnegatives
 |   * Supported constraint: MOI.VectorAffineFunction{Float64}-in-MOI.GeometricMeanCone

julia> begin
           model = MOI.instantiate(Hypatia.Optimizer; with_bridge_type = Float64)
           MOI.Bridges.remove_bridge(model, MOI.Bridges.Constraint.DualGeoMeanBridge{Float64})
           x, c = MOI.add_constrained_variables(model, MOI.DualGeometricMeanCone(5))
           MOI.Bridges.print_active_bridges(model)
       end
 * Supported objective: MOI.ScalarAffineFunction{Float64}
 * Unsupported constraint: MOI.VectorOfVariables-in-MOI.DualGeometricMeanCone
 |  bridged by:
 |   MOIB.Constraint.FunctionConversionBridge{Float64, MOI.VectorAffineFunction{Float64}, MOI.VectorOfVariables, MOI.DualGeometricMeanCone}
 |  may introduce:
 |   * Supported constraint: MOI.VectorAffineFunction{Float64}-in-MOI.DualGeometricMeanCone

I wonder if it does make sense to make FunctionConversionBridge cheaper. We should basically always prefer to use it over some other transformation.

[odow]

This needs some careful thought though, so I'm going to release v1.53 first. The temporary fix for Hypatia is to use a VectorAffineFunction directly.

[araujoms]

Indeed, I think it makes more sense to make the FunctionConversionBridge cheaper, as it is a cheap bridge, and GeometricMeanCone and RelativeEntropyCone were working by chance. Perhaps this problem is even affecting some other cones and solvers.

Closing in favour of #3063.