Solving Coin Change Problem with Dynamic Programming

Introduction and Core Concepts

The coin change problem is one of the most fundamental and frequently studied problems in dynamic programming, and a cornerstone for understanding optimization and combinatorial algorithms. At its core, the problem asks: given a set of coin denominations and a target amount, how can we make change for that amount using the fewest coins possible, or how many distinct ways exist to make that exact amount? While the premise sounds like a simple cashier's dilemma, its underlying structure reveals deep principles of recursion, overlapping subproblems, and optimal substructure that appear throughout computer science.

There are two primary variants of the coin change problem that every developer should understand. The first is the optimization variant, often called the minimum coins problem, where the goal is to find the smallest number of coins needed to reach the target amount. If it is impossible to form the amount with the given denominations, the algorithm should indicate failure, typically by returning -1 or infinity. The second is the counting variant, where the goal is to determine the total number of distinct combinations to make the target amount. This variant does not care about minimizing coins but about enumerating possibilities. Both variants share the same input structure but require subtly different recurrence relations.

Why does the coin change problem matter beyond interviews and textbooks? It is a canonical example of an unbounded knapsack problem, where each coin denomination can be used an unlimited number of times. Mastering it provides intuition for a whole family of resource allocation, scheduling, and partitioning problems. The techniques used to solve coin change — memoization, tabulation, and state transition — directly transfer to solving problems like rod cutting, word break, climbing stairs, and even more complex systems like inventory management and financial portfolio optimization. Understanding this single problem unlocks a pattern for solving hundreds of others.

From a theoretical perspective, the coin change problem is also an excellent illustration of why greedy algorithms fail. For canonical coin systems like US coins [1, 5, 10, 25], a greedy strategy of always picking the largest coin works for the minimum coins variant. However, for arbitrary denominations such as [1, 3, 4] and target amount 6, the greedy choice of 4 + 1 + 1 (3 coins) is suboptimal compared to 3 + 3 (2 coins). Dynamic programming guarantees an optimal solution regardless of the coin system, making it the robust and correct approach for the general case.

How It Works

Dynamic programming solves the coin change problem by breaking it down into smaller, overlapping subproblems and building up solutions from the bottom up or caching them from the top down. The key insight is optimal substructure: the optimal solution for amount amount can be constructed from optimal solutions for smaller amounts. If we know the minimum coins needed for amount - coin for every coin denomination, then the answer for amount is simply one more than the minimum of those values.

To formalize this, we define a DP state. For the minimum coins problem, let dp[i] represent the minimum number of coins required to make amount i. The base case is dp[0] = 0, because zero coins are needed to make amount zero. For any other amount i > 0, the recurrence relation is: dp[i] = min(dp[i - coin] + 1) for all coins where coin <= i and dp[i - coin] is reachable. If no such coin leads to a reachable state, dp[i] remains infinity, indicating the amount cannot be formed. This recurrence is applied iteratively for all amounts from 1 to the target.

For the counting variant, the state definition changes slightly. Let dp[i] represent the number of ways to make amount i. The base case is dp[0] = 1, representing one way to make zero amount by using no coins. The recurrence is dp[i] += dp[i - coin] for each coin. Critically, the order of iteration determines whether we count combinations or permutations. To count combinations where order does not matter (e.g., 1+2 and 2+1 are the same), we iterate over coins in the outer loop and amounts in the inner loop. To count permutations where order matters, we reverse the loops.

Overlapping Subproblems and Memoization

The naive recursive solution recomputes the same subproblems exponentially many times. For example, to compute minCoins(7) with coins [1,3,4], the recursion will compute minCoins(3) multiple times through different paths. Dynamic programming eliminates this redundancy. In the top-down memoization approach, we store the result of each subproblem in a hash map or array after computing it once. Subsequent calls simply look up the cached value. In the bottom-up tabulation approach, we systematically fill a table from smallest to largest amount, ensuring that when we compute dp[i], all required smaller states dp[i - coin] are already known.

Unbounded Knapsack Connection

The coin change problem is an unbounded knapsack problem where the knapsack capacity is the target amount, the weight of each item is the coin value, and the value is either 1 per coin (for minimizing count) or 1 per combination (for counting). Unlike the 0/1 knapsack where each item can be used at most once, here we have infinite supply of each denomination. This is why our transition allows reusing the same coin multiple times by referencing dp[i - coin] within the same iteration, rather than using a previous row as in 0/1 knapsack.

Implementation

Implementing the coin change problem in Python can be done using several approaches, each illustrating a different dynamic programming paradigm. Below are four complete implementations with detailed comments, starting from exponential recursion and progressing to optimized dynamic programming solutions.

1. Naive Recursive Solution (Exponential Time)

This baseline implementation explores all possibilities without any caching. It serves to illustrate the recurrence but is impractical for large amounts due to its exponential time complexity. It tries every coin at each step and takes the minimum.

def min_coins_recursive(coins, amount):
    # Base case: 0 amount needs 0 coins
    if amount == 0:
        return 0
    # Base case: negative amount is invalid
    if amount < 0:
        return float('inf')
    
    min_coins = float('inf')
    # Try every coin as the last coin used
    for coin in coins:
        # Recursively solve for remaining amount
        res = min_coins_recursive(coins, amount - coin)
        # If subproblem is solvable, update minimum
        if res != float('inf'):
            min_coins = min(min_coins, res + 1)
    
    return min_coins

# Returns inf if not possible, caller can convert to -1
# coins = [1, 3, 4], amount = 6 -> returns 2 (3+3)

2. Top-Down Dynamic Programming with Memoization

Memoization dramatically improves the recursive solution by caching results. The time complexity becomes polynomial because each amount from 0 to target is computed at most once. This approach is intuitive because it preserves the natural recursive structure while adding efficiency.

def coin_change_memo(coins, amount, memo=None):
    if memo is None:
        memo = {}
    # Base cases
    if amount == 0:
        return 0
    if amount < 0:
        return float('inf')
    # Return cached result if already computed
    if amount in memo:
        return memo[amount]
    
    min_coins = float('inf')
    for coin in coins:
        res = coin_change_memo(coins, amount - coin, memo)
        if res != float('inf'):
            min_coins = min(min_coins, res + 1)
    
    # Cache and return
    memo[amount] = min_coins
    return memo[amount]

def coin_change_top_down(coins, amount):
    result = coin_change_memo(coins, amount)
    return result if result != float('inf') else -1

3. Bottom-Up Tabulation for Minimum Coins

Tabulation is the most common and often most efficient implementation. It iteratively builds a DP array from 0 to amount, eliminating recursion overhead and the risk of stack overflow. This is the preferred solution for most interviews and production code.

def coin_change_dp(coins, amount):
    # dp[i] = minimum coins needed to make amount i
    dp = [float('inf')] * (amount + 1)
    dp[0] = 0  # 0 coins to make amount 0
    
    # Build table bottom-up
    for i in range(1, amount + 1):
        for coin in coins:
            # Check if coin can be used and subproblem is solvable
            if coin <= i and dp[i - coin] != float('inf'):
                dp[i] = min(dp[i], dp[i - coin] + 1)
    
    return dp[amount] if dp[amount] != float('inf') else -1

# Example usage:
# print(coin_change_dp([1, 2, 5], 11))  # Output: 3 (5+5+1)
# print(coin_change_dp([2], 3))         # Output: -1 (impossible)

4. Bottom-Up Counting of Combinations

This variant counts the number of distinct combinations to make the target amount. The crucial detail is the loop order: iterating over coins first ensures we do not double-count permutations. This implementation uses a 1D DP array for optimal space.

def count_change_ways(coins, amount):
    # dp[i] = number of ways to make amount i
    dp = [0] * (amount + 1)
    dp[0] = 1  # One way to make 0: use no coins
    
    # Iterate over coins first to count combinations (not permutations)
    for coin in coins:
        for i in range(coin, amount + 1):
            dp[i] += dp[i - coin]
    
    return dp[amount]

# Example: coins = [1, 2, 5], amount = 5 -> returns 4
# Ways: [5], [2,2,1], [2,1,1,1], [1,1,1,1,1]
# If loops were reversed, it would count permutations and return 9

5. Reconstructing the Solution

Often we need not just the minimum number of coins but the actual coins used. This requires storing a parent pointer array alongside the DP table to backtrack from the target amount to zero.

def coin_change_with_coins(coins, amount):
    dp = [float('inf')] * (amount + 1)
    coin_used = [-1] * (amount + 1)
    dp[0] = 0
    
    for i in range(1, amount + 1):
        for coin in coins:
            if coin <= i and dp[i - coin] + 1 < dp[i]:
                dp[i] = dp[i - coin] + 1
                coin_used[i] = coin
    
    if dp[amount] == float('inf'):
        return -1, []
    
    # Reconstruct coins used by backtracking
    result = []
    curr = amount
    while curr > 0:
        coin = coin_used[curr]
        result.append(coin)
        curr -= coin
    
    return dp[amount], result

# Example: coin_change_with_coins([1,3,4], 6) -> (2, [3, 3])

Step-by-Step Example

Let us walk through the bottom-up DP for the minimum coins problem in detail to solidify the mechanics. Consider coins = [1, 3, 4] and amount = 6. We want to find the minimum number of coins to make 6. We will create a DP array dp of size 7 (0 to 6), initialized to infinity except dp[0] = 0.

We iterate i from 1 to 6. For each i, we test every coin. For i = 1: coin 1 is <= 1 and dp[0] = 0, so dp[1] = dp[0] + 1 = 1. Coins 3 and 4 are too large. Result: dp[1] = 1 (1). For i = 2: coin 1 gives dp[1] + 1 = 2, so dp[2] = 2. 3 and 4 are too large. Result: dp[2] = 2 (1+1). For i = 3: coin 1 gives dp[2] + 1 = 3, coin 3 gives dp[0] + 1 = 1, which is better, so dp[3] = 1 (3). Coin 4 is too large. For i = 4: coin 1 gives dp[3] + 1 = 2, coin 3 gives dp[1] + 1 = 2, coin 4 gives dp[0] + 1 = 1, so dp[4] = 1 (4).

Continuing, for i = 5: coin 1 gives dp[4] + 1 = 2 (4+1), coin 3 gives dp[2] + 1 = 3 (1+1+3), coin 4 gives dp[1] + 1 = 2 (1+4). So dp[5] = 2. For i = 6: coin 1 gives dp[5] + 1 = 3, coin 3 gives dp[3] + 1 = 2 (3+3), coin 4 gives dp[2] + 1 = 3 (1+1+4). The minimum is 2, so dp[6] = 2. The optimal solution is 3+3. This trace shows how each entry depends only on previously computed smaller entries.

Visualizing the DP Table

The evolution of the DP table for this example can be summarized as follows. Initially: [0, inf, inf, inf, inf, inf, inf]. After i=1: [0, 1, inf, inf, inf, inf, inf]. After i=2: [0, 1, 2, inf, inf, inf, inf]. After i=3: [0, 1, 2, 1, inf, inf, inf]. After i=4: [0, 1, 2, 1, 1, inf, inf]. After i=5: [0, 1, 2, 1, 1, 2, inf]. After i=6: [0, 1, 2, 1, 1, 2, 2]. Notice how dp[6] reuses dp[3], demonstrating overlapping subproblems. If we were also tracking parent pointers, we would store for each i which coin gave the optimal value, allowing us to reconstruct the path.

Now contrast this with the counting variant for the same coins and amount. We initialize dp = [1, 0, 0, 0, 0, 0, 0]. Outer loop coin=1: we update dp[1]=1, dp[2]=1, dp[3]=1, dp[4]=1, dp[5]=1, dp[6]=1. Outer loop coin=3: we update dp[3]+=dp[0]=2, dp[4]+=dp[1]=2, dp[5]+=dp[2]=2, dp[6]+=dp[3]=3. Outer loop coin=4: we update dp[4]+=dp[0]=3, dp[5]+=dp[1]=3, dp[6]+=dp[2]=4. Final dp[6]=4 ways: [1,1,1,1,1,1], [1,1,4], [1,3,1,1] actually counted as [1,1,1,3] combination, and [3,3]. The coin-first order ensures each combination is counted once.

Complexity Analysis

Understanding the time and space complexity of different approaches to the coin change problem is critical for choosing the right implementation for a given constraint. The complexity depends on the number of coin denominations, denoted as n, and the target amount, denoted as amount or W.

The naive recursive solution without memoization has exponential time complexity, approximately O(n^amount) in the worst case, because each call branches into n recursive calls and the recursion depth can be up to amount/min(coins). Its space complexity is O(amount) due to the recursion stack, but it is otherwise unusable for amounts larger than 30-40. Memoization reduces this to O(n * amount) time because each amount is computed once and each computation iterates over n coins. The space becomes O(amount) for the memo table plus O(amount) for the recursion stack.

The bottom-up tabulation approach also runs in O(n * amount) time and O(amount) space for the 1D DP array. This is the standard optimal complexity for both the minimum coins and counting variants. Some optimizations can reduce space further or improve constants, but the asymptotic complexity remains the same. For the counting variant with a 2D table, space would be O(n * amount), but the optimized 1D version brings it down to O(amount). BFS-based approaches, which treat each amount as a node and each coin as an edge, also run in O(n * amount) time but may have higher constant factors and queue overhead.

It is important to note that coin change is pseudo-polynomial. The complexity depends on the numeric value of amount, not the size of its binary representation. If amount is very large (e.g., 10^9), even O(n * amount) is infeasible. In such cases, alternative mathematical approaches or approximations may be needed, but for typical interview constraints where amount is up to 10^4 or 10^5, the DP solution is perfectly efficient.

For the minimum coins problem, the best, average, and worst cases are identical in terms of Big O because the loops always iterate over all coins for all amounts regardless of input distribution. The only variation is early termination if a solution is found quickly in BFS, but asymptotically it remains the same. Space is linear in amount, which is typically the dominant constraint for large targets.

Variations and Optimizations

The classic coin change problem has several important variations that appear in interviews and real systems. Understanding these variants demonstrates deeper mastery of dynamic programming and its adaptability.

One common variation is the bounded or limited supply coin change, where each coin denomination has a limited count. For example, you may have only two 5-value coins and three 1-value coins. This changes the problem from unbounded to bounded knapsack. The DP state must then include the count of coins used, often requiring a 2D table dp[i][j] where i is amount and j is coin index, or an optimization using binary splitting to convert bounded counts into multiple 0/1 items. Another variation is to find not just the minimum number of coins but all possible combinations, or to determine if change can be made at all (a decision problem).

Another frequently asked variation is counting permutations vs combinations. As noted earlier, swapping loop order changes the semantics. Counting permutations where order matters (e.g., [1,2] and [2,1] are distinct) requires iterating over amounts in the outer loop and coins in the inner loop. This subtle difference is a common interview trap. Additionally, some problems ask for the minimum coins with an additional constraint, such as minimizing total weight or maximizing value under a coin limit.

Space and Time Optimizations

The standard 1D DP array is already space-optimized, but further micro-optimizations exist. Sorting coins and breaking early when coin > i can reduce constant factors. For very large amounts, we can use techniques like divide and conquer with matrix exponentiation for certain coin systems, or use the concept of coin system canonicalization. Another optimization is to use BFS for the minimum coins problem: treat each amount as a node, and BFS from 0 will find the shortest path to the target, which corresponds to the minimum number of coins. BFS can be faster in practice if the target is small and a solution is found early, as it does not need to compute all amounts up to the target.

For the counting problem, if the number of ways is huge, we often return the result modulo 10^9+7 to prevent integer overflow. We can also use generating functions: the number of ways is the coefficient of x^amount in the product of (1 + x^coin + x^(2*coin) + ... ) for each coin, which connects coin change to polynomial multiplication and FFT-based optimizations for very large inputs.

Real-World Applications

While the coin change problem is often introduced as a toy cashier problem, its underlying model of making optimal use of discrete resources with unlimited supply appears pervasively in real-world systems, far beyond vending machines.

In web servers and cloud infrastructure, resource allocation mirrors coin change. Suppose a load balancer needs to allocate exactly 11 CPU cores using virtual machine instances of sizes 1, 2, and 5 cores, while minimizing the number of instances to reduce overhead. This is precisely the minimum coins problem. Similarly, content delivery networks need to partition data blocks into packets of fixed sizes to exactly fill a transmission window while minimizing packet count or counting valid partitionings for redundancy.

In databases and storage systems, page allocation and extent sizing use coin change logic. A database that allocates storage in extents of 8KB, 32KB, and 128KB must allocate exactly a requested size with minimal fragmentation. The DP table can determine the optimal extent combination. In log-structured merge trees, compaction strategies that merge sorted runs of certain sizes can be modeled as coin change to minimize write amplification.

In networking, packet fragmentation and reassembly, as well as change-making for bandwidth allocation, rely on similar principles. A router that must fragment a 1500-byte packet into cells of 48, 53, or 64 bytes with minimal overhead solves a coin change variant. In financial systems, portfolio optimization where you must reach a target investment amount using standard lot sizes, or ATM cash dispensing with limited bill denominations, are direct applications. Even in cryptography and blockchain, UTXO (unspent transaction output) selection for Bitcoin transactions — choosing inputs to exactly fund a payment while minimizing fees — is a bounded coin change problem.

Beyond these, the counting variant is valuable for capacity planning and reliability analysis. Knowing how many ways a system can achieve a target configuration helps estimate redundancy and failure modes. For example, counting the number of ways to achieve a replication factor using different node sizes informs fault tolerance calculations.

Comparison with Alternatives

Dynamic programming is not the only way to approach the coin change problem. Greedy algorithms, brute force recursion, and graph search methods each have their place, but they differ dramatically in correctness, efficiency, and applicability to arbitrary coin systems.

The greedy algorithm, which repeatedly takes the largest coin that does not exceed the remaining amount, is extremely fast with O(n log n) for sorting plus O(amount/minCoin) for selection, and uses O(1) extra space. However, it only guarantees optimality for canonical coin systems like US currency or Euro coins. For arbitrary denominations, it can fail to find any solution even when one exists, or return a suboptimal solution. Therefore, it is unsuitable as a general-purpose solution, though it is useful as a heuristic or when the coin system is known to be canonical.

Brute force recursion correctly explores all possibilities and guarantees optimality, but its exponential time makes it infeasible for all but the smallest amounts. It serves primarily as a conceptual baseline and as the starting point for memoization. Breadth-first search (BFS) models the problem as a shortest path problem on an unweighted graph where nodes are amounts and edges add a coin. BFS guarantees the minimum number of coins and can be faster than DP if the solution is shallow, but it requires a queue and visited set, and still has O(n * amount) complexity in the worst case.

Dynamic programming, particularly bottom-up tabulation, is the gold standard for the general coin change problem. It guarantees optimality for any coin system, runs in pseudo-polynomial time, and uses linear space. It handles both optimization and counting variants with minor modifications. Its only drawback is that it requires O(amount) memory, which can be large if amount is huge, and it always computes the full table up to amount even if a solution could be found earlier.

In practice, the choice depends on constraints. For interviews, DP is almost always the expected answer. For production systems with known canonical denominations and a need for ultra-low latency, greedy may be preferred. For very large amounts where DP table size is prohibitive, mathematical optimizations or meet-in-the-middle techniques might be considered.

Common Mistakes and Best Practices

Even experienced developers make subtle errors when implementing coin change solutions. Recognizing these pitfalls is crucial for writing correct, efficient, and maintainable code.

One of the most frequent mistakes is incorrect initialization of the DP array. For the minimum coins problem, initializing with 0 instead of infinity (or a large sentinel value) leads to incorrect minima, as min(0, something) will always be 0. Conversely, for the counting problem, initializing dp[0] to 0 instead of 1 results in all counts being zero, because there is no base way to build upon. Another common error is using the wrong loop order for the counting variant, accidentally counting permutations when combinations are required or vice versa. This is a classic interview trap that changes the answer completely.

Another pitfall is integer overflow and failure to handle impossible amounts. Using a sentinel like float('inf') in Python is safe, but in languages like Java or C++ using Integer.MAX_VALUE can overflow when adding 1. The check dp[i - coin] != INF before adding 1 is essential. Also, forgetting to return -1 or another indicator for impossible amounts, instead returning infinity or a large number, violates the problem specification. Edge cases such as amount = 0, empty coin array, or coins containing 0 or negative values must be handled explicitly.

Best practices include sorting coins and adding early breaks to improve performance, using clear variable names like dp and coin_used, and writing helper functions to reconstruct solutions when needed. Always clarify with the interviewer whether they want combinations or permutations for the counting variant, and whether each coin can be used unlimited times or only once. Writing thorough test cases that cover canonical vs non-canonical systems, small and large amounts, and impossible cases will catch most bugs. Finally, prefer bottom-up tabulation for iterative clarity and to avoid recursion depth limits in Python for large amounts.

• Initialize dp correctly: infinity for min coins, 1 for count base case dp[0].
• Check reachability before transition: ensure dp[i - coin] is not infinity before using it.
• Use correct loop order: coin-first for combinations, amount-first for permutations.
• Handle edge cases: amount 0 should return 0, empty coins with positive amount is impossible.
• Avoid overflow: use float('inf') in Python or amount+1 as sentinel instead of max int.
• Consider reconstruction: store parent pointers if the actual coins are needed, not just the count.

Interview Questions

The coin change problem is a staple of technical interviews at top technology companies. Interviewers use it to assess understanding of dynamic programming, edge case handling, and ability to adapt the core pattern to variations. Below are common questions and how to approach them.

1. Minimum Coins to Make Amount

Question: Given coins = [1, 2, 5] and amount = 11, what is the minimum number of coins needed? What if amount = 3 and coins = [2]? This is the classic LeetCode 322. The expected answer is to implement bottom-up DP with O(n * amount) time and O(amount) space, returning -1 if impossible. Be prepared to explain the recurrence and walk through the DP table. Follow-up: Can you also return the coins used? This tests reconstruction with parent pointers.

2. Count Number of Combinations

Question: Given coins = [1, 2, 5] and amount = 5, how many distinct combinations exist? This is LeetCode 518 (Coin Change II). The key is to emphasize that [1,2,2] and [2,1,2] are the same combination, so you must iterate coins outer, amounts inner. The answer for this example is 4. Follow-up: How would you count permutations instead? Answer: swap the loops. This tests understanding of loop order semantics.

3. Why Does Greedy Fail? Provide a Counterexample

Question: Can we solve coin change greedily by always picking the largest coin? The interviewer wants you to demonstrate that greedy is not always optimal. Provide a counterexample: coins [1, 3, 4], amount 6. Greedy picks 4+1+1 (3 coins) but optimal is 3+3 (2 coins). Explain that greedy only works for canonical systems and that DP is needed for the general case. This tests conceptual depth beyond coding.

4. Bounded Coin Change with Limited Supply

Question: Each coin can be used at most once, or has a limited count. How does your solution change? This variant tests adaptation to 0/1 or bounded knapsack. The solution requires a 2D DP or modifying the 1D DP to iterate amounts backwards to avoid reuse, or using binary optimization for limited counts. Discuss the time and space trade-offs and how the recurrence changes to dp[i][j] = min(dp[i][j-1], dp[i - coin][j-1] + 1).

5. Optimize Space and Handle Large Amounts

Question: Amount can be up to 10^6, can you optimize space? Or amount is 10^9, what would you do? For the first part, explain that 1D DP already uses O(amount) which is optimal for DP, but BFS might find a solution faster if it is shallow. For huge amounts, discuss that DP is pseudo-polynomial and infeasible, and that you would need mathematical insights, such as using the Frobenius number, Dijkstra on residues modulo the smallest coin, or greedy with canonical coin system detection. This tests awareness of complexity limitations.

Preparing for these questions involves not just memorizing code but understanding the underlying principles, being able to derive recurrences on the spot, and clearly communicating trade-offs between approaches.