docs: J7o player-POV walkthrough with postflop solves (#179 follow-up)#183
Merged
Conversation
Companion to docs/j7o_walkthrough_tests_1_4_2026-05-28.md (PR #179), which reported equity only. This doc reports **actual GTO action distributions** from postflop subgame solves at each decision point — true player-POV format. Architecture per street: - Preflop: read SB's 169-class blueprint at the root infoset (||p|); J7o gets its action distribution directly. - Turn / River: call ``solve_postflop_from_blueprint`` with the preflop action sequence and the board, then extract J7o's per-class strategy and J♠7♦'s specific per-history strategy. Limitation surfaced honestly: flop subgame solves are DEFERRED. Empirical measurement (2026-05-28): the vector-form Rust solver runs > 5 minutes of CPU per flop solve at the smallest viable parameters (top-K = 4 hand classes + J7o pin, 5 DCFR iterations). The chance tree from flop to river blows up per-iter cost. Turn solves succeed in ~15s and river solves in <1s (TerminalCache amortizes the dominant evaluator cost on a constant board). Flop directional reads are from the equity-only walkthrough in PR #179. Headline result for Test 1 (J7o, 40 BB, A♦8♥9♦ 2♣ 3♠): - Preflop: open_to_200 = 92.1%, open_to_300 = 6.3%, call = 1.6%, fold ≈ 0%. The 169-class engine confirms J7o is an opening hand at this stack. - Turn (2♣): raise_33 = 30%, raise_75 = 19%, fold = 17%, raise_100 = 14%. J7o still raises a lot of the time as a polarized bluff after following BB's modal turn action. - River (3♠): all_in = 49%, bet_100 = 15%, bet_200 = 11%, check = 7%. SB bombs the river half the time (BB's modal action is check at 84.5%, so this is SB facing a checked river with J-high). Total wall time: 21.6s (preflop blueprint 4.5s, turn solve 14.7s, river solve 0.5s, overhead 1.9s). Script: scripts/run_j7o_walkthrough_full_pov.py — designed so the SKIP_FLOP_SOLVES gate can be flipped to False in a future burst once the flop-subgame perf path is improved. Depends on: PR #182 (fix(blueprint_subgame): normalize b/r token equivalence at preflop boundary), which unblocks the postflop wiring for SB's opening raise. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6 tasks
amaster97
added a commit
that referenced
this pull request
May 28, 2026
) Quantifies PR #183's "5+ min, killed" deferral via an empirical 4-config sweep at the J7o A♦8♥9♦ flop after SB-opens-3bb → BB-calls: | Config | top_k | iters | Wall to terminal | Peak RSS | Outcome | |---|---|---|---|---|---| | 0 (floor) | 2 | 2 | 20:00 (timeout) | 2.62 GB | TIMEOUT | | 1 (minimal) | 4 | 5 | ~5:00 | 2.31 GB | OOM (sig 9) | | 2 (moderate) | 8 | 20 | ~2:00-2:30 | 2.93 GB | OOM (sig 9) | | 3 (light-prod) | 15 | 50 | ~10-20 s | (sub-sample) | OOM (sig 9) | Validates: realtime flop subgame is NOT feasible at any tested config on the current implementation. Even the floor (3×2 classes, 2 iters) cannot complete in 20 minutes, ruling out "shrink top_k further" as a fix — decision-node count dominates regardless of class count. Defers to docs/v1_10_postflop_optimization_plan.md (da38888) for authoritative root-cause analysis (dcfr_vector.rs:591-835 allocator pressure) and 4-PR remediation roadmap. Confirms v1.9.0 ship recommendation: flop = blueprint-only (PR #183's framing), live flop deferred to v1.10. Ships: - docs/flop_subgame_perf_measurement_2026-05-28.md (this measurement) - scripts/measure_flop_subgame_perf.py (reproducible single-flop driver) - scripts/run_flop_perf_measurements.sh (RSS watcher + 20-min hard kill) Engine and blueprint_subgame.py untouched. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
solve_postflop_from_blueprintfor turn and river solves.scripts/run_j7o_walkthrough_full_pov.py(1300 lines; SKIP_FLOP_SOLVES gate is flippable for future bursts).Headline result — Test 1 (J7o, 40 BB, A♦8♥9♦ 2♣ 3♠)
open_to_200 = 92.1%,open_to_300 = 6.3%,call = 1.6%, fold ≈ 0%.raise_33 = 30%,raise_75 = 19%,fold = 17%,raise_100 = 14%.all_in = 49%,bet_100 = 15%,bet_200 = 11%,check = 7%. SB bombs the river half the time when BB checks.Limitation surfaced honestly
Flop subgame solves are DEFERRED. Empirical measurement (2026-05-28): the vector-form solver runs > 5 minutes of CPU per flop solve even at top-K = 4 classes + 5 DCFR iterations — the chance tree from flop to river blows up per-iter cost. Turn solves work in ~15s and river solves in <1s (TerminalCache amortizes evaluator cost on a constant board). Flop directional reads are pulled from the equity-only doc (PR #179).
Wall time
Total: 21.6s (preflop blueprint 4.5s, turn solve 14.7s, river solve 0.5s, overhead 1.9s).
Depends on
fix(blueprint_subgame): normalize b/r token equivalence at preflop boundary) — merged. Without it, the very first call intosolve_postflop_from_blueprintwith a real Rust-blueprint action prefix crashes.Test plan
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
[Generated with Claude Code]