Integrality Tolerance in MIP: How Close Is “Integer Enough”?
Integrality tolerance decides when a variable value is considered “integer” by a solver. It balances numerical stability with discrete accuracy—and it’s separate from the optimality gap.
This calculator exposes the integrality tolerance as a setting: try different values in the ILP/MILP calculator and watch when solutions flip from “integer-feasible” to “not integer” in the branch-and-bound steps.
On this page
- Quick takeaway
- What is integrality tolerance?
- How solvers use integrality tolerance internally
- Questions people ask about integrality tolerance
- Typical default values and recommended ranges
- What happens if you tighten or loosen the tolerance?
- Integrality tolerance vs optimality gap (don’t mix them)
- Worked examples (and what to look for)
- Common mistakes & safe adjustment rules
- What to do next
Quick takeaway:
Integrality tolerance is the numerical threshold used to decide whether an apparently fractional variable value
should be treated as integer. If |x − round(x)| ≤ tol, the solver counts x as integer.
Typical values are between 1e-9 and 1e-6.
Changing it affects which solutions are considered integer-feasible, but it does not change the definition of
the optimality gap.
What is integrality tolerance?
Definition
Plain-English definition with the actual test
Solvers rarely get exact integers like 1.0000000000 due to floating-point arithmetic. Instead, they use a test:
|x - round(x)| ≤ tol ⇒ treat x as integer
Here tol is the integrality tolerance.
If the difference between x and the nearest integer is below tol, the solver considers the variable “integer enough”
for feasibility and branching decisions.
How solvers use integrality tolerance internally
Mechanics
Three main places tolerance shows up
- Feasibility checks: deciding whether a candidate solution satisfies integer constraints.
- Branching decisions: determining which variables are “fractional enough” to branch on.
- Reporting: printing “x ∈ {0,1}” in solution summaries even when values are stored as floating-point approximations.
In the ILP/MILP calculator, the “Integrality tol” setting directly controls this test.
Questions people ask about integrality tolerance
People ask
What is a good integrality tolerance value?
Many production solvers default to something like 1e-6 or 1e-9.
Smaller values are stricter (fewer “nearly integer” values accepted), but can be more sensitive to numerical noise.
Larger values are more forgiving but can accept visibly fractional values as “integer.”
People ask
Does integrality tolerance affect the optimality gap?
Not directly. The optimality gap compares objective values of the incumbent and best bound (see optimality gap in MIP). Integrality tolerance affects which solutions count as integer-feasible, which indirectly influences which incumbents are possible, but the formula for gap itself is separate.
People ask
Can changing integrality tolerance make the solver faster?
Sometimes—but usually only subtly. Looser tolerance can prevent over-branching on tiny numerical deviations. However, if you loosen it too much, you may accept solutions that are visually non-integer or violate discrete logic. It’s almost always better to fix scaling/bounds first before tweaking tolerance.
Typical default values and recommended ranges
Defaults
What major solvers use (approximate ranges)
| Solver (indicative) | Typical integrality tolerance | Notes |
|---|---|---|
| Gurobi | ~1e-5 to 1e-6 (IntFeasTol parameter) | Can be adjusted; defaults tuned to double-precision numerics. |
| CPLEX | ~1e-5 (epint) | Adjustable but rarely needs manual tuning. |
| Open-source MIP solvers | Often 1e-6 or similar | Exact value depends on implementation. |
1e-9, emphasizing clarity in small teaching examples.
For large, scaled industrial models, values such as 1e-6 are common.
What happens if you tighten or loosen the tolerance?
Effects
Tightening integrality tolerance (e.g., from 1e-6 to 1e-9)
- Fewer values will be treated as “integer enough.”
- The solver may need to branch more to drive variables closer to exact integers.
- You reduce the risk of accepting solutions with visible fractional parts.
Effects
Loosening integrality tolerance (e.g., from 1e-6 to 1e-4)
- More values (like 0.00009 or 0.99991) will count as integer.
- You might see slightly faster solves if the model was over-branching due to tiny violations.
- You risk treating noticeably fractional values as binaries/integers if the model is poorly scaled.
Safe rule: treat tolerance as a numerical safeguard, not a knob for “fixing” modeling issues. If you’re tempted to set a very large tolerance, fix scaling and bounds instead.
Integrality tolerance vs optimality gap (don’t mix them)
Conceptual separation
Two different questions entirely
| Concept | What it controls | Where it appears |
|---|---|---|
| Integrality tolerance | How close a variable must be to an integer to count as integer-feasible. | Feasibility checks, branching, printed solution values. |
| Optimality gap | How far the incumbent’s objective may be from the true optimum. | Stopping criteria, solver logs, and quality certificates. |
For the gap itself, see optimality gap in MIP.
Worked examples (and what to look for)
Worked example
Example: variable at 0.9999998 with tolerance 1e-6 vs 1e-9
|x - round(x)| = |0.9999998 - 1| = 2e-7
- With
tol = 1e-6,2e-7 ≤ 1e-6→ treated as integer (OK). - With
tol = 1e-9,2e-7 > 1e-9→ not integer; solver will try to improve integrality.
In the ILP/MILP calculator, you can adjust the integrality tolerance and see when a solution is accepted or rejected as integer-feasible in the branch-and-bound steps.
Common mistakes & safe adjustment rules
Mistakes
Mistake: using integrality tolerance to “hide” modeling or scaling issues
If your variable values are off by 0.01 or 0.1 from integers, the issue is almost never tolerance—it’s:
- Bad scaling (huge/small coefficients),
- Loose or inconsistent bounds,
- Incorrect or missing constraints.
Fix those first; only then consider fine-tuning tolerance.
Mistakes
Mistake: assuming tighter tolerance always improves solution quality
Overly tight tolerance can cause:
- Longer runtimes (more branching to achieve strict integrality),
- False “infeasible” or “no incumbent” outcomes in numerically delicate models.
If your model is well-scaled and your solver is stable, defaults are usually good enough.
What to do next
Next steps
Experiment safely with the ILP/MILP calculator
- Load a small ILP example in the ILP/MILP calculator.
- Solve with the default integrality tolerance and note the solution values.
- Tighten the tolerance (e.g., 1e-9) and observe whether more branching or different node behavior occurs.
- Loosen it (e.g., 1e-4) and see when solutions with visible fractional parts start to be accepted.
Connect what you see to LP relaxation bound and optimality gap to build intuition about numerical vs structural issues.
Disclaimer
This explanation of integrality tolerance and the associated calculator settings is provided for educational and informational purposes only. Actual MIP solver behavior depends on many numerical and implementation details beyond this overview. Do not rely solely on these settings or this article for high-stakes optimization decisions without verifying behavior in your target solver and consulting its official documentation.