(a) The picks are x1,x2 → 2 decision variables.
(b) One slack per ≤ constraint (not counting x≥0, which is handled by keeping variables
non-negative). Two constraints → 2 slacks s1,s2.
(c) Total = decisions + slacks =2+2=4.
Non-basic x1=x2=0, so the corner is the ==origin (0,0)==. Then z=5(0)+4(0)=0.
The slacks s1=24,s2=6 just say "at the origin all the resource is still unused" — both
constraints are slack, neither is tight.
Slacks:x1+s1=4,2x2+s2=12,3x1+2x2+s3=18. The z-row is z−3x1−5x2=0, i.e.
coefficients (−3,−5).
Enter: most negative is −5 under x2 → x2 enters (raising x2 raises z fastest per unit).
Ratio test — only rows where the x2-column entry is positive:
Row s1: x2-entry is 0 → skip (a 0 never bounds the increase).
Row s2: 12/2=6.
Row s3: 18/2=9.
Smallest ratio is 6 → s2 leaves. Pushing x2 to 6 makes s2=0 (constraint 2x2≤12
becomes tight) while others stay ≥0.
New corner:x1=0,x2=6, so (0,6) with z=3(0)+5(6)=30.
After the first pivot, x2 is basic (=6), and the z-row still has a negative under x1, so we
pivot again. Carrying the row-reduction to completion (enter x1, ratio test picks the
3x1+2x2≤18 row) lands us at the intersection of 2x2=12 and 3x1+2x2=18:
2x2=12⇒x2=6,3x1+2(6)=18⇒3x1=6⇒x1=2.
Corner (2,6), and z=3(2)+5(6)=6+30=36. The z-row is now all ≥0 → optimal.
Check the third constraint on the way: x1=2≤4 ✓, both used up sensibly. See the corner walk in
the figure below.
The z-row equation is z=2x1+7x2−4s2 (move the negatives across). So ∂z/∂x2=7, the largest positive rate. x2 enters — increasing it raises z by 7 per
unit, more than x1's 2; the s1,s2 columns (0 and +4) either help nothing or reducez,
so we would never increase them. "Most negative in the z-row" is exactly "biggest positive rate of
gain".
Yes — optimal, because everyz-row coefficient is ≥0. Reading z=(const)−3x2−1s1−5(⋅): raising any currently-non-basic variable can only lowerz (a 0 leaves
it unchanged). With no direction of improvement left, we sit on the top corner. This is the parent
note's optimality test stated as a picture: the objective ramp no longer tilts uphill in any
feasible direction.
Why negate? The simplex loop is built to maximize. Minimizing z is the same as maximizing
w=−z=x1+3x2, since minz=−max(−z).
Slacks:x1+x2+s1=5,x1+2x2+s2=8. The w-row coefficients are (−1,−3).
Pivot 1 — enter x2 (most negative −3). Ratios: 5/1=5, 8/2=4 → s2 leaves.
New corner: on the line x1+2x2=8 with x1=0 → x2=4, giving (0,4), w=3(4)=12.
The w-row still shows a negative under x1, so continue.
Pivot 2 — enter x1. The binding pair is x1+x2=5 and x1+2x2=8. Solve:
subtract: (x1+2x2)−(x1+x2)=8−5⇒x2=3,x1=5−3=2.
Corner (2,3): w=2+3(3)=2+9=11? Check both objectives carefully:
w=x1+3x2=2+9=11. Compare (0,4): w=12. Since 12>11, the corner (0,4) is actually
the better one for w — the x1 column would not improve w here, so the w-row is already
all ≥0 after pivot 1. Optimum: (0,4), w=12.
Therefore minz=−w=−12 at (0,4).
(Moral: always evaluate — the ratio/entering rules propose a move, but the optimality test is what
confirms you have arrived.)
By strong duality, the dual's optimal (a minimization) equals the primal's optimal. So the dual
optimum is 36. Usefulness: after you finish the primal by simplex, computing any feasible
dual solution with value 36proves you reached the true optimum — a second, independent
certificate beyond "the z-row went all non-negative". This is why the tableau's final z-row entries
under the slack columns are exactly the dual variable values.
A tie means the entering variable hits two constraints at the exact same value — more than m
constraints pass through one corner. That corner is degenerate (over-determined). Practical danger:
a pivot may swap basis variables while zdoes not change (a "stall"), and in rare cases the
method can cycle back to a basis it already visited, never terminating. Fixes: Bland's rule
(break ties by choosing the variable with the smallest index) guarantees termination. Geometrically the
vertex is fine; the bookkeeping just needs an anti-cycling tie-break.
Slack: x1−x2+s1=1. The z-row is (−1,−1); say x2 enters. Its column entry in the only
constraint row is −1 (negative). The ratio test uses only positive entries — there are
none. That means: as x2 grows, s1=1−x1+x2grows too, so no constraint ever stops
x2. We can raise x2 (and z) without limit → the LP is unbounded, z→+∞.
The signal in the tableau: a negative z-row entry whose entire column has no positive entry =
unbounded objective. (See figure — the feasible region opens upward forever.)
Convert the ≥: x1+x2≥5⇒−(x1+x2)≤−5, whose RHS is −5<0. The basic
starting solution x1=x2=0 gives slack =−5<0 → not feasible, so the origin is not a valid
starting corner; plain simplex needs b≥0. The one-line reason no solution exists: a sum
cannot be both≤2 and ≥5, so the feasible region is empty (the two half-planes never
overlap). Handling requires the two-phase or Big-M method to find a feasible corner first —
which here reports infeasibility.
The entering variable is the one with the most negative z-row coefficient.
The leaving variable is chosen by the smallest positive ratio RHS ÷ column entry.
We stop when every z-row coefficient is ==≥0.
A ratio-test column with no positive entries signals an unbounded objective.
A tie in the ratio test signals a degenerate== vertex and risks cycling.