Why bridges and not an optimizer

[odow]

I'm not convinced about the bridge approach. I know we discussed it and I was interested to see what happened, but after looking at the code I have some reservations.

In particular, many of the reformulations are not exact with the idea that you solve a sequence of problems for decreasing $\tau \rightarrow 0$, warm-starting each solve from the prior solution. The bridge approach doesn't allow that.

I was more thinking along the lines of https://github.com/jump-dev/MultiObjectiveAlgorithms.jl and https://github.com/jump-dev/MathOptLazy.jl, where we cache some part of the model (here, complementarity constraints), and then move all of the complexity into the MOI.optimize! routine.

[odow]

Other reasons are #20 and #39

[frapac]

I understand your concern, and I would be happy to have a discussion with you and @blegat at JuMP-dev.

We should make explicit to the user that some reformulations are not equivalent (oftentimes, we are relaxing slightly the complementarity constraints). My hope was to make that explicit in the documentation, but maybe that's not the proper place.

However, some other reformulations remains strictly equivalent (SOS1 reformulation, default Scholtes relaxation with tau=0, and the vertical reformulation).

Doing the modifications directly in MOI.Optimize! would also make sense, but that would change thoroughly the current design.

[blegat]

When the user is using MathOptComplements.Optimizer, the fact that it is using bridges internally doesn't really matter. We started by not using bridges at first but we ended up feeling that we were reimplementing MOI.Bridges.AbstractBridgeOptimizer. Bridges are just a reformulation mechanism. The layer added by JuMP only do equivalent reformulation but that doesn't mean that we can use that technology for non-equivalent reformulations as well.
Unclear if #39 is a motivation for a change of design until we find the issue.
For #20, we'll be able to implement it thanks to the fact that we created a custom subtype of MOI.Bridges.AbstractBridgeOptimizer and not a MOI.Bridges.LazyBridgeOptimizer