A common source of numerical issues is numerical rounding in the numbers that are used to represent constraint matrix coefficients. To illustrate the issue, consider the following example:
It may be tempting to say that the two equations are equivalent, but adding both to a model will lead to an incorrect result. This is an important point for our users: Gurobi will always trust the input numbers that they provide, and will never change them unless the change can be shown to not affect the solution.
So, with this in mind, during presolve Gurobi can use the second
constraint to determine:
When substituted into the first constraint, this yields
and thus as the only solution.
If user had provided these two equations instead:
this would give:
Even with a very small threshold for treating a coefficient as zero, the result here is that the first constraint is truly redundant. Any solution with would be accepted as feasible.
The main point is that constraints that are exactly parallel, or linearly dependant (within double-precision floating-point and small tolerances) are harmless, but constraints that are almost parallel to each other produce tiny coefficients in the linear system solves and in preprocessing, which can wreak havoc on the solution process. In the next section, we expand on the limits double-precision floating-point numbers, and in particular why .