Driving a Linear Programming Solver
Getting a formulated program into the argument form a particular solver expects, and reading its output back into the model's own terms. The mathematics is unchanged; what varies is the convention each tool imposes and the places a mismatch produces a confident wrong answer.
Definition
A solver accepts a program in one fixed form and reports a status, a point and an objective value. Using one is a three-part translation.
Into the solver's form. Each tool fixes a direction and a way of expressing constraints, and a program not already in that shape must be converted before entry. The conversions are the standard-form ones, applied to satisfy an interface rather than a theorem: a maximisation is entered as
The invocation. Coefficients are supplied as arrays whose positions carry meaning: column
Back out of it. The reported point is indexed the same way, so reading it means applying the same correspondence in reverse. When the objective was negated to fit the interface, the reported value is
What the tool does not do. It optimises the program it received. Whether that program represents the described situation is outside its scope, and a successful status is evidence about the arithmetic, never about the modelling. This is why the verification checks are applied to the original model rather than to the solver's restatement of it.
Assumptions and scope
The program is already correctly formulated. Everything here is about entry and retrieval, and a faithful invocation of a wrong model returns a confident wrong answer.
Interfaces change. Specific menus, argument orders and option names are cited to vendor documentation and will drift; the conventions they express are what the unit teaches.
Floating-point tolerances mean a reported point may satisfy constraints only approximately. A value of 79.9999999 against a limit of 80 is a tolerance artefact rather than a violation, and distinguishing that from a real breach is part of reading output.
The unit covers linear programs only. Integer restrictions change which routine applies and what a returned bound means.
A solver reporting infeasible or unbounded is making a claim about the program it received, which may be a claim about a transcription error rather than about the situation.
Worked material
Contrast
Solving by hand against solving with a tool
| By hand | With a solver | |
|---|---|---|
| Scale | a few variables and constraints | thousands, routinely |
| Where errors arise | arithmetic within a known method | translation at the model–interface boundary |
| How errors show | a pivot that will not complete, a negative right-hand side | a clean status on the wrong program |
| What is visible | every intermediate quantity | the final answer, and whatever the tool chooses to report |
| What must be checked | the arithmetic | that the program entered is the model written |
The error profile inverts. Hand computation fails noisily: a wrong ratio test produces an infeasible point that the next step exposes. Tool use fails silently, because the tool has no view of what you meant and every syntactically valid program has an answer.
Why hand methods are still learned. Not as a substitute, nobody pivots a thousand-variable program by hand, but because the reported output is written in their vocabulary. A shadow price is a dual variable; a degenerate warning is a basic variable at zero; a variable at its bound is nonbasic. Without the methods, those outputs are strings rather than information.
What the tool adds that hand methods cannot. Sensitivity analysis on a realistic model, re-solving under changed data in seconds, and scale. The workshop example's binding pattern, capacity limiting, demand not, invites asking what an extra machine-hour is worth, and that question is answerable in one further run.
Where the competences meet. Verification is the same work in both cases: substitute into the constraints as written, recompute the objective, judge the status. The difference is that a hand solution's arithmetic is also open to inspection, whereas a solver's is not, which makes verification against the original model more important with a tool, not less.
Common errors
Common misconception
A solver reporting an optimal status confirms that the model is correct, so once the tool runs cleanly the formulation no longer needs checking.
Common misconception
A solver works out from the problem whether to maximise or minimise, so a maximisation's coefficients can be entered directly into any solver and the reported objective value read off as it stands.