Getting All Four Numbers to Equal 24
The 24 Game gives you four digits and asks you to combine them with addition, subtraction, multiplication, and division to hit exactly 24. It sounds trivial until you stare at a hand like 3 7 3 7 or 1 5 5 5 and your brain starts making soft whimpering noises. That is the actual experience most people have. When manual solving hits a wall, a solver exhaustively checks every permutation of the four numbers paired with every valid arrangement of the three operators between them. There are 4! = 24 orderings of the cards, and for each ordering you have 4^3 = 64 operator combinations. Brute force gets you to 1,536 expressions before you even account for parenthesization, which doubles the effective search space depending on how you structure the tree. A proper solver builds an expression tree and evaluates all five binary tree shapes for each number permutation. That is the difference between missing a solution and finding it instantly. I spent about six hours writing a JavaScript implementation once because the available online tools at the time kept choking on fraction intermediates. The problem was floating point drift. A solution path might go through 1/3 or 5/7, and when Python or JavaScript multiplies those floats back down later, you end up with 23.9999999997 instead of exactly 24. My workaround was switching every intermediate value to exact rational arithmetic using a simple numerator/denominator pair with GCD reduction. It added maybe forty lines of code and eliminated every false negative I had been chasing. If you are building your own solver, do not skip this. It is the single most common failure mode.
Here is the core algorithm in plain terms. You take the four numbers as a multiset. Pick any two, apply every possible operator that yields a valid result, replace those two with the result, and recurse on the new three-number set. Repeat until you have one number left. If it equals 24, return the expression. If you exhaust all paths without success, the hand is unsolvable. The expression tree approach is cleaner if you prefer a bottom-up method. You generate all possible results from pairs of numbers, store them with their expression strings, then combine those intermediate results with remaining numbers. This naturally handles the different parenthesization patterns without explicitly generating tree shapes. One thing beginners consistently miss is that division does not have to produce integers at intermediate steps. A hand like 1 5 5 5 solves as 5 * (5 - 1/5) = 24. The 1/5 is a valid intermediate, and the solver needs to track it. If you restrict yourself to integer-only arithmetic, you will falsely report that some solvable hands have no solution. This alone accounts for maybe a third of incorrect "no solution" reports in poorly written solvers.
Practical considerations
The total number of distinct four-number multisets using values 1 through 13 is C(13+4-1,4) = 1820. Of those, roughly 1362 are solvable and about 458 are not. Hands like 1 1 1 1 and 1 1 1 2 are famously unsolvable. If you are using a solver, verify it against these edge cases. A correct implementation should report them as unsolvable rather than crashing or looping. Another edge case that caught me off guard: commutative operator caching. Addition and multiplication are commutative, so a*b and b*a are redundant. If you are optimizing performance, skipping one of each pair cuts the operation count by roughly half without affecting correctness. Division and subtraction are not commutative, so both a/b and b/a must be considered when a != b. The naive approach checks both even when a equals b, which wastes cycles but never produces wrong answers. For four numbers this waste is negligible. It only matters if you are building a variant with more inputs. There are also hands where the only solution requires a very specific parenthesization pattern that a greedy left-to-right evaluator will never find. For example, (a + b) * (c + d) is structurally different from ((a + b) * c) + d. Any solver that only tries one parenthesization order will silently miss solutions. The five distinct full binary tree shapes for four leaves are all required.
Get the Full Details
I have seen people try to solve this with dynamic programming or memoization across subsets, which works fine for larger versions of the game but adds unnecessary complexity here. For four numbers, brute force is faster to implement and runs in under ten milliseconds on any modern device. The overhead of a sophisticated algorithm outweighs any theoretical efficiency gain at this scale. If you want to use an existing solver rather than build one, most implementations online handle the standard 1-13 range correctly. The ones that do not are usually the ones with the floating point issue I described, or the ones that ignore fractional intermediates. A quick smoke test with 1 5 5 5 will tell you whether a given tool is trustworthy. If it says that hand is unsolvable, discard it. The game itself is a solid mental exercise for arithmetic fluency, but the real value is in understanding the search space. The constraint that every number must be used exactly once is what makes it deceptively hard. Remove that rule and almost any four numbers become trivial. Keep it and you are navigating a finite but tight combinatorial landscape where a single misplaced parenthesis can be the difference between a solution and a dead end.
