What a solver result can tell you
Published · Reviewed
Two outputs can disagree because they answer different poker questions. Before comparing a betting Action frequency or an EV, check the game definition, the result’s units, and how the answer was calculated.
Start with the game you actually specified
Consider a heads-up flop after the button raises and the big blind calls, with 100bb starting stacks. That description leaves much of the model unspecified. It does not identify the opening size, the weighted preflop ranges, the rake model, the board, or the sizes either player can use after the flop.
Write those inputs beside the output. A useful record includes the pot and remaining effective stacks, the complete board with suits, and weighted ranges for both seats. “Button versus big blind” is a category of situations, not a reproducible configuration.
The next input is the betting tree. If the tree offers checking and a single bet size, the solver distributes strategy over those options. It has not rejected every size that you omitted. Its answer can be internally consistent while leaving your preferred live-game size unanswered. The range and menu controls in PioSOLVER’s tree builder make those modelling decisions explicit.
Read convergence as a property of that game
A numerical solution is calculated iteratively. Its stopping target concerns the configured game; it does not certify that the game matches an opponent. Tightening the Solve tolerance cannot repair a missing action or an unsuitable starting range.
Check both whether the computation has settled sufficiently within the chosen model and whether that model suits the question you want to answer. Greater computational precision does not establish that the model is suitable.
This matters when a product uses the word “exact.” In Turnstone’s stored-solution labels, that word remains qualified by the input ranges, permitted actions, and stopping criterion. It does not mean a strategy for every possible Hold’em situation. Keeping the qualification next to the label is more useful than hiding it in a general disclaimer.
Keep approximation error separate
A search can replace distant parts of a tree with estimated continuation values. Turnstone uses a learned value model at the turn boundary of its flop search. That reduces the future game it explicitly searches, but introduces an approximation that needs its own evaluation.
The DeepStack research paper is a primary reference for combining poker search with learned evaluation. It supplies context for the approach, not a transferable accuracy claim for Turnstone. Different training distributions, action abstractions, and search procedures need separate measurements.
A reference solver’s residual Exploitability and a learned search’s decision loss are not interchangeable. Even the reference is calculated under a particular game definition. An evaluation should explain which quantity it measures and how that quantity was aggregated, rather than labelling every percentage “accuracy.”
Compare like with like
Imagine two reports, one evaluating a previously tested collection of spots and another describing a larger library of stored boards. The larger inventory does not update the older evaluation. To claim coverage for the new library, the added situations need to be evaluated under the method being claimed.
The same problem arises with a mean. An average across tested boards can conceal one poorly performing spot. It also depends on whether boards receive equal weight or weights intended to represent deals or opportunities. A frequency averaged across board patterns answers a different question from how often a player bets after reaching a decision.
Before comparing two displayed values, check their units and accounting conventions. A value that includes chips invested earlier cannot be directly compared with one measured from the current decision. PioSOLVER’s description of its displayed numbers is a useful reference for reading those labels rather than guessing from the size of the number.
Turn a difference into a narrower question
Suppose two tools show different flop bet frequencies. Start by matching the board and ranges, then the pot, stacks, rake treatment, and menus on later streets. Check that both numbers describe the same decision and use the same weighting. Only after those checks is a difference evidence about the computations themselves.
If the inputs cannot be matched, record the mismatch. It may still be useful to study each model, but it cannot establish that one implementation is more accurate. A named-product comparison would need a shared test setup and an explicitly defined measurement.
Our methodology lists the fields we expect alongside published results. This article is an interpretation guide, not a new experiment: it publishes no solver frequencies, measured timing, or performance comparison. Its practical use is to help you decide which conclusions a result supports before trying to turn it into a rule for play.