You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As suggested by @odow in this discussion, I report a possible enhancement of error message when one inadvertidly uses broadcasted vector bounds when creating a vector of JuMP variables.
Considering the following preamble code,
using JuMP
model =Model()
xmax = [10., 0.]
the correct way to have a variable x<=xmax elementwise is by using an explicit indexing variable (which is documented, but not exactly for this vector slicing usecase)
@variable(model, x[i=1:2] <= xmax[i])
However, there is a wrong approach that someone can easily follow (at least I did -;)), using broadcasting on the comparison operator:
@variable(model, x[1:2] .<= xmax)
which yields the surprising error message:
ERROR: LoadError: In `@variable(model, x[1:2] .<= xmax)`: Unknown sense .<=.
Also, in the case of two bounds, with the same mistake:
@variable(model, 0<= x[1:2] .<= xmax)
the error message is different but also not helpful:
ERROR: LoadError: In `@variable(model, 0 <= x[1:2] .<= xmax)`: Use the form lb <=...<= ub.
Expected behavior: in an ideal world, the error message would point out to the correct solution (ex : "broadcasted constraints are not yet supported, use ... instead"). Alternatively, it may be worth supporting the broadcasted syntax, but I don't have enough background on JuMP to judge the difficulty of the task. This last idea may relate to the closed issue #1455, although it was about applying broadcasting on the set_lower_bound function not within the @variable macro.
The text was updated successfully, but these errors were encountered:
Hello,
As suggested by @odow in this discussion, I report a possible enhancement of error message when one inadvertidly uses broadcasted vector bounds when creating a vector of JuMP variables.
Considering the following preamble code,
the correct way to have a variable
x<=xmax
elementwise is by using an explicit indexing variable (which is documented, but not exactly for this vector slicing usecase)However, there is a wrong approach that someone can easily follow (at least I did -;)), using broadcasting on the comparison operator:
which yields the surprising error message:
Also, in the case of two bounds, with the same mistake:
the error message is different but also not helpful:
Expected behavior: in an ideal world, the error message would point out to the correct solution (ex : "broadcasted constraints are not yet supported, use ... instead"). Alternatively, it may be worth supporting the broadcasted syntax, but I don't have enough background on JuMP to judge the difficulty of the task. This last idea may relate to the closed issue #1455, although it was about applying broadcasting on the
set_lower_bound
function not within the@variable
macro.The text was updated successfully, but these errors were encountered: