Operations Research Methods

How to Interpret Sensitivity Analysis in Linear Programming Without Confusing Optimality Criteria

Students often misinterpret solver reports by conflating linear programming (LP) local optima with integer programming (IP) global optima. This article outlines a methodological framework for identifying constraints, interpreting integer tolerance, and presenting these technical details naturally in academic reports.

In operations research or financial modeling assignments, sensitivity analysis typically appears as a solver report where students must identify binding constraints or interpret the impact of coefficient changes. The most common sticking point is not the calculation itself but the confusion over the definition of 'optimality.' Specifically, in integer programming (IP), when a solver displays an integer tolerance of zero, many students assume this guarantees a global optimum, overlooking the fundamental distinction between the LP relaxation and the integer solution.

The logical framework for solving these problems involves three steps. First, distinguish the problem type: confirm whether the model is a pure LP or a mixed-integer program. Second, for LPs, focus on the 'Range of Optimality,' which defines the coefficient range that preserves the optimal basis. Third, for IPs, verify the solver status by distinguishing between 'Optimal' and 'Upper/Lower Bound.' If the integer tolerance is set to zero, it indicates the algorithm seeks a fully integer-feasible solution, but this does not automatically guarantee global optimality relative to the LP relaxation unless the report explicitly declares it.

The most frequent error is conflating LP and IP optimality criteria. When a solver shows an integer tolerance of zero, students often mistake any feasible integer solution for the global optimum. In reality, a zero tolerance only means the algorithm requires exact integer feasibility; if the search terminates early due to time or node limits, the returned solution may be local or heuristic. Citing this solution as final without checking for a 'Proven Optimal' status introduces bias, rendering subsequent interpretations of shadow prices or marginal contributions invalid.

Before submitting, perform these self-check actions. First, rerun the model and confirm the solver log includes a 'Global Optimum Found' declaration, not just a 'Feasible Solution.' Second, check the integer tolerance setting; if it is zero, ensure a full branch-and-bound search was executed. Third, compare the objective value of the LP relaxation with the current integer solution to calculate the gap, ensuring it is within acceptable limits. These steps validate the solution's integrity and prevent unsupported optimality claims in your report.

When writing the discussion section, avoid mechanical phrases like 'since p < 0.05, we reject H0.' Instead, specify: 'Under a zero integer tolerance, the solver's solution exhibits a negligible gap relative to the LP relaxation, thus considered an approximate global optimum.' Retain the numbers (e.g., gap percentage), terms (e.g., branch-and-bound, integer tolerance), and causal direction (tolerance settings affect solution precision) during rewriting. easydue can assist here, helping you make your technical expression more natural and aligned with academic writing standards, rather than a stack of rigid formulas.