From 4ce6a76b0946e4ba943d29c506c9e2fb00601efd Mon Sep 17 00:00:00 2001 From: Scott Gasch Date: Thu, 27 Aug 2026 07:41:41 -0700 Subject: Baseline: uPositional data-calibrated fix, enprise/trapped hints, EBF/beta-cutoff/counter-move stats, script.c FPE fix. No LMR, no counter-move-driven move ordering (both explored separately, kept out for now -- counter-move measured worse, ~655->647 solved on ecm879 @ sn=4M with a leaner tree beforehand). Futility pruning restored. Verified: 647/879 solved, EBF 4.609 @ sn=4M; 684/879 solved, EBF 3.995 @ 20s/move, 1cpu, 256m hash (typhoon_baseline.log). The counter-move table is still written and its stats still tracked (dynamic.c) for diagnostic purposes, but generate.c no longer reads it for move ordering, so it has no effect on search behavior in this commit. lmr_testing/ holds the in-flight graded-LMR + counter-move code (not applied here) with notes on what was already tried and measured, so a future session can resume without re-deriving it. --- src/lmr_testing/README.md | 73 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 src/lmr_testing/README.md (limited to 'src/lmr_testing/README.md') diff --git a/src/lmr_testing/README.md b/src/lmr_testing/README.md new file mode 100644 index 0000000..8ac983f --- /dev/null +++ b/src/lmr_testing/README.md @@ -0,0 +1,73 @@ +# In-flight LMR/counter-move work, stashed 2026-08-27 + +The main tree (`/usr/home/scott/typhoon/src`) was reverted to a clean +pre-LMR/pre-counter-move baseline (LMR=fixed -ONE_PLY history pruning, +futility restored, no counter-move scoring) so an overnight ECM baseline +run could establish ground truth (`typhoon_baseline.log` @ 20s/move, +`typhoon_baseline_ecm4m.log` @ sn=4M, both 1cpu/256m hash). + +This directory holds the exact bodies that were reverted, so they can be +re-applied on top of the (soon to be committed) clean baseline instead of +reconstructing from memory. + +## What's still intact in the main tree (never touched) + +- `dynamic.c`: `InitLMRTable()`, `g_iLMRQuietReduction` table population, + and the counter-move table write (`_NewCounterMove`, still runs and + updates `u64CounterMoveTries`/`u64CounterMoveHits` stats -- just + nothing reads `ctx->mvCounter` for move ordering/reduction anymore). +- `main.c`: still calls `InitLMRTable()`. +- `chess.h`: still has all struct fields (`mvCounter`, `fPvNode`, + `g_iLMRQuietReduction` extern, `GetLMRReduction` prototype, counter-move + bit flags, stats counters). No chess.h changes needed to restore LMR. + +## What needs restoring (saved in this directory) + +- `searchsup_GetLMRReduction.c` -- the graded-LMR body: Ethereal formula + (`0.7844 + ln(depth)*ln(moves)/2.4696`) + `ONE_PLY` base, soft + PV-adjacency discount (Crafty-style, 1 ply less instead of hard skip + when `ctx->sPlyInfo[ctx->uPly-1].fPvNode`), counter-move exemption + (added last, alongside killer exemptions), move-count threshold `> 3`, + fail-high gate `<= 10`. This is the *best validated* config from + yesterday's sweep: 24/30 solved, EBF 4.223 on `ecm_quick.ep_` @ sn=4M. + Drop this in to replace `GetLMRReduction` in `searchsup.c`. + +- `generate_counter_move_block.c` -- the three generate.c hunks: struct + decl (`sKillers[6]`, `mvLast`), the counter-move bonus pre-population + block, and the `s += sKillers[4]/[5]` scoring lines. See inline + `// LOCATION:` comments for where each piece goes. + +- `search_c_snippets.txt` -- the two one-line search.c changes: + `pi->fPvNode = (iBeta != iAlpha + 1);` (near `iInitialAlpha = iAlpha;`) + and the futility-pruning `FALSE &&` isolation-test disable (optional -- + only re-add if resuming the "isolate LMR's effect alone" testing + methodology; leave futility on to test LMR combined with it instead). + +## Known results/dead ends from yesterday's sweep (don't re-try blindly) + +See conversation history for full detail, but in brief, all measured on +`ecm_quick.ep_` @ sn=4M against this config's 24/30 EBF 4.223 baseline: +- Table-only (no `+ONE_PLY` base): 23/30, EBF 4.224 -- worse. +- Fail-high gate `<=5`: 24/30, EBF 4.274 -- worse. `<=20`: 23/30, EBF + 4.101 -- best EBF but costs a solve (same shape as several other + knobs -- EBF-vs-solve-count tradeoff, not a free win). +- Grandparent PV guard (uPly-2): 23/30, EBF 4.258 -- worse both ways. +- Obsidian formula (`0.99 + ln(d)*ln(m)/3.14`, table-alone): 23/30, EBF + 4.175 -- good EBF, costs a solve. +- "Improving" signal (Crafty/Berserk/SF-style, eval vs 2 plies ago), + tried with both `GetRoughEvalScore` (material-only past uPly 4) and a + real `Eval()` call: both measured identically worse, 23/30 EBF 4.252. + GetRoughEvalScore's material-only fallback deep in the tree was ruled + out as the cause since the real-Eval version scored the same. + +## The real methodology finding (more important than any single knob) + +ECM.016 case study: baseline's "stable" answer through depth 11 (`Rxc5`) +was actually a shallow, unconvicted pick -- at 24.5M+ nodes even the +baseline flips to `dxe3` and stays there (matches Crafty's own stable +depth-18-21 preference for `dxe3`). Full-ecm879 solve-count deltas from +sn=4M runs are contaminated by positions like this where neither config +actually understands the position yet. Before trusting any future +solve-count delta on a small suite, verify the "lost" positions are ones +where a long/deep baseline run is actually stable and correct -- that's +what tonight's overnight run is for (finding the "confident" ECM subset). -- cgit v1.3