Evaluation

Eval Panel

The Eval panel (CTRL-E) evaluates live whatever position sits on the board; on a bearoff position it specialises and additionally computes the EPC (Effective Pip Count). It is opened by pressing CTRL-E, by clicking the Eval tab in the lower panel, or by running the eval command; epc, its former name, opens it too. The panel was called EPC, then Bearoff, before becoming Eval — so this is where to look for what an earlier version called the Bearoff panel, the name now only naming the tab that configures the bearoff tables.

The panel always shows the single decision the position on the board calls for — never two at once — and the facts that go with it. Each quantity is read in the axis that suits it rather than in a single imposed axis: the winning, gammon and backgammon probabilities and the cubeless equity of each player, computed before the roll, are read per player (bottom, top, then Δ), to the left of the cube decision, when no dice are showing. Facts and decision stay side by side: the cube decision never drops below the figures that justify it, whatever the interface language and the position on the board. As soon as dice are showing, these same before the roll values change axis: they are read on roll, at the head of the candidate-move list, as an italic before the roll row — not one more candidate move, a reference against which to read each move. The gap between that row and a move contains the luck of the roll, never the merit of the move, and so it carries no error column. On a pure bearoff position, a second table, still per player and always present, dice showing or not, carries the EPC, the pip count, the wastage, the average number of rolls and the standard deviation; these five columns never migrate. The two tables are stacked and share the same column grid: same edges, same column guides, a single column of dots — they read as one two-storey object. Above the tables, the header band carries the title, the regime badge and the engine attribution (the depth of the last evaluation appears there too), then, on the right, the Challenge box and the Add to database button. As long as gammonNet has returned nothing, the panel says so in one line: “Evaluating…”, or “Set up a position” on an empty board.

Only the candidate-move list scrolls — the before the roll row, too, stays pinned above it; the rest of the panel (facts, badge, cube decision) always remains visible, with no particular adjustment of the panel size.

The facts table and the decision are computed by gammonNet, embedded, without XG or gnubg. The computation follows the position without ever freezing the interface: a 0-ply depth is displayed immediately on every gesture, then, after half a second of stillness, a deeper evaluation (2 plies by default, adjustable in the gammonNet tab of the settings) replaces it in the background — any new gesture cancels that background computation. The depth shown in the badge strip, or inside the regime badge on a race position, is always the one that actually produced the figure shown, never the one requested; it is not repeated on every row, since a live evaluation shares the same depth for all moves. The equity of the candidate moves and of the cube decision follows the score of the position: in money game it is expressed in points, at a match score in normalised equity — the same scale as XG and GNU Backgammon, where winning the value of the current cube is worth +1 and losing it −1 — never mixed in the same table. The column header states it explicitly rather than leaving the scale to guess: “Equity (money)” in money game, “Equity (match)” at a match score. It accounts for the live cube: the search values every terminal position through the cube model (Janowski, measured efficiency) in the position’s cube state, the way XG and GNU Backgammon do in cubeful evaluation. This is what makes the gammon-go and gammon-save effects visible at the score — at 4-away/2-away, the player behind plays 8/2 6/2 on an opening 6-4 because an early double will give the gammon the value of the match, something a cubeless evaluation cannot see. The before the roll row, by contrast, stays a cubeless equity: it is a fact about the position, not a decision. The evaluation is never stored: it is a computation, not an analysis. Clicking a candidate move shows it on the board as arrows, exactly as in the Analysis panel. The discreet ? button, in the badge strip, leads to the gammonNet engine repository; the full attribution (Strehl network, gammonNet configuration) appears in the Acknowledgments of the help.

The panel rolls out the position like the Analysis panel (see Rollouts): Ctrl+click and Shift+click select moves, the right-click opens the same menu — rollout, copy of the position and the evaluation, or of the position and the selected moves —, Shift+R starts or stops the rollout and Esc cancels it; a thin bar follows the games played, and each rolled-out move carries its result in the Rollout column (without dice, under the cube decision). Since the board is a scratch board, the rollout is never saved: it is played in memory, with no open database as on a read-only database, and its result is shown only as long as the board stays the same. A rollout started before a change to the board is not shown on the new position.

The Add to database button, at the head of the badge strip, stores the position on the board in the database; CTRL-S, the w command and the Save Position toolbar button do the same. Only the position is written, never the evaluation shown; if gammonNet automatic analysis is enabled, its batch starts afterwards, as after an import. The status bar announces the position’s number, including when it was already in the database: it is then marked as individually imported, and the Individually Imported filter (s i) finds it. The panel stays open on the same board, which remains a scratch board: you can move a checker and add the variation, and leaving the panel brings you back to what you were studying. The button is disabled while no database is open, or while the position cannot be saved (for example the panel’s starting position, where the top player has borne off all their checkers); its tooltip gives the reason.

The user edits the checker position over the whole board, exactly as in edit mode: left click places a checker of the bottom player, right click a checker of the top player. The second table, the race one, only appears when the resulting position is a pure bearoff (all checkers of both players in their home board); on any other position, only the table of the four common columns (win, gammon, backgammon, cubeless) responds, and the decision bears on the checkers or on a generic cube depending on whether dice are showing.

In each facts table, one row per player — identified by its coloured dot, the black player always at the bottom. The first carries, as long as no dice are showing, the player’s win, gammon and backgammon (probabilities, without the % sign) and cubeless equity; the second, on a bearoff position and dice showing or not, the EPC, the pip count, the wastage (difference between the EPC and the pip count), the average number of rolls and the standard deviation. When both players have values to compare, a Δ row gives the signed differences (bottom − top: negative when the black player is ahead). Outside a race position, showing dice therefore makes the facts tables themselves disappear: the four columns they carried have just changed axis, on roll, at the head of the move list.

The cube decision always has the same shape, whatever the origin of the figures — exact table, evaluated regime or ordinary gammonNet evaluation: one row per option, in the order no double, double/take, double/pass, with its equity in the position’s frame of reference and its gap to the best option. The order never changes, unlike the move list: the three options have names, so it is the name one reads, not the rank. The best one is recognised by its highlighting and by its gap cell left empty. When the cube has already been turned, the options read no redouble, redouble/take, redouble/pass.

A last row gives the verdict. It takes four values: no double, double, take, double, pass and too good to double, the last when playing the position on is worth more than cashing the point: doubling would then be a mistake for the opposite reason to that of a plain no double. It is also the only place where the panel says there is no verdict, rather than suggesting a computation in progress:

no decision — the regime is not entitled to one; the cube verdict is never estimated (see the estimated badge);
not evaluable at this score — the engine refuses the position, typically a score beyond the horizon of the match equity table, i.e. a side with more than 64 points to go;
opponent owns the cube and cube dead (Crawford) — the cube cannot be turned. The equities remain displayed, for information, but no option carries a gap: an error is what a choice costs, and there is no choice.

In money game, the Jacoby and Beaver rules active on the position appear under the cube table, in small badges next to the verdict they change: the no double verdict of a position under the Jacoby rule is not the same computation as without it, and nothing else on screen said so.

Under the Beaver rule, the double, take row is worth the opponent’s best answer other than passing: taking, or beavering — redoubling at once while keeping the cube, the game then being played for four times the stake — with the doubler then answering with a raccoon (eight times the stake, cube on his side) when it pays him. The verdict and the errors are read on this row, as without the rule; at a match score, the rule does not apply.

A third badge, Max cube, appears when the source identifier caps the cube — at a match score as well as in a money game. That one does not describe the computation shown above it: the built-in evaluator does not model a ceiling, so the verdict is the one for a free cube. That is precisely why the badge is there: a capped cube is the one visible reason blunderDB and eXtreme Gammon can announce two different verdicts on the same position.

The player on roll and the cube position are edited directly on the board, as in edit mode: clicking a player’s bearoff/score rectangle gives that player the roll; clicking the cube cycles centred → owned bottom → owned top (right click cycles the other way). The cube value stays pinned — in money game the equities are expressed in units of the current cube, only its owner matters. The analysis is recomputed immediately. In the estimated regime, the badge itself is clickable and opens the Bearoff tab of the settings directly; its tooltip explains why (cube verdict not estimable, ADR-0009) and how to widen the exact domain.

The score is also edited directly on the board, as in edit mode: left click on a player’s score rectangle decrements their number of points to go, right click increments it. Leaving the money score (-1, -1) by editing one side alone automatically aligns the other side on the same value rather than leaving an inconsistent score. On a bearoff position in the exact regime, moving from a money score to a match score leaves the winning probability as it is (a database lookup, valid whatever the frame of reference) but switches the displayed equity and cube verdict to those of the evaluated regime — the exact table being money by construction, it cannot answer the question asked at the score. The badge then becomes composite (“exact (win) · evaluated (cube)”) to say so explicitly.

The dice, finally, are edited the same way, and they are what decides the question being asked: dice on the board make a checker decision (the list of candidate moves), no dice a cube decision. Left-clicking a die raises its value (6 wraps to 1), right-clicking lowers it (1 wraps to 6); clicking a die on a board that has none puts down two at once — a single die would be neither a checker decision nor a cube decision. Clicking a player’s rectangle removes the dice to ask a cube question, and the next click on a die puts them back as they were.

BACKSPACE, or Clear the position in the menu of a right click outside the board, clears the position: empty board, money score (-1, -1), no dice showing — values specific to the Eval panel, different from those used in edit mode (7 everywhere, dice 3-1), to stay consistent with what the panel shows by default. Starting position, in the same menu, sets up the checkers of a new game on those same values.

Cube matrix

A cube decision is not a property of the board. The same checkers, the same pip count, are a double at 2-away/4-away and a no-double at 4-away/2-away; a player who has learnt the money answer has learnt one cell of a grid. The Eval panel shows the cell the position carries; the cube matrix shows the whole grid.

The cm command opens it on the position on screen. Each cell gives the verdict at one score: the row is the number of points the player on roll still needs, the column the number the opponent still needs. The four verdicts read ND (no double), DT (double, take), DP (double, pass) and TG (too good); a cell the engine refuses carries a question mark and says why on hover, which also gives the cell’s three equities. Three match lengths are offered: 5, 7 and 9 points.

The cell of the score the position actually carries is framed, and its row and column headers underlined: reading starts there, “my cell, and what surrounds it”. It is framed as soon as both of the position’s away scores fit in the displayed grid; changing the length moves the frame or removes it. A money position, the Crawford game, or an away beyond the grid designate none: there is no cell to show, and showing an approaching one would be false.

The position’s own score is replaced by each cell’s; its cube is kept. The grid answers “at what score would I turn this cube”, not what a centred position would do. It is post-Crawford throughout: during the Crawford game the cube is not in play, and a column of “you may not double” would say nothing about the position.

Every cell is its own search. The engine is match-aware — it does not play the same game at 2-away as at 7-away — so a single search read through different match equities would be wrong exactly where the score matters. The grid arrives at 0-ply first, then recomputes at the configured display depth once the window is at rest: the same escalation as the rest of the panel, for a 9-point grid costing about a second and a half.

The same grid is computed outside the interface, with the command line’s cubematrix command.

Reference data panel

The Reference data panel gathers the score tables. It opens with CTRL-SHIFT-R or the ref command, with no database open. The met, tp2, tp4 commands and their _live / _last variants, gv1, gv2 and gv4 open it on the tab of the requested table. Rows and columns are the points needed to win the match: the row is the player in question, the column is their opponent. Five tabs:

MET — the Kazaross-XG2 match equity table, from 1 to 15 points away, as a percentage chance of winning the match;
Take points — at cube 2 (from 2 to 9 points away) and cube 4 (from 3 to 9), each in two side-by-side grids: long race (live cube) and last roll (dead cube);
Gammon values — at cubes 1, 2 and 4;
Aggregated — a grid from 2 to 9 points away where each cell has three lines: the take point at cube 2 (live / dead), at cube 4 (live / dead), then the gammon values at cubes 1, 2 and 4, in a muted colour. A dash marks a value that the table does not define at that score;
Neil’s numbers — a mental shortcut for the MET, due to Neil Kazaross.

Neil’s numbers. The leader’s equity is estimated by E ≃ 50% + (score difference) × Neil(n), where n is the number of points the trailer needs. The numbers are 10 at 3 away, 9 at 4, 8 at 5, 7 at 6, 6 at 8, 5 at 11, 4 at 15, 3½ at 19 and 3 at 25 (mnemonic: “8 is 6, 11 is 5, 15 is 4”); in between they are interpolated linearly (6½ at 7, 5⅔ at 9, 5⅓ at 10, 4¾ at 12). For example, at 3 away against 5 away, the estimate is 50 + 2 × 8 = 66%, and the MET gives 64.8%. The tab shows the row of numbers, then a leader × trailer grid, from 2 to 15 points away: each cell gives the estimate and, in small type, its difference from the Kazaross-XG2 MET, to show where the shortcut deviates. The shortcut does not hold when the leader is at 1 or 2 away: the row of the leader at 2 away shows the MET value, in a muted colour and with no difference. Source: Kit Woolsey, Match Equity Table, GammOnLine, 1999.

Bringing a position into the Eval panel

The panel opens by default on a bearoff position, but a study most often starts from a position already at hand. Four gestures bring it there:

Right click on the board, in an analysis panel or while navigating a match, then Evaluate this position: the Eval panel opens directly on that position, as displayed; Evaluate the mirror of this position opens it there seen from the other side. The context menu does not appear in the Eval panel or in the Search panel, where the right button already serves to place checkers of the other colour.
Right-click on the board, then Evaluate in a new tab: a new view, named Variant of #n (n being the number of the original view), opens in the Eval panel on the displayed position, where variants can be set up freely. The original view keeps its position, its list and its analysis. This choice is not offered in the Transcription panel.
CTRL-C then CTRL-V: copy the position from the analysis panel, then paste it once in the Eval panel. Pasting also accepts an identifier from elsewhere — an XGID (eXtreme Gammon, GNU Backgammon, another instance of blunderDB) or an OGID (OpenGammon): it only has to be in the clipboard.
The command import XGID=… (or import OGID=…) for when the identifier is not in the clipboard but in a message, on a forum read in a terminal, or produced by a script. It is the same verb as plain import: with no argument it opens a file picker, with one it reads the identifier. The path is then identical to pasting — same reading, same deduplication, same opening of the imported position.

An OGID carries a position and nothing else: no evaluation, no comment. The position therefore arrives without an analysis, exactly like a bare XGID, and the built-in evaluator can fill the gap afterwards.

In an OGID, the Crawford game is read from the C that follows the match length (7C): without it, a player one point from the goal is past the Crawford game.

A screenshot of the board (eXtreme Gammon, default theme) can be read three ways: paste the image (CTRL-V), drag it onto the window, or open it with CTRL-I (.png, .jpg). No database is needed. The position read lands on the edit board and is only a proposal: the points and the cube the reading is unsure of are ringed in orange; a doubt that cannot be ringed (the board’s direction when the point numbers are outside the image, unreadable dice) and what a screenshot never shows (the score, the side to move when the dice are hidden) are named in the status bar. Correct the board as usual, then save with the usual gesture: nothing is saved before. An image in which no known board is recognised is refused, with the reason in the status bar. The same reading exists on the command line (capture).

The Eval panel’s board is a draft: the position arrives there without its database identifier, so that no change made here can rewrite the record it came from. All the usual board edits remain available there (checkers, cube, dice, score), and the evaluation follows every change.

In the other direction, CTRL-C copies the Eval panel’s board to the clipboard, with an XGID recomputed from the checkers on the board — hence pasteable directly into eXtreme Gammon or into another instance of blunderDB. Only the position travels: the evaluation shown by the panel is not a database record and does not accompany the copy.

On leaving the Eval panel, the position previously viewed is restored: the draft is never saved on its own.

When the position is a pure bearoff (all checkers of both players in their home board) and no dice are showing, the cube decision shows, for the player on roll:

in the exact regime: the money equities (cubeless, no double, double/take, double/pass) and the money cube verdict (no double, double/take, double/pass or too good to double) — outside a match score, see above for the case of the score,
in the evaluated regime: the same equities and the same four-valued verdict, but played out by gammonNet (search + Janowski cube model) rather than read from a table — available even at a match score, which the estimated regime could never offer;
in the estimated regime: the cube verdict is then deliberately not shown — only the winning probability, in the facts table, along with its error margin, remains available.

As soon as dice are showing on a race position, this before the roll cube decision disappears — the board then calls for a checker decision, not a cube one — but the winning probability, for its part, remains a fact of the position, not a decision: it joins the before the roll row at the head of the move list, next to the EPC which, for its part, stays displayed just to the left.

A badge indicates the regime: exact (value read from a two-sided database), evaluated · <depth> (played out by gammonNet — the depth shown is the one that actually produced the figure shown), estimated ± margin, or, at a match score within the exact domain, exact (win) · evaluated (cube) — see above. The exact regime wins wherever it is available; otherwise the evaluated regime is displayed as soon as it has finished computing, replacing in place the estimated regime shown while waiting. See Methodology and assumptions of the Eval panel for the precise definition of the three regimes and their assumptions.

Widening the exact domain. The table computed on first launch covers 6 chequers a side. Two ways to go further, in the configuration’s Bearoff tab:

compute a wider two-sided table — up to TS-06-15 if the machine has the memory for it. The tab states the size, the memory and the time on this machine before starting, and the computation pauses and resumes. A cancelled computation leaves a .part file which is never read as a table;
point to any two-sided gnubg .bd file. The database with the widest domain automatically wins.

The panel’s board is a scratch board, and it is remembered. Leaving the Eval panel and coming back finds the position it was left on, not the default bearoff board: that one is only served the first time the panel is opened in a session. Sending a position from the database to the panel wins over that memory, and BACKSPACE hands back the default board at any time. Nothing is written to the database along the way — the scratch board has no position identity, and its evaluation is recomputed on arrival rather than carried over.

Challenge mode. The Challenge box, in the header band, enables a training mode: on every change to the position, the values of three zones are masked (replaced by “···”); clicking a zone reveals that zone only. Without dice, these are the bottom player’s row, the top player’s row and the cube decision — the Δ row only appears once both player rows are revealed. The decision block then keeps its three rows: it is its values, its verdict and the highlighting of the best option that disappear, failing which the exercise would be solved by looking for the bold row. With dice showing on a race position, each player’s EPC row is masked as before, but the third zone then covers the before the roll row and the move list together: the list being sorted from best move to worst, revealing it partially would already give the answer away. With dice showing outside a race position, that same single zone alone covers everything the panel displays. One can thus practise estimating each side’s EPC, then deciding on the cube or on the move to play, before checking. The setting is remembered.

No database open. The Eval panel does not need a database: once the welcome screen is dismissed, a position can be set up, pasted (CTRL-V) and edited there, evaluated, rolled out, and copied as text (CTRL-C) or as an image (CTRL-X, and CTRL-X CTRL-X with the evaluation). The right-click menu in the panel also offers Save the image (SVG)… and Save the image (PNG)…. The board of the Search tab is a scratch board too: it can be edited and receives a paste without a database, and one moves from one to the other without losing anything; running the search, however, requires a database. Only Add to database and CTRL-S require a database in the panel, and the status bar says so. No database is created behind the scenes. In the Eval panel as in the Search tab, the import XGID=… (or import OGID=…) command places the position on the scratch board, without a database. The Training tab also opens without a database: Scores, Checkers, Bearoff and Evaluation are available, Decision is disabled with the reason shown, and the finished session is not recorded (the journal says so). Tournament Direction requires an open database.

To close the Eval panel, press CTRL-E or switch to another tab.

Methodology and assumptions of the Eval panel

Every value displayed by the panel rests on precise assumptions, stated here exhaustively.

Domain. The race zone — winning probability and cube verdict — covers pure bearoffs only: every remaining chequer of both players in their home board. The position is evaluated before the roll; any dice set on it are ignored.

The EPC blocks, on the other hand, go further: a side gets its EPC as soon as its farthest chequer fits in the loaded one-sided table. With the default table (six points) that is the old home-board rule; with an eight-point table, computed from the Bearoff tab, a side with a chequer on the 8-point is treated like any other. Nothing is extrapolated: a chequer one point too far simply has no EPC, exactly as a chequer on the 7-point had none before. When the table that answered is not the six-point one, its name appears in the corner of the race block (“OS-08”) — without it one would read “six” by default and believe the side entirely home.

EPC blocks (always exact). The EPC, the average number of rolls and the standard deviation come from the exact distribution of the number of rolls needed to bear every chequer off, read from GNUbg’s one-sided database (6 to 10 points, 15 chequers, computed on the machine). EPC = average rolls × 49/6 (49/6 ≈ 8.167 is the exact average of pips per roll, doubles counted four times); wastage = EPC − pip count. The only idealisation is one-sided optimal play: each player minimises their own rolls, ignoring the opponent — that is the standard definition of the EPC.

Winning probability, exact regime. Direct lookup in the widest available two-sided database (TS-06-06 computed on first launch, an external file, or TS-06-11 computed from the Bearoff tab). These databases result from a complete retrograde analysis under optimal two-sided play by both sides: no additional assumption, error limited to quantisation (< 0.002%).

Winning probability, estimated regime. Outside the database’s domain: the probability is obtained by convolving the two one-sided distributions (the player on roll wins if their number of rolls is less than or equal to the opponent’s), then applying a frozen polynomial correction, calibrated offline against the TS-06-11 database. Three assumptions:

independence of the two bearoff processes — structural in a race, with no contact there is no interaction whatsoever;
optimal one-sided play by both sides — this is the approximation: in reality the trailing player deviates to play for variance and the leader for safety. The measured effect is an antisymmetric bias (the convolution overstates the leader’s advantage) which the correction absorbs statistically;
the correction was calibrated and validated on the oracle’s domain (up to 11 checkers per player). Measured residual error: standard deviation 0.05%, 99th percentile 0.17%, observed maximum 0.9% (in winning-probability points). Beyond 11 checkers per player, this bound is extrapolated — the trend is monotonic but no oracle certifies it.

Equities and cube verdict (exact regime only). The displayed equities are those of the money game, without Jacoby, the reference framework of the bearoff literature. Within the ≤ 11 checkers per player domain, gammons are impossible (each side has already borne off at least 4 checkers): this is not an approximation. The verdict (no double / double, take / double, pass) is reconstructed exactly from the stored equities, following GNUbg’s rule, validated verdict for verdict against its analysis.

Note

The cubeful equities assume optimal cube play by both sides all the way to the end: future recubes are fully valued (complete retrograde analysis). In the very volatile races at the end of the game, the cascade of recubes eats up almost all of the advantage of the side on roll — the “no double” and “double/take” equities can then be close to zero where an engine such as XG, whose cube model does not value this cascade, shows values close to the dead cube (for instance 2 checkers on the 3 point against 2 checkers on the 2 point: 62% winning chances, exact D/T +0.006 versus +0.475 for XG). The displayed decision, however, coincides with the engines’.

Winning probability and verdict, evaluated regime. Outside the exact domain, the winning probability comes from gammonNet’s raw output (0-ply search, then at the configured depth, never read from a table), and the verdict from a Janowski “Decide” applied to that output — the search plays out the trajectory instead of summarising a snapshot of it, which is precisely what the estimated regime could not do (see below) and allows, alone among the three regimes together with the exact one, a verdict at the match score.

This regime was measured, not merely assumed, against the built-in two-sided table (TestEvalMeasure, 4000 sampled money decisions, canonical parameters 2-ply k=12): money verdict agreement 93.4% (3735/4000), broken down by distance to gammonNet’s take point — 61.1% within 1% of the take point (the zone most sensitive to a coin toss), 88.3% between 1 and 5%, 91.5% between 5 and 10%, 94.0% between 10 and 20%, 94.4% beyond. Winning-probability gap: mean 0.85%, median 0.44%, 95th percentile 3.21%, maximum 8.30%. Cubeful-equity gap: mean 0.039, median 0.018, 95th percentile 0.151, maximum 0.406. The shape is the expected one: most of the disagreement concentrates exactly at the take point, where two legitimately different methods diverge most on a close decision — not a diffuse error that would cost equity everywhere.

This measurement covers money decisions, in a race. The match-score verdict — which only this regime can render — and contact positions have no published measurement: none of the above carries over to those cases.

Why not deeper than 2-ply? Because the measurement says it buys nothing. A checker decision at 3-ply evaluates the network 14 times more than at 2-ply (159,000 evaluations against 11,400, averaged over twenty real decisions) and takes about 14 times longer (3.9 s against 0.27 s on a single core of the same machine). Over forty real decisions replayed at both depths, the deeper search changed its mind twice, and both times the gain it claimed for itself was at most 0.0002 normalised equity: two orders of magnitude below 0.020, the threshold at which eXtreme Gammon calls a decision an error at all. Per decision, all cases together, the gain is 0.0000.

2-ply therefore remains the default; 3- and 4-ply are chosen in the gammonNet tab of the settings. At 3 and 4 ply, as in GNUbg, only the root compares several plays: at every interior node, the reply kept is the best one at 0-ply, and it alone is searched deeper. This does not say 3-ply is worthless in general, only that on this network, with this filter, it does not pay for the wait of someone sitting in front of a panel. The measurement is reproducible (TestThreePlyMeasure) and the conclusion will be re-judged if the network changes.

Why is there no estimated verdict? What follows targets specifically the convolution method (estimated regime), not the evaluated regime above: cubeful equity is a trajectory problem (when to double) that no statistical summary of the position captures — the best static model measured leaves a residual error (standard deviation 0.016 of equity, maximum 0.20) large enough to flip every close decision. Likewise, converting the verdict to the match score through a match-equity table was measured to be insufficient (12% of disagreements with GNUbg’s 2-ply analysis, including genuine blunders). Since a wrong verdict displayed with confidence is worse than no verdict, the convolution was never allowed to display a verdict — it is a search that plays out the trajectory, not a statistical summary, that fills this hole.

Note

The bearoff databases are immutable mathematical tables. blunderDB computes them itself, identically to GNUbg’s makebearoff tool — byte for byte — in the Bearoff tab of the configuration or with blunderdb bearoff generate.