Fewest Coins for Amount

Problem Statement

You're given a set of coin denominations, each usable as many times as you like, and a target amount. Find the smallest number of coins that add up to exactly that amount. If there's no way to make the exact amount with these denominations, print -1 instead.

Input Format

The input has exactly two lines:

• Line 1: the coin denominations, as space-separated positive integers, no two of which are the same.
• Line 2: a single integer, the target amount.

Output Format

Print a single integer: the minimum number of coins that sum to exactly the target amount, or -1 if no combination of the given denominations reaches it exactly.

Example Walkthrough

Take the first sample: denominations 1 2 5, target 11. Imagine building up a table dp where dp[x] is the fewest coins needed to make amount x, starting from dp[0] = 0 (zero coins make an amount of 0). For each amount from 1 up to 11, dp[x] is the smallest of dp[x - c] + 1 over every coin c that's small enough to fit (c <= x): dp[1] = dp[0] + 1 = 1 (using one 1-coin). dp[2] = 1 (one 2-coin, since dp[0] + 1 beats dp[1] + 1). dp[3] = 2 (a 2-coin and a 1-coin). dp[4] = 2 (two 2-coins). dp[5] = 1 (one 5-coin, beating any combination of 1s and 2s). Continuing this way up to dp[11]: the best combination turns out to be dp[6] = dp[5] + 1 = 2 (5 + 1) or dp[4] + 1 = 3 (worse), so dp[6] = 2; eventually dp[10] = dp[5] + 1 = 2 (two 5-coins), and dp[11] = dp[10] + 1 = 3 (two 5-coins and one 1-coin). No other combination of 1s, 2s, and 5s reaches 11 in fewer than 3 coins, matching the expected output.

Approach

Trying combinations directly — for instance, recursively choosing a first coin and then solving the remaining amount — looks natural, but the same remaining amount can be reached by many different sequences of earlier choices, and a naive recursive solution ends up solving those repeated remaining amounts over and over. This is the same kind of repeated-subproblem issue that shows up when computing Fibonacci numbers by naive recursion, and it has the same fix: don't recompute an already-solved subproblem, build it up once and reuse it.

Build a table dp indexed by amount, from 0 up to the target. dp[0] = 0 by definition — no coins are needed to make nothing. For every larger amount x, dp[x] depends only on smaller amounts: for each coin c that's no larger than x, using one of that coin leaves amount x - c still to make, which costs dp[x - c] coins by definition (already computed, since x - c < x), plus the one coin just used. dp[x] is the smallest such value across every coin choice — try every coin, and keep the best. If no coin makes progress possible (every relevant dp[x - c] is itself unreachable), dp[x] stays unreachable too.

Filling the table from dp[0] up to dp[amount], in order, guarantees that whenever dp[x] is being computed, every dp[x - c] it depends on has already been finalized. Once the table is complete, dp[amount] is the answer directly — or, if it was never updated away from its "unreachable" placeholder, the amount can't be made exactly with these coins, so the answer is -1.

Common Mistakes

• Trying to solve this with a greedy approach — always picking the largest coin that fits. Greedy happens to work for denominations like 1, 5, 10, 25, but it isn't correct in general. With denominations 1, 3, and 4 and a target of 6, greedy would pick 4, then have to fill the remaining 2 with two 1-coins, for 3 coins total (4 + 1 + 1) — but 3 + 3 reaches 6 in only 2 coins. Only checking every combination systematically, as the dp table does, is guaranteed to find the true minimum.
• Not distinguishing "unreachable" from an actual coin count of 0. If the dp table is initialized with 0 everywhere instead of a placeholder like infinity, an amount that's genuinely impossible to make can end up looking like it costs 0 coins, and the final -1 check has no way to tell reachable amounts apart from unreachable ones.
• Forgetting the amount = 0 case. It's tempting to assume the answer must be at least 1, but making an amount of exactly 0 correctly takes 0 coins — this should fall out naturally from dp[0] = 0 rather than needing a special case, as long as the base case is set up correctly from the start.