|
Confirmed self-play regression traced to a stale test_vs_head.sh reference
binary (typhoon_allbitboards/550ea81, deleted): every "vs head" comparison
since 92fc412 (Sep 4) was checking new work against that fixed Sep-4
snapshot, never against real HEAD or the working tree. Rebuilt clean
reference binaries directly from git and re-verified everything from
scratch.
This commit lands only the pieces confirmed safe against clean 434fa04
(fast st1 match, ~30-40 games, score ~0.44-0.55, consistent with parity;
plus a DEBUG-build smoke test pass):
- recogn.c, fen.c: real bugfixes
- data.c, draw.c, ics.c: whitespace only
- x64.asm: retires the asm GetAttacks implementation now that chess.h's
GetAttacks macro unconditionally selects the already-verified-faster
_GetAttacksBB bitboard version instead of a three-way build-flag
toggle (GETATTACKS_BITBOARD/CROUTINES/asm default)
- see.c, testsee.c: SEE/test-harness updates supporting that default
- root.c: per-tier eval-exit reporting (super-lazy counters currently
always read 0 -- accurate, since no super-lazy exit exists yet)
- main.c: startup banner update, InitEval() call, TestRecogn() added to
the #ifdef TEST self-test sequence
- command.c: InitEval() DNA-reload hook, new qsearchfutility diagnostic
- dynamic.c: minor changes
- chess.h: the GetAttacks default change above, three
FUTILITY_BASE_MARGIN_* compatibility aliases (all still equal to the
original flat FUTILITY_BASE_MARGIN -- search.c has not been split into
per-tier margins here), placeholder super-lazy counters, and an
EvalPasserRaces -> _EvalPasserRacesAgainstLoneKings rename (confirmed
byte-identical body) to match recogn.c's call site
- eval.c: the same rename, plus a no-op InitEval() stub (nothing to
initialize until the ROOK_FULL_HALF_OPEN_BONUS cache below exists)
Deliberately NOT included: the full eval.c overhaul (~1770 lines) and
search.c's qsearch-futility rework (~650 lines), including yesterday's
loosened SUPER_LAZY_MARGIN_BY_ARMY/FUTILITY_BASE_MARGIN_BY_SOURCE tables.
Reverting just those two tables while keeping the rest of the eval.c
overhaul still lost badly to 434fa04 (0.20 over 10 games), so the
regression isn't fully explained by the margins alone -- the eval.c
overhaul needs careful, incremental re-verification against this commit
as the new baseline, not a bulk re-apply. Full original work preserved in
git stash (stash@{0} as of this commit) for that follow-up.
Note: two pre-existing, position/state-dependent assertion crashes were
found during this verification (util.c:1093 WalkPV, recogn.c:1359
_SanityCheckRecognizers), both reproducing on unmodified 434fa04 -- not
introduced by anything here, not yet root-caused.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Ka9o3S2eKqh4jNfmxVZ6fH
|
|
Search()'s Dieter-Brusser hash-hit-leads-to-draw check only verified
that a score of 0 would clear the same alpha/beta bound as the stored
iScore -- it didn't establish that iScore itself was accurate. Since
playing the hash move actually produces a draw, propagate the draw
score upward instead of the stale score computed along a different,
non-repeating path.
While fixing this, centralized every other place that returned a
literal 0 for a draw (search.c's stalemate leaf, searchsup.c's
QSearch draw leaf, probe.c's EGTB draw case, which had a dead
`// g_iDrawValue[...]` comment suggesting this was intended all
along) into a single g_iDrawScore[2] global in draw.c, declared in
chess.h. It's indexed by side to move rather than a scalar so a
future contempt-factor tweak can bias the draw score per color
without touching every call site again; both entries are currently 0,
so behavior is unchanged except for the hash-hit bugfix above.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012e2SaEaQ27JJq1D3wCqryr
|
