Benchmarks & research

Three-way postflop research

The preflop engine trains blueprints for 2–6 players, so a blueprint contains three-way flops. This page reports how the three-way re-solve (RangeCFR three-way) was built and checked.

What the re-solve computes

• The blueprint's own tree. The re-solve starts from the node's full public state (stacks, pot, who has acted, pot type). It uses the same betting skeleton the blueprint was trained on.
• Every hand. Each of the three ranges is kept combo by combo, with no hand abstraction. Card removal between all three hands and the board is exact.
• Cards. From a turn root, every river card is covered. From a flop root, the default full tree covers every turn and river when RAM permits. Quick preview or insufficient RAM can reduce turn coverage (see Sampling accuracy).
• Exact payoffs. Side pots are built in layers, dead money from folded seats counts, ties are split, and rake is taken proportionally from the matched pot (an unmatched bet goes back unraked). A player who folded earlier still blocks the cards they hold.
• An approximate equilibrium. The result depends on the number of iterations; the accuracy number below says how far it got.

Why three players are expensive

A third player greatly increases the number of decisions and the memory required for a full flop tree. Check the in-app RAM estimate before starting; reducing bet sizes or starting from a turn can make a large spot practical.

Three-way payoff validation

The three-way payoff calculation was checked against an independent direct calculation on test cases with side pots, folded players, ties and rake. Differences were at floating-point rounding level. This validates the payoff step; it does not by itself establish that a finite-iteration strategy has converged.

Checked against the heads-up engine

Configuration: the same blueprint tree and node, solved by the three-way engine with two players and by the heads-up RangeCFR. Metric: OOP EV and exploitability in % of the pot.

The two engines reach the same EVs on all three roots. On the flop they were run for different numbers of iterations, so their exploitability values are not a like-for-like accuracy comparison; the table does not show that the two engines are equally accurate there.

We have not yet made an independent cross-solver comparison for three-way postflop. The validation so far is internal: the payoff calculation, the heads-up reduction above, and two checks that apply as a solve runs. First, the players' EVs must add up to zero in a game without rake; they do, to within 10^-5 bb. Second, exploitability must fall steadily.

Convergence on a three-way turn

In an earlier measured turn spot, the displayed accuracy improved as the run progressed: 1.14% of the pot after 50 iterations, 0.33% after 100 and 0.17% after 150. These are results for that test configuration, not a promised speed for other trees or hardware.

What to expect on a desktop

The solver estimates memory for your exact ranges and betting tree before a run. River roots are generally the lightest, turns cover every river, and full flop roots can require substantially more RAM and time. The engine reports progress and measured accuracy as it runs, so you can stop at your chosen target. Earlier short flop benchmarks are not representative of a converged solve or the current build's speed. A reduced-turn preview is available when you want to explore a large flop tree with less RAM; the default remains a full-card solve when it fits.

Pots with four or more players cannot be re-solved locally; they keep the blueprint strategy trained with the rest of the tree.