A packing row says usage ≤ availability. Its coefficients are per-unit rates read down a column of a data table, and the gap it leaves at a point is that resource's slack, measured in the resource's own unit. A row with no slack left is tight, and this lesson is careful about what tight does and does not tell you.
Core ideas
One shape, repeated once per resource. The interesting content is in the slacks, and in one thing they cannot tell you.
Every ≤ row in this family is the same sentence: what the plan consumes of one resource, at most what there is of it. The row belongs to the resource, not to the product, so three products and three shops give three rows and not nine.
The assembly row 3C + 2T ≤ 18 takes its 3 from the chairs column of the assembly row of the table and its 2 from the tables column. Reading the table across instead of down transposes the model into a different, solvable, wrong one, which is why the lab prints the table beside the programme it produced.
At (2, 6) the carpentry row has 2 bench hours left and the other two rows have nothing left. That number is not a score and not a percentage: it is hours, and the same optimum has a slack in each row measured in a different unit.
The material
One row per resource, read off a table; the slacks at the optimum; and the question this course deliberately cannot answer yet.
The data arrive as a table, and the model is a transcription of it. Rates down the columns, availabilities down the right, and the profit row underneath.
For a row a·x ≤ b and a point x, the slack of the row at x is b − a·x. It is at or above zero exactly where the row holds, and the row is tight at x when the slack is zero.
Slack is a quantity in the situation and not a diagnostic: the slack in the carpentry row is the bench hours the plan leaves unused. “Standard Form, Slack and Surplus” promotes it to a variable of the model; here it is only computed.
The two-product workshop is worth 36 at (2, 6), and the slacks there are 2 bench hours, 0 finishing hours and 0 assembly hours. Two of the three rows are used right up, which is the usual state of affairs: an optimum of a two-variable programme sits where two boundaries cross.
Let the workshop also make benches, at 1 bench hour, 1 finishing hour and 2 assembly hours each, earning 4. The table grows a column, every row grows a term, and the optimum becomes 75/2 at (1, 9/2, 3) with all three rows tight. Two things changed. The answer is a fraction, and there is no longer a picture: three decisions cannot be drawn on a plane, so the lab hands the programme to the exact simplex instead of enumerating corners.
Both routes are solving the same kind of object and they agree wherever they overlap — pin the bench column at zero and the engine returns 36 again. That agreement is worth more than either method alone, because it is the only evidence that the picture was a method and not a habit.
A tight row is a resource the plan has used up. It is tempting to read that as “the bottleneck”, and to conclude that one more hour of it would buy something. It need not.
Push the assembly line to 24 hours. The optimum moves to (4, 6) and earns 42, and now all three rows are tight: 4 ≤ 4, 12 ≤ 12 and 24 ≤ 24. Add a twenty-fifth assembly hour and the answer is still 42, with one assembly hour idle. Add a bench hour and it is still 42. Add two finishing hours and it is 45. Three resources exhausted, one of them worth paying for.
What separates them is a number this course cannot yet compute: the change in the optimum for one more unit of a resource, and the range of availabilities over which that change is the truth. It is called a shadow price, it is “Duality and Sensitivity Analysis”, and the honest report here is that a tight row names a resource the plan exhausted and says nothing about what relieving it would be worth.
The slacks do settle a smaller question completely, and it is worth having. A row with slack left is a row that is not currently deciding anything: change its availability by less than its slack and neither the plan nor the profit moves at all.
Interactive
Per-unit rates down the columns, availabilities down the right
Method
The table is the model. These four steps are a transcription with two checks in it.
Count the rows of your model before writing them: as many as there are things in limited supply. A row for each product is the commonest transposition, and it produces a model about nothing at all.
The chairs column of the table supplies the coefficient of C in every row. Write the column out beside the rows it feeds if the table is wide; a misplaced rate is invisible once the programme is written.
hours per unit × units is hours, and the availability is hours of the same shop. When a rate is quoted in minutes and an availability in hours, that is a real error and the only place it shows is here.
Which rows are tight is the structural fact about the solution; the objective value is one number. Note the slacks in their own units, and resist the conclusion that a tight row is worth relieving.
The two-product version is worth 36 at (2, 6) and can be drawn. Adding the bench column removes the picture and changes the kind of answer, so it is the case worth writing out in full.
Every row is tight, the plan asks for four and a half tables, and 75/2 is not a number a decimal would have kept. A reader who wanted whole tables has a real question and it is answered in “Integer Programming”, not by rounding — that warning is the standing one on this course.
For a faded rehearsal, drop the bench column and take the finishing shop from 12 hours to 13. The supplied first move is which rows can possibly change: only the ones that were tight, because a row with slack to spare is not deciding anything. Predict the new plan and profit, then check it against the lab, and say in a sentence why the carpentry slack grew rather than shrank.
You should be able to transcribe a rate table into rows and columns without transposing it, compute the slack in every row at a given point in that row's own unit, and state what a tight row does and does not settle.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.