Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add bridge to that converts upper/lower constraints to interval constraints #1193

Closed
freemin7 opened this issue Nov 6, 2020 · 4 comments
Closed
Labels
Submodule: Bridges About the Bridges submodule

Comments

@freemin7
Copy link

freemin7 commented Nov 6, 2020

It is much simpler to implement a solver interface that just handles interval constraints.
However currently such a solver wouldn't be able to handle one sided constraints due to a lack of a bridge converting them to interval constraints.

Another issue that pops up his that in what interval x <= 6 should be expressed as. The obvious solution -Inf <= x <= 6 only works floating point numbers, Inf does not exist for integers or Fraction types (as @blegat pointed out in the Gitter). In this case it should be possible to pass some lower/upper bound as parameter for the bridge which should be used instead of -Inf and Inf.

Bounding Inf to a finite value is also a thing i've seen on NLP solvers which work with floating points exclusively.

@odow
Copy link
Member

odow commented Nov 6, 2020

It's also not obvious what should happen if multiple bound constraints get added.

model = Optimizer()
x = MOI.add_variable(model)
MOI.add_constraint(model, x, MOI.LessThan(1.0))
MOI.add_constraint(model, x, MOI.GreaterThan(1.0))  # But an interval bound already exists!

@blegat
Copy link
Member

blegat commented Nov 8, 2020

The bridge would only support floating point numbers so if integer or rational are use, the bridge will simply not be used. I don't like introducing arbitrarily large values, this can lead to subtle bugs. It can be done at the level of solver wrappers but I'd rather not do it at the level of MOI.
For SingleVariable bounds, I would say the error is expected. The user should set an Interval constraint instead. As JuMP is not doing it, it should start doing it.
Another approach would be to transform the second add_constraint with set(..., MOI.Interval(1.0, 1.0)) inside the bridge with something like #1097
Anyway, this does not prevent us from using it for ScalarAffineFunction and ScalarQuadraticFunction.

@shadiakiki1986
Copy link
Contributor

@blegat I started a draft PR #1195 for this. Could you take a quick look and tell me if I'm on the right track? I tried to use your comment above as well as gitter chat on November 6, 2020 8:59 PM

shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 11, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 11, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 11, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 11, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 11, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 11, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 16, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 16, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 16, 2020
shadiakiki1986 added a commit to shadiakiki1986/MathOptInterface.jl that referenced this issue Nov 18, 2020
@blegat blegat closed this as completed in 6f16730 Nov 27, 2020
@shadiakiki1986
Copy link
Contributor

@freemin7 with the pr merged, you might want to test your issue again on master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Submodule: Bridges About the Bridges submodule
Development

No branches or pull requests

4 participants