This is another modeling tool for Python.
There are quite a few modeling tools available for Python: Pyomo, PuLP, and most commercial LP/MIP solvers some with some Python modeling layer.
This is what caught my eye when reading about Python-MIP:
In [3] an interesting question came up. The value of an integer variable is often slightly non-integer. E.g. something like 0.0000011625. This is the result of the integer feasibility tolerance that a solver applies. In the discussion [3] the remark is made:
![]()
I believe there is more to this. Rounding integer solutions can lead to larger infeasibilities. With some aggressive presolve/scaling these infeasibilities can sometimes be large after postsolve/unscaling. Also: some equations may have long summations of binary variables. This would accumulate a lot of rounding errors. And then there are these big-M constraints....
It also means that using the steps:
may lead to "feasible" for the first solve, but "infeasible" for the second solve. E.g. when we want duals for the fixed LP we use this "fix integers" step.
Safer would be to tighten the integer feasibility tolerance. Cplex even allows epint=0 (epint is Cplex's integer feasibility tolerance). Of course tightening the integer feasibility tolerance will likely lead to longer solution times.
Indeed, modeling systems and solvers currently handle this by offloading the problem to the user. The solver is probably the right place to deal with this. Not sure developers are eager to work on this. Taking responsibility by simple-minded rounding may be asking for more problems than it solves.
There are quite a few modeling tools available for Python: Pyomo, PuLP, and most commercial LP/MIP solvers some with some Python modeling layer.
This is what caught my eye when reading about Python-MIP:
- The name is rather unimaginative.
- Looks like the authors are from Brazil.
- Supported solvers are CBC and Gurobi.
- The Python-MIP is compatible with the just-in-time compiler PyPy, which can lead to substantial performance improvements.
- It is claimed that with PyPy jit, python-MIP can be 25 times as fast than the Gurobi modeling tool.
- There are some interesting facilities supported by Python-MIP:
- Cuts can be provided using a call-back mechanism
- Support for MIPSTART (initial integer solution)
- Solution pool
Question
In [3] an interesting question came up. The value of an integer variable is often slightly non-integer. E.g. something like 0.0000011625. This is the result of the integer feasibility tolerance that a solver applies. In the discussion [3] the remark is made:
I believe there is more to this. Rounding integer solutions can lead to larger infeasibilities. With some aggressive presolve/scaling these infeasibilities can sometimes be large after postsolve/unscaling. Also: some equations may have long summations of binary variables. This would accumulate a lot of rounding errors. And then there are these big-M constraints....
It also means that using the steps:
solve
fix solution (or fix integers) to optimal solution
solve
may lead to "feasible" for the first solve, but "infeasible" for the second solve. E.g. when we want duals for the fixed LP we use this "fix integers" step.
Safer would be to tighten the integer feasibility tolerance. Cplex even allows epint=0 (epint is Cplex's integer feasibility tolerance). Of course tightening the integer feasibility tolerance will likely lead to longer solution times.
Indeed, modeling systems and solvers currently handle this by offloading the problem to the user. The solver is probably the right place to deal with this. Not sure developers are eager to work on this. Taking responsibility by simple-minded rounding may be asking for more problems than it solves.
On the other hand, these slightly fractional values certainly cause confusion. Especially for beginners in MIP modeling.
So the question remains: is rounding integer variables a good idea?
So the question remains: is rounding integer variables a good idea?