Revision history [back]
 | 1 | initial version |
The primary resource for these question is the documentation: http://doc.sagemath.org/html/en/reference/numerical/sage/numerical/mip.html
as is explained there, the indexing of variables (so, how you refer the the indices in your code) is very flexible, and you can just use multi-indices as you like: the interface will keep track of the indices you use and map them to an internal index. The printing of variables is a little more restricted: it looks like variables just always print in the form <name>_<index>.
You can use variables with other names, but presently this seems to be relatively limited:
sage: p = MixedIntegerLinearProgram(solver='GLPK')
sage: x = p.new_variable(real=True, nonnegative=True, name='X')
sage: y = p.new_variable(integer=True, nonnegative=True, name='Y')
sage: x[1],x[2],y[1],y[2]
(x_0, x_1, x_2, x_3)
As the documentation says:
- "name" -- string. Associates a name to the variable. This is only useful when exporting the linear program to a file using "write_mps" or "write_lp", and has no other effect.
so it looks like presently, the name argument is essentially a no-op. It suggests that presently, there is excellent support for writing linear programming problems with very rich variable names and indexing, but the printing seems to focus on the linear algebra representation of the problem, where your variables are just entries in a vector. It would seem this could be changed, but might require discussion if the benefits of that are worth the breaking of backwards compatibility that it would entail.
From a teaching point of view, there is an argument to be made that helping people understand that variables are just entries in a vector (and therefore are naturally labeled with x_0,x_1,x_2,...), but printing that is a little closer to the commands used to input the problem would also be nice; especialy given that x_0,x_1, ... are NEVER appropriate names to refer to variables in a MIP.
So ... DEFINING the things you want seems to be fully supported, but having them PRINT in a way that reflects it seems not to be.
| | 2 | No.2 Revision |
The primary resource for these question is the documentation: http://doc.sagemath.org/html/en/reference/numerical/sage/numerical/mip.html
as is explained there, the indexing of variables (so, how you refer the the indices in your code) is very flexible, and you can just use multi-indices as you like: the interface will keep track of the indices you use and map them to an internal index. The printing of variables is a little more restricted: it looks like variables just always print in the form <name>_<index>.
You can use variables with other names, but presently this seems to be relatively limited:
sage: p = MixedIntegerLinearProgram(solver='GLPK')
sage: x = p.new_variable(real=True, nonnegative=True, name='X')
sage: y = p.new_variable(integer=True, nonnegative=True, name='Y')
sage: x[1],x[2],y[1],y[2]
(x_0, x_1, x_2, x_3)
As the documentation says:
- "name" -- string. Associates a name to the variable. This is only useful when exporting the linear program to a file using "write_mps" or "write_lp", and has no other effect.
so it looks like presently, the name argument is essentially a no-op. It suggests that presently, there is excellent support for writing linear programming problems with very rich variable names and indexing, but the printing seems to focus on the linear algebra representation of the problem, where your variables are just entries in a vector. It would seem this could be changed, but might require discussion if the benefits of that are worth the breaking of backwards compatibility that it would entail.
From a teaching point of view, there is an argument to be made that helping people understand that variables are just entries in a vector (and therefore are naturally labeled with x_0,x_1,x_2,...), but printing that is a little closer to the commands used to input the problem would also be nice; especialy given that x_0,x_1, ... are NEVER appropriate names in a sage session to refer to variables in a MIP.
So ... DEFINING the things you want seems to be fully supported, but having them PRINT in a way that reflects it seems not to be.
