# Convert ILP variables to strict integer values in JuMP

**URL:** <https://discourse.julialang.org/t/convert-ilp-variables-to-strict-integer-values-in-jump/71957>\
**Category:** Optimization (Mathematical)\
**Tags:** jump\
**Created:** [November 23, 2021, 4:52pm UTC](https://discourse.julialang.org/t/convert-ilp-variables-to-strict-integer-values-in-jump/71957 "2021-11-23T16:52:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![filchristou](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/filchristou/32/26760_2.png) [@filchristou](https://discourse.julialang.org/u/filchristou)\
**Post date:** [November 23, 2021, 4:52pm UTC](https://discourse.julialang.org/t/convert-ilp-variables-to-strict-integer-values-in-jump/71957/1 "2021-11-23T16:52:50Z")

</div>

It has often happened that after solving a MILP, my integer or binary variables are getting a value something like `4.237436454375536e-11` or `1.0000000000008162` or even `4.0`. In other words even though a variable is meant to be Integer or Binary it gets real values.

I understand that probably the backend solvers (e.g. CPLEX) are using real numbers to solve the mathematical programming problem.

But since JuMP knows the model description, wouldn’t it be easy to apply a conversion of the solved variables after the backend finished calculations, so that the user directly gets something that would be more reasonable (e.g. `0` instead of `4.237436454375536e-11`) ?

Something like that would make it more convenient to do the metaanalysis of the solution.

---

<div class="post-metadata">

**Author:** ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)\
**Post date:** [November 23, 2021, 7:50pm UTC](https://discourse.julialang.org/t/convert-ilp-variables-to-strict-integer-values-in-jump/71957/2 "2021-11-23T19:50:01Z")

</div>

JuMP forces the user to explicitly deal with the non-integrality of solutions returned by a solver.

It’s important that users understand solvers are not using exact arithmetic, and that numerical issues can arise. As one example, “optimal” integer solutions rounded to exact integers may be infeasible. (You’ll often see this with big-M type constraints, where a binary variable might take `1e-8`, but when multiplied by a large M the term becomes significant.)

Gurobi has a good series of documentation on this:

> **[Guidelines for Numerical Issues - Gurobi Optimization](https://www.gurobi.com/documentation/9.1/refman/guidelines_for_numerical_i.html)**
>
> Guidelines for Numerical Issues