Discuss implementing all constraint types

[odow]

Raised by @tkoolen:

I can't use the MOIT tests because I only advertise support for Interval constraint sets (which I think is the right thing to do). I thought that the proper way to add support for LessThan etc. would be to have a CombineIntoIntervalBridge in MOIU, similar to SplitIntervalBridge.

I’m still not sure whether I should advertise support for vector-valued constraints in OSQP. Perhaps document that better.

I added the following to the docs, however when I attempted to use the web editor I clicked merge into master rather than make a PR. Commit is 51c8f72. I can revert if people want changes.

With this in mind, developers should attempt to support as many constraint types as possible if it makes sense on the solver side. For example, if the solver only supports constraints of the form l <= f(x) <= u, where l or u can be inf or -inf, the wrapper should support ScalarAffineFunction-in-LessThan/GreaterThan/EqualTo instead of just Interval.

[tkoolen]

For example, if the solver only supports constraints of the form l <= f(x) <= u, where l or u can be inf or -inf, the wrapper should support ScalarAffineFunction-in-LessThan/GreaterThan/EqualTo instead of just Interval

What about VectorAffineFunction-in-Zeros/Nonnegatives/Nonpositives? If that's the policy, it just seems to me like that would lead to a lot of repeated code across solver implementations, with a much larger surface area for bugs than if these kinds of extensions are handled in a central location. It will be tedious, and especially the handling of duals will be error prone. And you could also ask the question why SplitIntervalBridge exists then.

[mlubin]

This is an inherent tension in the design of MOI. The current answer is, if you want users to be able to model with these constraints, then the solver wrapper must support it. The OSQP wrapper could choose to support only ScalarAffineFunction-in-Interval, but this would imply that variable bounds and one-sided constraints like @constraint(m, x + y <= 1) would fail to work from JuMP (obviously not good).

OSQP is not the kind of solver where users would typically expect to model with vector-valued constraints, so I'd say that support for VectorAffineFunction-in-Zeros/Nonnegatives/Nonpositives is less pressing. However, someone will want it eventually, and if it's not implemented they could choose to reformulate or implement support for it. Documentation is important here, as you mentioned.

Support for different function-set combinations can be either through bridges or on an ad-hoc basis. It's up to the package author to decide. It will take some time and experience to develop best practices.

[blegat]

What about VectorAffineFunction-in-Zeros/Nonnegatives/Nonpositives? If that's the policy, it just seems to me like that would lead to a lot of repeated code across solver implementations, with a much larger surface area for bugs than if these kinds of extensions are handled in a central location. It will be tedious, and especially the handling of duals will be error prone. And you could also ask the question why SplitIntervalBridge exists then.

I wouldn't be against adding a bridge for that. I think some solvers might want deal with every constraint type directly to try to have minimal memory/time footprint for each of them (typically LP solvers, there has even been talk about caching constraints to submit them in bunch to the solvers to allow better performance) but for other solvers, the reasoning is that this is completely negligible and bridges are an appropriate way to make solvers support everything with minimal duplicate work (typically convex solvers). I like to think that MOI thrives for both type of solvers and allows them to be seamlessly available through the same API.