Skip to content
Home DSA Fractional Knapsack — When Greedy Fails on 0/1 Constraints

Fractional Knapsack — When Greedy Fails on 0/1 Constraints

Where developers are forged. · Structured learning · Free forever.
📍 Part of: Greedy & Backtracking → Topic 9 of 13
Avoid the mistake: a greedy fractional knapsack algorithm increased throughput only 2% vs 15% because tasks were indivisible.
⚙️ Intermediate — basic DSA knowledge assumed
In this tutorial, you'll learn
Avoid the mistake: a greedy fractional knapsack algorithm increased throughput only 2% vs 15% because tasks were indivisible.
  • Sort by value/weight density descending. Take full items while they fit, take a fraction of the next item to fill remaining capacity. O(n log n) dominated by sort.
  • The exchange argument is the key: any solution not taking the highest-density item first can be improved by swapping — this is the formal proof, not just intuition.
  • Fractional knapsack: greedy optimal. 0/1 knapsack: DP required. Knowing which you are facing is the first question to ask in any packing/allocation problem.
✦ Plain-English analogy ✦ Real code with output ✦ Interview questions
Quick Answer
  • Fractional knapsack lets you take partial items — greedy by value/weight density is optimal.
  • Sort items by value/weight ratio descending; take full items until the bag fills, then take a fraction of the next item.
  • Exchange argument proves optimality: any optimal solution can be tweaked to include the highest-density item without losing value.
  • Sorting dominates runtime at O(n log n); selection is O(n).
  • Real-world: resource allocation like bandwidth or CPU time where fractional units are meaningful.
🚨 START HERE

Greedy Knapsack Quick Debug

Use these three commands to verify your greedy solution is correct
🟡

Suspiciously low total value

Immediate ActionList the item densities and the fraction taken.
Commands
print([(value/weight, taken_fraction) for item in items])
Check that the sum of taken weights equals original capacity.
Fix NowIf any high-density item has zero taken fraction, re-sort by density and reprocess.
🟡

Algorithm fills capacity but value is worse than brute force

Immediate ActionCompare with a simple brute force for small n (n <= 15).
Commands
Run brute-force 0/1 knapsack on the same data — if it gives higher value, you have a fractional-vs-0/1 mismatch.
Check item divisibility constraints in the problem statement.
Fix NowIf items are indivisible, switch to DP. If divisible, check density calculation.
Production Incident

Greedy on a 0/1 Problem Cost the Team a Month of Optimisation

A platform team assumed their resource allocation problem was fractional, used greedy, and delivered suboptimal results — because items were actually indivisible.
SymptomAfter deploying a new scheduling algorithm, total throughput increased only 2% instead of the expected 15%. The team had switched from a DP-based solution to a greedy one to reduce latency.
AssumptionThe team assumed that since CPU time could be split, any resource allocation was fractional — they treated each task as infinitely divisible.
Root causeThe tasks were actually 0/1: each task required a fixed block of CPU (a whole container). Taking a fraction of a task wasn't possible. The greedy algorithm by density picked tasks that didn't fit together optimally.
FixReverted to a DP-based 0/1 knapsack algorithm. Added a check in the design phase: is the resource granular discrete or continuous?
Key Lesson
Always confirm whether items are divisible or indivisible before choosing the algorithm.Greedy for fractional knapsack is optimal, but applying it to a 0/1 problem gives no guarantee — test the constraint, not just the intuition.
Production Debug Guide

Symptom → Action guide for when your resource allocation looks wrong

Total value is lower than expected, but the solution seems to follow the greedy rule.Verify the items are actually fractional. If any item cannot be split (e.g., a container, a job), you need 0/1 knapsack — reframe the problem.
Sort order appears correct but results are off by a small amount.Check floating point precision in value/weight ratios. Use decimal or fractions to avoid truncation errors.
The algorithm takes a fraction of an item when the remaining capacity is exactly equal to a full item.Double-check the comparison: if weight <= remaining, take the full item, not a fraction. Off-by-one logic here leads to unintended fractional splits.

Fractional knapsack is where most engineers first encounter the concept of greedy correctness — the proof that taking the highest value-density item first is provably optimal, not just intuitively reasonable. The exchange argument used here is a template that appears throughout algorithm design: assume the greedy choice is not in an optimal solution, then show you can swap it in without making things worse.

In practice, fractional knapsack models continuous resource allocation: bandwidth allocation across network flows, portfolio optimisation with divisible assets, CPU time sharing. The 0/1 version (items must be whole) requires dynamic programming and is a completely different beast — knowing which version you're facing is the first question to ask.

The Greedy Strategy

Sort all items by value/weight ratio in descending order. Take items greedily — full items when they fit, a fraction of the next item when the bag is almost full.

fractional_knapsack.py · PYTHON
123456789101112131415161718192021
def fractional_knapsack(capacity: float, weights: list, values: list) -> float:
    n = len(weights)
    # Create (value_density, weight, value) tuples
    items = sorted(zip(values, weights), key=lambda x: x[0]/x[1], reverse=True)
    total_value = 0.0
    remaining = capacity
    for value, weight in items:
        if remaining <= 0:
            break
        if weight <= remaining:
            total_value += value
            remaining -= weight
        else:
            # Take fraction
            total_value += value * (remaining / weight)
            remaining = 0
    return total_value

weights = [10, 20, 30]
values  = [60, 100, 120]
print(fractional_knapsack(50, weights, values))  # 240.0
▶ Output
240.0
📊 Production Insight
Sorting by density with floating point can give precision errors in edge cases.
Use the cross-multiplication comparison: val1 wt2 > val2 wt1 instead of val1/wt1 > val2/wt2.
This avoids DivideByZero and floating-point drift, especially with integer weights and values.
🎯 Key Takeaway
Sort by value/weight density descending.
Take full items while they fit, then a fraction of the next item.
O(n log n) dominated by sort — but prefer cross-multiplication for stable sorting.

Why Greedy Works Here But Not for 0/1 Knapsack

The greedy approach works for fractional knapsack because of the greedy choice property: taking the highest value-density item first is always locally and globally optimal — you can always 'undo' a partial choice by trading a fraction.

For 0/1 knapsack, taking the highest density item might leave a gap that no remaining item can fill optimally. Example: - Capacity = 10 - Item A: weight=6, value=10 (density 1.67) - Item B: weight=5, value=8 (density 1.60) - Item C: weight=5, value=8 (density 1.60)

Greedy picks A (density 1.67) then can only fit one of B/C — total = 10+8 = 18. Optimal picks B+C — total = 8+8 = 16. Wait — greedy wins here. But with capacity=10, items [{w=6,v=6},{w=5,v=5},{w=5,v=5}]: greedy picks first (density 1), then one of the others = 11. Optimal: pick both w=5 items = 10. Greedy wins again for fractional.

The key: with fractional items, the exchange argument holds perfectly — you can always swap parts of lower-density items for parts of higher-density ones to improve value.

🔥Proof of Optimality
Suppose an optimal solution doesn't take the highest-density item first. Swap some fraction of a lower-density item for an equal weight of the highest-density item — value increases. Contradiction. Therefore greedy is optimal.
📊 Production Insight
The most common mistake in production is using greedy on a 0/1 problem.
This slips in when engineers think 'continuous resource' but the resource is actually allocated in discrete chunks.
Always validate the divisibility assumption with the domain owner — it's a 5-minute question that prevents a 2-week rewrite.
🎯 Key Takeaway
Greedy works for fractional because any solution missing high-density items can be improved by swapping.
For 0/1 problems, greedy gives no guarantee — learn to spot the difference, it's often the only question that matters.
Which algorithm to use?
IfItems are divisible (you can take any fraction)
UseUse greedy by density — optimal and O(n log n).
IfItems are indivisible (0/1 knapsack)
UseUse dynamic programming — greedy fails.
IfItems have both weight and value, capacity small (W <= 1000)
UseDP O(nW) is feasible even for 0/1.
IfVery large n and continuous resources
UseGreedy fractional is your only practical choice.

Proof of Optimality — Exchange Argument Formalised

The exchange argument is the formal proof that greedy is optimal. We'll walk through it step by step for fractional knapsack.

Let the items be sorted by value/weight ratio: v1/w1 >= v2/w2 >= ... >= vn/wn. Let G be the greedy solution. Let O be an optimal solution that differs from G at the first index i where they take different fractions.

Since G takes the maximum possible amount of item i, O takes less (or zero) of item i. O must compensate with some later item j (j > i) that has lower density. Replace a unit weight of item j with a unit weight of item i in O. The value of O increases (or stays same) because vi/wi >= vj/wj. If it stays same, density ties don't matter.

Thus we can transform O into G without decreasing value, proving G is optimal.

This argument is the foundation for greedy optimality proofs in many other problems: activity selection, Huffman coding, coin change (canonical systems).

📊 Production Insight
In interviews, the exchange argument is how you convince a senior engineer that your greedy solution is correct.
Don't just say 'sort by density' — walk through the swap and show why no better solution can exist.
The same argument structure works for scheduling, caching, and resource allocation problems.
🎯 Key Takeaway
Exchange argument: assume greedy is not in optimal, swap in the greedy choice, get equal or better value.
Master this pattern — it appears in half of all greedy problems asked in senior-level interviews.

Complexity and Space Considerations

Sorting: O(n log n) — dominated by sort. Selection pass: O(n) — one scan. Total time: O(n log n). Space: O(1) extra (if sorting in place), otherwise O(n) for a copy.

Compare with 0/1 knapsack dynamic programming: O(nW) time and O(W) space (with 1D array). For large W, fractional knapsack's O(n log n) is much faster.

Trick: If weights are small integers (W <= n log n), you can use counting sort for O(n + W) time, but in practice the built-in sort is fine.

📊 Production Insight
When capacity is huge (e.g., 10^9), DP is impossible — greedy becomes your only option.
Memory-wise, fractional knapsack uses no extra space beyond the input, which matters in embedded systems.
But if you need to process millions of items, the sorting step becomes the bottleneck — consider a streaming approach using selection algorithm (O(n) worst-case) if you only need the top items.
🎯 Key Takeaway
O(n log n) time, O(1) extra space — almost always fast enough.
The bottleneck is sorting. For streaming scenarios, use a partial sort or selection algorithm.

Real-World Applications and Variations

Fractional knapsack appears in many continuous resource allocation problems: - Bandwidth allocation: Splitting bandwidth among flows proportionally to their 'value' (e.g., priority * throughput). - CPU time scheduling: Weighted fair queuing (WFQ) uses a similar greedy approach — allocate CPU to the highest 'density' process first. - Portfolio optimisation: When assets are perfectly divisible (e.g., stocks in large markets), the greedy by expected return per unit risk gives the optimal mix. - Mixing raw materials: In manufacturing, you have limited capacity and want to maximise profit by blending ingredients of different value densities.

Variations: - Bounded fractional knapsack: Each item has a maximum fraction you can take (e.g., you cannot take more than 50% of a shared resource). Still solvable by greedy after adjusting densities? Not necessarily — requires a more complex approach. - Multiple knapsacks: Have several bags. Greedy still works? Not in general — becomes a variant of bin packing. - Knapsack with penalties: Taking a fraction incurs overhead (e.g., setup time per item). Breaks the greedy property.

📊 Production Insight
In a networking context, I've seen bandwidth allocation using greedy fractional knapsack work well until QoS constraints made some flows indivisible — then we had to switch to a 0/1 model.
Always model the real constraint. If there's a minimum allocation unit (e.g., a container size), that's a 0/1 problem, not fractional.
The greedy assumption is fragile; validate it with the team that defines the resource.
🎯 Key Takeaway
Fractional knapsack models divisible resource allocation.
But beware of hidden indivisibility (discrete units, minimum chunks) — they transform the problem into 0/1, where greedy fails.
Know the boundary: continuous vs discrete is the first question.

Common Mistakes and Edge Cases

Even for a simple greedy algorithm, several mistakes slip into code:

  1. Sorting by value only: Forgetting to divide by weight. Takes expensive heavy items first, not the best value per unit weight.
  2. Integer division: In languages like C++ or Java, dividing two integers gives an integer, messing up density order. Use double or compare cross-multiplication.
  3. Floating point equality: When two densities are equal, stable sort matters for reproducibility but not optimality.
  4. Off-by-one in capacity check: Taking a fraction when the item fits exactly but you compare weight < remaining instead of <=.
  5. Not handling zero-weight items: Division by zero if weight = 0. Check if weight > 0 before dividing.
  6. Assuming capacity is integer: If capacity is integer but weights are floats, capacity comparison can drift.
📊 Production Insight
I once debugged a production issue where the algorithm was producing suboptimal allocations — turned out the team was sorting by (value/weight) using integer division in C++. The density for (value=3, weight=2) and (value=2, weight=2) both became 1, losing the ordering. Switch to cross-multiplication fixed it instantly.
🎯 Key Takeaway
Use cross-multiplication to compare densities: a/b > c/d iff ad > cb.
Always check for zero weights and floating-point precision.
Small coding errors in sorting logic cost real throughput — test with edge cases.

Comparison with 0/1 Knapsack

Understanding when to use each is critical. Here's a direct comparison:

  • Fractional Knapsack: Items divisible, greedy gives optimal solution, O(n log n).
  • 0/1 Knapsack: Items indivisible, DP required, O(nW) time.
  • Unbounded Knapsack: Items can be taken multiple times, DP also used but with different recurrence.

The fundamental difference is the fraction. In fractional, the exchange argument works because you can always swap a small piece of a low-density item for an equal piece of a high-density one. In 0/1, you can't swap a piece — you must swap whole items, which may not fit in the remaining space.

📊 Production Insight
Engineers often overgeneralise from fractional to 0/1 because they remember 'knapsack is solved with greedy'. That confusion leads to suboptimal decisions in production.
I've seen a pricing engine that treated each sale as fractional (you can sell partial units) when the actual product was discrete — caused revenue loss until fixed.
When in doubt, state the divisibility explicitly in your code comments or design docs.
🎯 Key Takeaway
Fractional: greedy, O(n log n). 0/1: DP, O(nW).
The dividing line is divisibility of items — not complexity or instinct.
State the assumption in code: # items are divisible, so greedy is safe.

🎯 Key Takeaways

  • Sort by value/weight density descending. Take full items while they fit, take a fraction of the next item to fill remaining capacity. O(n log n) dominated by sort.
  • The exchange argument is the key: any solution not taking the highest-density item first can be improved by swapping — this is the formal proof, not just intuition.
  • Fractional knapsack: greedy optimal. 0/1 knapsack: DP required. Knowing which you are facing is the first question to ask in any packing/allocation problem.
  • Real-world: continuous resource allocation — bandwidth, CPU cycles, capital allocation where fractional units are meaningful.
  • Follow-up interview question: if weights and values are integers, does fractional knapsack still give a fractional answer? (Yes, if no item fits perfectly in remaining space.)

⚠ Common Mistakes to Avoid

    Sorting by value only, not value/weight ratio
    Symptom

    The greedy picks heavy, high-value items first and fills capacity poorly, giving lower total value than possible.

    Fix

    Always divide value by weight (or use cross-multiplication) to determine the order.

    Integer division when computing density
    Symptom

    Multiple different ratios evaluate to the same integer, losing ordering precision.

    Fix

    Use double/float for the division or compare using val1 weight2 > val2 weight1.

    Using <= instead of < for remaining capacity check (or vice versa)
    Symptom

    When an item exactly fits the remaining capacity, the algorithm either takes a fraction of it or skips it, wasting capacity or creating an unnecessary fraction.

    Fix

    Use if weight <= remaining: take entire item, else take fraction.

    Not handling zero-weight items
    Symptom

    Division by zero when computing density (value/0).

    Fix

    Filter out zero-weight items before sorting, or handle them as special case (they contribute value without consuming capacity — take them all).

    Assuming the problem is fractional when items are actually indivisible
    Symptom

    Greedy gives suboptimal result compared to brute force / DP.

    Fix

    Review the problem constraints: if items must be taken whole, use 0/1 knapsack DP.

Interview Questions on This Topic

  • QWhy does greedy work for fractional knapsack but not 0/1 knapsack?SeniorReveal
    Greedy works for fractional knapsack because items are divisible, so taking the highest density item first is always optimal — you can swap any partial lower-density item for the same weight of higher-density to increase value. In 0/1 knapsack, the integer constraint means swapping whole items may leave wasted space, so greedy can't guarantee optimality. Professional answer example: 'The exchange argument applies because we can adjust fractional amounts continuously. For 0/1, the integrality gap means greedy can be arbitrarily worse — a famous counterexample shows the ratio can be unbounded.'
  • QWhat is the time and space complexity of fractional knapsack?Mid-levelReveal
    Time: O(n log n) due to sorting. The selection pass is O(n). Space: O(1) extra if sorting in-place, O(n) if a copy of the items is needed. Could you reduce sorting time? If we use a selection algorithm to find the item that fills the bag exactly, we can achieve O(n) average, but that's overkill — sorting is usually fine.
  • QProve that sorting by value/weight ratio gives the optimal solution.SeniorReveal
    Use the exchange argument: Let items be sorted by descending ratio. Let G be greedy solution, O be an optimal solution. Find the first index i where G takes more than O. O must compensate with some lower-density item j (j > i). Replace a unit weight of j with the same weight of i in O. Since ratio[i] >= ratio[j], the total value does not decrease. Repeat until G and O match. Thus G is optimal. For a rigorous proof, you need to show that after a finite number of swaps, G and O become identical.
  • QCan the fractional knapsack greedy algorithm be implemented without sorting?SeniorReveal
    Yes, using a median-of-medians selection algorithm to find the 'pivot' — the item that fills the remaining capacity. This yields O(n) worst-case time. However, it's more complex and rarely needed. Sorting is simpler and O(n log n) is usually fine.
  • QHow would you handle a fractional knapsack where each item has a bound on how much you can take?SeniorReveal
    That's the bounded fractional knapsack. Greedy no longer works in general because after taking the optimal fraction, the next item's bound might restrict swapping. We need a DP variant or a more sophisticated approach. However, if bounds are all >= capacity, it's the same as unbounded fractional.

Frequently Asked Questions

What if two items have the same value density?

Tie-breaking order doesn't matter — any ordering of equal-density items gives the same total value. However, for deterministic output, sort by a secondary key (e.g., higher weight first or use stable sort).

Can fractional knapsack be solved without sorting?

Yes, using a selection algorithm (like quickselect with median-of-medians) to find the 'breakpoint' item. That yields O(n) worst-case but is more complex. Sorting is simpler and typically fast enough.

Does fractional knapsack have any real-world use outside of educational contexts?

Absolutely. It models any continuous resource allocation: bandwidth throttling, CPU scheduling (WFQ), blending raw materials, investment with divisible assets. Any scenario where you can take a percentage of an item is fractional.

What if the capacity is extremely large (e.g., 10^12)?

Fractional knapsack still works in O(n log n) because capacity doesn't affect time complexity. DP for 0/1 would be impossible. Big capacity is a green flag for fractional greedy.

How do I test whether my greedy solution is correct?

Write a brute-force solution for small n (n ≤ 12) and compare. Also test edge cases: all same density, one huge item, negative weights (though not typical), zero values, and items that exactly fill capacity.

🔥
Naren Founder & Author

Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.

← PreviousPermutations using BacktrackingNext →Job Sequencing Problem with Deadlines
Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged