Search vs. Evaluation
Strip a chess engine down to its studs and there are exactly two machines inside. One looks ahead through the branching tree of possible moves; the other judges a single position once the looking stops. Everything else — the pruning tricks, the caches, the neural nets — is in service of doing one of those two jobs faster or better. This is the page that makes the rest of the cluster make sense.
Look ahead, then judge
Search is how far and how cleverly the engine looks ahead. Evaluation is how well it scores one position when it stops. They're inseparable but distinct: a deep search with a foolish evaluation calculates its way confidently to a bad conclusion; a brilliant evaluation with no search gets tactically flattened. Strength is the product of both. Hold that split in mind and every other term in computer chess snaps into one bucket or the other.
From minimax to alpha-beta
The base algorithm is minimax: assume both sides always play their best move, so you maximize your score while the opponent minimizes it, and pick the move that leads to the best guaranteed outcome. Done naively, minimax is impossibly expensive — the tree of chess positions branches about 35 ways per move and explodes.
The essential optimization is alpha-beta pruning. It tracks two bounds — alpha (the best you're already assured) and beta (the best the opponent will permit) — and the moment a branch is proven unable to affect the final decision, it stops examining it. Crucially, alpha-beta returns exactly the same move minimax would; it just skips the work that couldn't have mattered.
Alpha-beta is partition elimination. It's the optimizer proving a whole branch of the plan can't contain the answer and refusing to scan it — the same reason a well-partitioned table lets the engine skip everything outside the relevant range. You don't read the partitions you've proven are irrelevant; alpha-beta doesn't search the lines it's proven can't change the result. Same idea, same enormous savings.
Once the right branch is proven unable to beat what the left branch already guarantees, alpha-beta never looks inside it.
The refinements that make it fast
Alpha-beta only prunes well if good moves are tried first, so a stack of techniques exists to feed it in the right order and at the right depth:
- Iterative deepening
- Search to depth 1, then 2, then 3, reusing what you learned each time. It sounds wasteful but it isn't — it dramatically improves move ordering and always leaves a usable best move ready when the clock runs out.
- Move ordering
- Try the moves most likely to be best first — captures, killer moves, the hash move — so alpha-beta prunes as early as possible. Good ordering is worth enormous speed.
- Quiescence search
- At the leaves, keep searching only the "noisy" moves — captures and checks — until the position is calm, so the engine never stops its evaluation in the middle of a trade.
- Pruning & reductions
- Null-move pruning, late move reductions, futility pruning — a family of shortcuts that skip or shorten branches unlikely to matter, trading a sliver of accuracy for a lot of depth.
The problem quiescence solves has a name of its own — the horizon effect: the error of stopping at a fixed depth right before something decisive, like not seeing that the piece you just "won" gets recaptured on the very next move. Cut the search off mid-capture and the engine cheerfully reports a winning position that is actually losing. Quiescence extends just the forcing moves until the dust settles, so the number it hands back is trustworthy.
Transposition tables and Zobrist hashing
The same position is reached over and over by different move orders — that's a transposition — so an engine keeps a transposition table: a hash cache of positions it has already evaluated, keyed by a Zobrist hash (a 64-bit fingerprint of the board, updated incrementally as pieces move). Hit the table and the engine reuses the stored result instead of re-searching a subtree from scratch. Its size is the Hash setting — the single biggest memory knob on the engine.
The transposition table is a plan/result cache, and Zobrist hashing is its cache key — a hash of the "query" (the position) so logically-identical work arriving by different routes resolves to one entry. Sizing it against RAM is the same trade-off as sizing the plan cache or buffer pool: too small and you thrash, re-solving what you already solved; big enough and the repeated work is free. When I tell a client "your cache hit ratio is the whole game," I'm describing an engine's transposition table without meaning to.
How engines judged a position before neural nets
For fifty years, evaluation was a handcrafted formula — a human-designed sum of terms scoring a position in centipawns (100 centipawns = one pawn). The main ingredients:
- Material
- The raw value of the pieces (pawn 1, knight/bishop ~3, rook 5, queen 9). The biggest single term by far.
- Piece-square tables
- A per-square bonus or penalty for each piece — knights like the center, pawns want to advance. Cheap positional knowledge baked into a lookup table.
- Mobility
- How many squares a side's pieces control. More activity, better score.
- King safety
- Pawn cover, open files near the king, the count and weight of attackers. Often the difference between a sound position and a lost one.
- Tapered eval
- Blend separate midgame and endgame scores based on how much material remains, so priorities shift smoothly as pieces come off — king safety matters in the middlegame, king activity in the endgame.
This is the part that changed most. In 2020 the handcrafted evaluation started giving way to a trained neural network (NNUE), and by 2023 Stockfish had removed the last handcrafted term. But the search half of the engine — alpha-beta, iterative deepening, transposition tables, quiescence — is still, recognizably, the machine described above. Neural nets changed how engines judge; they didn't change how engines look ahead.
Reading engine output
Three terms decode most of what an engine prints. A node is one position examined; speed is quoted in nodes per second (modern engines hit hundreds of millions). A ply is one half-move, so "20 ply" is ten moves for each side. And centipawns are the evaluation unit: "+1.50" means a pawn-and-a-half edge. Full definitions live in the glossary.
- Chessprogramming Wiki — Minimax, Alpha-Beta, Iterative Deepening, Quiescence Search, Transposition Table, Zobrist Hashing, Evaluation.
- Stockfish evaluation documentation for the classical-to-NNUE transition (handcrafted eval removed in 2023).
- The NNUE page in this cluster for the modern evaluation half; the automation page for reading engine output in practice.
Now watch the evaluation half go neural
Search stayed classical; evaluation was reinvented. That story — and the incremental-update trick that made it fast enough — is next.