3.7.5 · D5Algorithm Paradigms
Question bank — When greedy fails — 0 - 1 knapsack counter-example
These items lean on ideas from the parent note: Greedy Algorithms, Fractional Knapsack, Dynamic Programming, the Greedy-Choice Property, and the Exchange Argument.
The symbols this page uses (read first)
True or false — justify
Greedy by value-density always gives the optimal 0/1 knapsack answer.
False. On with A(10,60), B(20,100), C(30,120) it takes A+B = 160, but B+C = 220 fills the bag exactly; the integrality constraint lets a dense item waste capacity.
Greedy by value-density always gives the optimal fractional knapsack answer.
True. With slivers allowed you can top the bag off to exactly using a fraction of the next item, so no capacity is wasted and the Exchange Argument holds.
If greedy fills the bag to exactly capacity , its answer must be optimal.
False. Filling to removes the "wasted capacity" symptom but not the disease — a full bag of low-value items can still be beaten by a different full (or even lighter) higher-value subset.
The optimal 0/1 solution always uses at least as much weight as greedy's.
False. Optimality maximizes value, not weight; the best subset can weigh less than greedy's if that lighter combination happens to be worth more.
With capacity , the item with the single highest value is always in some optimal knapsack.
False. A high-value but heavy item can monopolize capacity — a value-130-weight-50 item exactly fills alone, blocking the (100,30)+(120,30)=220 pair (weights ), so the 130-item is excluded from the optimum.
Sorting by value-density and by raw value give the same greedy pick order.
False. Density and value rank items differently; a low-value light item can out-rank a high-value heavy one on density.
0/1 knapsack has optimal substructure.
True. The best solution using items decomposes into the best sub-solution over ; that is exactly what the DP recurrence exploits.
0/1 knapsack has the greedy-choice property.
False. No fixed "take the locally best item" rule is provably part of an optimal solution — that missing Greedy-Choice Property is precisely why greedy fails and Dynamic Programming is needed.
The DP runtime makes 0/1 knapsack a polynomial-time problem.
False. counts one cell per (item, capacity value), but needs only bits to write, so the table is exponential in the input size; this is pseudo-polynomial, consistent with the problem's NP-hardness.
Because fractional knapsack is easy, its integer version must also be easy.
False. Adding the constraint jumps the problem from polynomial to NP-hard — a tiny change in the model can change the whole complexity class.
Spot the error
"Greedy left 20 units empty, but density was maximized, so value was maximized too."
The error is equating average density with total value. Under an integer cap, empty room is uncaptured value; C at density 4 fills the gap and wins despite lower density.
"The exchange argument proves density-greedy optimal, and it doesn't care about fractions."
The error is ignoring what the swap requires. The Exchange Argument swaps an arbitrarily small sliver to keep weight fixed; whole-item swaps in 0/1 change total weight and may break capacity, so the proof is illegal.
"I'll fix greedy by, if the densest item doesn't fit, just taking the next densest — that recovers optimality."
The error is assuming a smarter skip-rule restores a proof. There is no simple sort/skip key that is optimal for all inputs; the fix is DP or a guaranteed approximation, not a patched heuristic.
"Take C (needs 30) in the remaining room of 20 — it mostly fits, so count it."
The error violates the 0/1 rule: an item is whole or absent. "Mostly fits" is fractional-knapsack thinking; C simply cannot be placed in 20 units.
"Density-greedy is at least always close to optimal, so it's a safe approximation."
The error is assuming bounded error. Pure density-greedy can be arbitrarily bad; only gives a proven ½-guarantee.
"K(i,c) commits to taking item i whenever it fits, since that grabs value."
The error mis-states the recurrence. takes the max of skip () and take () — it tries both and never commits early; that is exactly why it beats greedy.
Why questions
Why divide value by weight (a ratio ) instead of subtracting or just reading value?
The bag charges you in room, and a ratio measures value earned per scarce unit of room spent — the true "exchange rate"; subtraction mixes worth and room as if they were the same currency, and raw value ignores room entirely.
Why can leftover capacity in 0/1 knapsack cost you value, but never in fractional?
In fractional you slice the next item to fill the bag exactly, so leftover is always zero; in 0/1 you cannot slice, so a gap smaller than every remaining item stays empty and represents lost value.
Why does the counter-example need the low-density item C to be takeable together with B?
The failure is greedy stealing capacity: A(10) consumes room that B(20)+C(30)=50 needed to co-exist, so greedy's early pick forecloses the globally optimal B+C pairing.
Why does the DP "remember the best value for each capacity" instead of a running choice?
Because the optimal use of leftover capacity depends on the exact amount left; storing for every ensures no future combination is prematurely ruled out.
Why is "sort by value" tempting yet wrong when value is the very thing we maximize?
Value ignores the cost side (weight); a heavy high-value item can occupy capacity that two lighter items would have filled for more total value.
Why does adding integrality () break greedy but not Dynamic Programming?
Greedy relies on a proof (exchange) that needs slivers; DP relies only on optimal substructure, which survives the whole-or-nothing constraint untouched.
Why is fast for small yet not a true polynomial algorithm?
It is polynomial in the numeric value , but the input only spends bits to store , so the work grows exponentially in that bit-length — the hallmark of a pseudo-polynomial algorithm.
Edge cases
If every item is heavier than the capacity , what does greedy and the optimum return?
Both return value 0 — nothing fits, so and greedy skips all items; this degenerate case is where the two trivially agree.
What if an item has weight but value ?
Its density divides by zero — it "should" be taken always since it costs no room, but the ratio blows up and breaks the sort; either add the input constraint , or special-case zero-weight items by taking every one of them for free before running the heuristic.
If all items have equal value-density, does greedy become optimal?
Not guaranteed — equal density means the answer reduces to fitting maximum weight, and greedy's fit order can still leave a gap that a different equal-density subset would fill more fully.
When several items share the same density, can the tie-break order change greedy's total?
Yes — density alone doesn't fix an order among equals, and taking a heavier equal-density item first can consume room two lighter equals needed, so different tie-break rules (e.g. lighter-first vs. heavier-first) can produce different greedy totals on the same input.
If , what is the answer and does the recurrence handle it?
The answer is 0; the base/guard triggers for every positive-weight item at , so for all — no special case needed (zero-weight items are the lone exception, still worth taking).
If there is exactly one item, are greedy and optimum identical?
Yes — with one item the only decision is take-if-it-fits, so both give (when ) or 0; a single item cannot create the capacity-blocking conflict that trips greedy.
If two items have identical weight but different value, can greedy still err?
Not from this pair alone (it prefers the higher value at equal weight), but the pair can still combine with a third item so that greedy's earlier pick blocks a better overall subset.
Can greedy ever accidentally return the optimal answer on a "bad" instance?
Yes — greedy is not always wrong, only not provably right; on many instances it coincides with the optimum, which is exactly why testing one lucky case never validates it.
Recall One-line survival summary
Greedy fails whenever a locally best item steals capacity a better whole-item combination needed; the cure is Dynamic Programming (try take and skip via ), and no simple sort key ever replaces it.