| Age | Commit message (Collapse) | Author |
|---|
|
a stale king-safety data bug found along the way.
The Texel/coordinate-descent auto-tuning pass (started at 29d73f4) left
several eval terms with non-monotonic or outright sign-flipped values
that several ASSERTs had to be silently commented out to tolerate
(e.g. BACKWARD_SHIELDED_BY_LOCATION scoring a structural pawn defect as
a +12..+17 bonus on most squares, PASSER_BONUS_AS_MATERIAL_COMES_OFF
staying flat until the defending side was down to almost nothing).
Restored all 54 differing constant tables to their last hand-tuned
values (commit df8facc, pre-dating 29d73f4) mechanically -- table
names/shapes are identical between the two commits, only values
differ, so this is a pure data restore with none of the surrounding
code-structure changes since df8facc reverted.
Also fixes a real bug found while investigating: pos->uPiecesPointingAtKing[]
was only refreshed inside EstimatePositionalScore's lazy-eval-margin
path (eval.c ~5648), but _EvalKing reads it unconditionally on every
full eval. Whenever a node's cheap material+pawn score wasn't close
enough to the alpha/beta window to trigger that lazy-margin branch, the
full eval proceeded straight to _EvalKing using a stale
uPiecesPointingAtKing value left over from a prior, unrelated node --
silent, intermittent noise in king-safety scoring on an unpredictable
subset of evaluations. Introduced 2026-08-24/26 (29d73f4, 7857096), so
it predates and was baked into the Texel tuning pass being reverted
here. Fixed by computing it once in an else branch when the lazy-margin
path isn't taken, so it's refreshed exactly once per full eval either
way (this is the innermost eval loop, so avoided doubling the cost on
the branch that already computes it).
sd10/sn5m results across the three curated suites (vs. head_reference,
the prior Texel-tuned HEAD):
sd10: ringers 9/11 (was 10), confident 85/90 (was 88), hard 23/90 (was 17) -- total 117 vs 115
sn5m: ringers 11/11 (was 10), confident 87/90 (was 89), hard 14/90 (was 13) -- total 112 vs 112
Net win at sd10, wash at sn5m, in both cases with a large swing toward
ecm_hard_quick -- consistent with hand-tuned values being more
internally coherent (monotonic curves, no sign flips, no double-counted
whole-position aggregates layered on top of already-summed per-item
terms) even though they were never retuned against this specific suite
or these specific opponents.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01M9ZDiJhiUajUxh95mTXCFJ
|
|
Finishes work left half-done in 7857096 ("Replace ctx->uPositional with
a data-calibrated Eval() return value"): that commit added Eval()'s new
piPositional out-param but never migrated GetRoughEvalScore onto it, so
GetRoughEvalScore's mid/deep-tree fallback kept reading the old
ctx->uPositional field -- a per-thread EWMA written only on full-eval
calls and never touched by the (far more common) lazy-eval path, so it
carried a stale value from whatever unrelated position last triggered a
full eval, potentially many nodes/plies away. Combined with EVAL_HASH
being long since disabled (its probe branch already dead), every
GetRoughEvalScore call past ply 4 was effectively "material + garbage."
Fixed by having GetRoughEvalScore just call Eval() directly -- its own
lazy-exit machinery already is the cheap, calibrated estimate this
function exists to provide, so there's no separate estimator to
maintain. Removed ctx->uPositional entirely (struct field, its EWMA
update in eval.c, both root.c init sites, split.c's cross-split
propagation, testeval.c's reset) along with the entire EVAL_HASH
subsystem (struct, table, Probe/StoreEvalHash, main.c's now-dead
reporting branch, the GNUmakefile flag) -- confirmed unused elsewhere
and explicitly being cut for good, not coming back in this form.
Also fixed GetRoughEvalScore's prototype being wrongly declared inside
#ifdef EVAL_HASH in chess.h even though the function itself is defined
and called unconditionally -- this was the source of the recurring
"call to undeclared function 'GetRoughEvalScore'" implicit-declaration
warning seen throughout this session's builds.
Separately, fixed QSearch to match its own documented intent: the
en-prise/trapped-piece "don't let this side stand pat" check now only
fires if the side hasn't already been allowed to stand pat earlier in
this qsearch line (matching the comment above it, which already said
this but the code never implemented it).
Verified against baseline/typhoon_baseline (pristine, pre-session) on
ecm_ringers.ep_ (4), ecm_hard_quick.ep_ (50-sample), and
ecm_confident_quick.ep_ (40) at sn=5M, --cpus 1, book disabled:
pristine baseline solves 3/50 on the hard sample; this commit solves
6/50, with the stand-pat fix and GetRoughEvalScore fix each
contributing +1 independently confirmed. No regressions on the other
two suites (4/4 and 40/40 unchanged throughout).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01YGSMkwjqiCk4XhbfN7ugD2
|
|
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.
|
|
uPositional was a per-thread EWMA of abs(material - true score) used to
size lazy-eval and futility margins. It was history-derived (reflecting
whatever recent, unrelated positions looked like) rather than derived
from the position actually being margined, and its update/consumption
was tangled with EVAL_HASH (now disabled).
Eval() now takes an optional SCORE *piPositional out-param and fills it
in on every return path: exact (abs(material-delta)) on a full eval,
or an estimate from a new EstimatePositionalScore() on a lazy exit.
EstimatePositionalScore()'s two terms (king-safety-defect-bucketed, and
a flat residual for mobility/passers/everything else) are calibrated
from ~1.6M measured full-eval samples (p90 of the actual swing), not
guessed -- an initial guessed version measurably regressed ECM solve
rate (630 vs a 650 baseline at sn=4M); the recalibrated version is back
at parity (649/879).
search.c's qsearch futility now reads the value Eval() just computed
instead of the stale/shared ctx field. Also removes QSearchInDangerNoStandPat
and SideCanStandPat, dead since the danger-hash check that fed them was
already commented out (e08387a) -- they depended on the same enprise/
trapped-piece data this conversation is about to move off of
g_PositionHash entirely.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
|
|
|
|
|
|
it found)
|
|
|
