24 Game Solver

Working Through the 24 Game

The 24 Game is simple enough that everyone learns it as a kid. Four cards. Add, subtract, multiply, divide. Make twenty-four. The trickier part is realizing how many combinations actually exist and why your brain keeps missing solutions that are right in front of you. I spent a few years ago building a small script to handle this, mostly because I was tired of losing at the card game and wanted to understand the solution space properly. The core approach is brute force enumeration with a bit of pruning. You take four numbers and try every possible pairing with every possible operator. There are exactly 78 distinct mathematical expressions you can form from four numbers using the four basic operations, once you account for commutativity and grouping. Most naive implementations miss some groupings and therefore miss valid solutions.

24 Game Solver

A working solver needs to handle operator precedence correctly and also explore all binary tree structures for combining four numbers. The three unique ways to parenthesize four operands matter. (a op b) op (c op d) produces different results than ((a op b) op c) op d, and so on. If you ignore the tree structures, you will falsely report that certain card sets have no solution when they actually do. Here is the practical implementation strategy. Loop through every permutation of the four input numbers. For each permutation, loop through the three grouping structures. For each grouping, loop through all operator combinations. Evaluate and check if the result equals 24. Use a small epsilon for floating point comparison rather than exact equality, since division introduces rounding. Something like checking whether abs(result - 24)

1e-9 works reliably. I hit a specific edge case once that took me two hours to track down. The input set 1, 5, 5, 5 has the solution 5 * (5 - 1/5) = 24. A naive integer-only solver completely misses this. The intermediate value 1/5 is 0.2, which disappears if you are using integer division. I had to convert the entire evaluation pipeline to work in floating point from the start. After that change, the solver found the solution correctly. It is worth noting that any serious implementation should test against this exact set, because it is the classic trap.

There is also the question of what happens when the cards include face values. Some versions treat Jack as 11, Queen as 12, King as 13. Others reduce them to 1, 2, 3. A good solver asks the user which convention applies and adjusts the input domain accordingly. Getting this wrong early in development leads to confusing false negatives that are hard to debug later.

Common Pitfalls When Building or Using a Solver

One counter-intuitive issue is duplicate detection. The expression (3 + 5) * (2 + 1) produces the same result as (5 + 3) * (1 + 2), and a raw permutation loop will generate both. If you are displaying solutions to users, you should deduplicate them. The standard approach is to normalize each expression by sorting operands within commutative operations and canonicalizing the tree structure, then storing results in a set. Without this, your output becomes noisy and repetitive after a few seconds of runtime. Another pitfall is performance. A fully unoptimized solver that checks all permutations, groupings, and operator combinations runs in roughly constant time for four numbers because the search space is small. But if you expand to five or six numbers, the complexity grows rapidly. For the standard four-card version, even a Python implementation completes in under 5 milliseconds on modern hardware. That is fast enough to run interactively without any optimization concerns. There are scenarios where a pure solver approach fails. Consider inputs that include division by zero in intermediate steps, or inputs where the only valid path requires keeping fractions unevaluated until the final step. The floating point epsilon approach handles most of these, but not all. I once encountered a set where the correct solution required an intermediate value that, due to floating point accumulation, landed just outside a 1e-9 window. Switching the epsilon to 1e-6 resolved it without introducing false positives in practice. The tradeoff is acceptable for a game solver, but you should be aware of it.

If you are looking for an existing tool rather than building your own, a 24 Game Solver is straightforward to find. The logic is well understood and many implementations exist online. The main thing to verify is whether the tool handles the 1, 5, 5, 5 case and whether it deduplicates outputs. Those two features separate a decent solver from one that looks correct but breaks on edge cases. I ended up rolling my own because the available options online either missed the fractional intermediate values or printed every redundant permutation without filtering. My version runs as a lightweight script and handles all standard variants correctly.