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
Is your feature request related to a problem? Please describe.
Mathoptinterface offers automatic and well tested "advanced" constraints, e.g. SOS constraints. It would be nice to offer those within Optimzation.jl.
As a motivating example consider the sparse regression problem (😅), which can either be modeled with integer variables $z_i \in \lbrace 0, 1\rbrace$ using a big-M formulationin the constraints
I think the nicest solution would be something along
@variablesbegin
x::Float64 [description="Parameter with value"]
c::Int [bounds = (0,1), description ="Integer decision"]
end
constraint = [
SOS1(x, 1-c)
]
which indicates the right constraints.
Given that these constraints add variables and might become complicated, a transformation step could be added in the expression simplifcation routine of OptimizationMOI. This way only "dummy" constraints must be added and registered.
# Something along the lines of ...if ex.args[1] == SOS1
MOI.add_constraint(..., ....)
end...
Describe alternatives you’ve considered
Instead of relying on MOI we could add functions returning the internal representation of the constraint. This would be more universal, but might end buggy and adds to the maintenance stack.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Mathoptinterface offers automatic and well tested "advanced" constraints, e.g. SOS constraints. It would be nice to offer those within Optimzation.jl.
As a motivating example consider the sparse regression problem (😅), which can either be modeled with integer variables
$z_i \in \lbrace 0, 1\rbrace$ using a big-M formulationin the constraints
or with the special ordered set 1 type constraint
which mathoptinterface expands internally.
Describe the solution you’d like
I think the nicest solution would be something along
which indicates the right constraints.
Given that these constraints add variables and might become complicated, a transformation step could be added in the expression simplifcation routine of OptimizationMOI. This way only "dummy" constraints must be added and registered.
Describe alternatives you’ve considered
Instead of relying on MOI we could add functions returning the internal representation of the constraint. This would be more universal, but might end buggy and adds to the maintenance stack.
The text was updated successfully, but these errors were encountered: