Add JuMP-level Nonnegatives, Nonpositives, and Zeros sets #3273
Conversation
This change enables `Ax >= b` to be lowered to `Ax - b in Nonnegatives()`, and removes the confusing Vector-in-GreaterThan(0) method in build_constraint that asserted the right-hand side was zero.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #3273 +/- ##
=======================================
Coverage 98.10% 98.11%
=======================================
Files 34 34
Lines 4704 4714 +10
=======================================
+ Hits 4615 4625 +10
Misses 89 89
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Co-authored-by: James Foster <38274066+jd-foster@users.noreply.github.com>
| f::AbstractVector, | ||
| set::Nonnegatives, | ||
| ) | ||
| return build_constraint(_error, f, MOI.Nonnegatives(length(f))) |
There was a problem hiding this comment.
This is equivalent to assuming that @constraint(model, a >= b) is equivalent to @constraint(model, a >= b, Nonnegatives()) right ?
I think we explicitly decided not to have these cones by default but I would be ok to change it but I think we need to make sure everybody agrees on it.
It also kind of makes sense since we assumes Nonnegatives by default to compare vector of objective in multiobjective optimization.
There was a problem hiding this comment.
This is equivalent to assuming that @constraint(model, a >= b) is equivalent to @constraint(model, a >= b, Nonnegatives()) right?
Yes, for vector-valued a - b. I think this is pretty standard interpretation. Do you remember why we decided not to?
It makes it a lot easier to write models that conic solvers support without bridges. Currently they'll bridge every scalar linear constraint to a vector-valued one of dimension 1.
There was a problem hiding this comment.
I don't remember, @mlubin do you ?
It's also the convention Boyd's uses in his book.
|
The trade-off is that the solvers where we care about an efficient direct mode are unlikely to natively support |
No because the only cases that will change are cases that were previously erroring. The scalar |
| ) | ||
| @test_throws_strip err @constraint(model, [x, 2x] == [1 - x, 3]) |
There was a problem hiding this comment.
Here's an example of code that previously errored
|
I guess it's ok then. It's a bit confusing that we'll allow both |
| Make sure to use [Julia's dot syntax](https://docs.julialang.org/en/v1/manual/functions/index.html#man-vectorized-1) | ||
| in front of the comparison operators (for example, `.==`, `.>=`, and `.<=`). If you | ||
| use a comparison without the dot, an error will be thrown. | ||
| The two constraints, `==` and `.==` are similar, but subtly different. The first |
There was a problem hiding this comment.
Is this bit of the documentation enough to describe the differences?
This change enables
Ax >= bto be lowered toAx - b in Nonnegatives(), and removes the confusing Vector-in-GreaterThan(0) method in build_constraint that asserted the right-hand side was zero.Closes #3265
I'm not sure why it didn't occur to me to do this ages ago.