1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
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).
|
