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
74
75
76
77
78
79
80
81
82
83
84
85
86
|
Better understanding of stuff like KRKRB == drawish, Q's come off = !drawish
Pawnhash size tunable from cmdline again
Think about when to avoid nullmove pruning based on checks in the line
r2r4/p4pk1/2p3p1/1p1nPR2/5p1Q/2N5/PPPq4/1K4R1 w - - 0 0 -- check extension crazy
2026-09-17: search.c's extended futility pruning (VALUE_KNIGHT/VALUE_ROOK
gate, PREPARE_TO_TRY_MOVES) now folds in iImprovement + iPositional[side]
(the same per-tier p50 typical-value estimate QSearch's own futility gate
uses), but still uses one flat margin regardless of which Eval() exit tier
(PLY_INFO.uLastPositionalSource) produced iEval/iPositional at that node.
iPositional corrects for a tier's mean bias, not its spread -- a coarse
(super-lazy) read could carry more variance/tail risk than a fine one even
after mean-centering. Rather than a categorical "never prune from
super-lazy" rule (rejected as too blunt/magic-number-shaped -- iPositional
already replaces trust-by-category with trust-by-measured-bias), the
principled fix is a real EFP_BASE_MARGIN_BY_SOURCE[tier], calibrated the
same way as QSearch's FUTILITY_BASE_MARGIN_BY_SOURCE (CALIBRATE_QSEARCH_
FUTILITY-style harness: search the would-be-pruned move anyway, bucket
surprise rate by distance-short-of-bar AND uLastPositionalSource, check
whether the tiers actually need different margins here too). Not yet
built -- deferred behind self-play validation of today's iPositional/
futility-margin changes landing first.
2026-09-18: sharded ASSERT-fuzzing harness -- the technique that found
the CommonSearchInit PV-staleness bug (DEBUG binary + gdb, batch mode,
`script <shard>.ep_` at a shallow sd, let it run until either an
ASSERT/SIGSEGV or clean exit) generalizes well and should be run
routinely, not just once ad hoc. Shard tests/cross_sectional_200k.ep_
(or any large stratified pool) into N pieces and run N concurrent
DEBUG-build _typhoon processes under gdb, one per shard, each logging
to its own file; investigate any hit (assert message + gdb backtrace)
the same way this session did. Needs a full core budget (N cores) so
it collides with self-play match runs -- schedule it for whenever the
box isn't already saturated by match_play.py workers, not concurrently
with them.
2026-09-18: blunders.pgn review (typhoon vs Crafty losses).
2026-09-18: consider adding cLikelyUnstoppablePasser to the POSITION
structure and using it to extend searches. Just like we already do
with cTrapped and cEnprise -- signals from eval.c to affect search.
2026-10-01: It seems like a Q vs RR in a pawnful endgame... Q dominates.
In general, we should work on encouraging the engine to maintain a good
pawn structure -- read more of that pawn power in chess book. Work on
the pawn eval specifically. Maybe do eval learning on only the pawn
hashed eval terms.
2026-10-04: We need to go faster.
- Can we get rid of rgSquares[] completely and use bitboards everywhere?
- Eliminate SEE calls?
- profile a super-lazy-always (material-only Eval() exit, forced
unconditionally, throwaway diagnostic build a la the zero-
selection-budget move-ordering trick -- never commit it) binary
against Crafty at matched depth/positions to find out where our
nps actually goes once eval is ~free. Scott's educated guess is
SEE and the is-this-move-a-check / legal-reply-to-check generators
dominate once eval is out of the way, not eval itself -- also
suspect given the earlier `<=`-to-`<` SEE-skip experiment on line
~4178 (skip SEE on same-piece- for-same-piece captures) barely
changed speed but made trees fatter (more nodes needed), i.e. that
SEE call was doing real pruning work, not just costing
time. Before assuming check-detection costs are irreducible,
confirm "is this move a check" is answered via O(1) bitboard AND
against the enemy king square from the post-move attack bitboard,
not via a generate-and-filter pass -- Scott believes he already
does this "cheaply" but isn't sure it's the fastest available
method. Single-legal-reply-to- check detection is likely the
genuinely unavoidable cost of the three (needs a real legal-move
count in the child position) -- worth checking whether it
early-exits as soon as a 2nd legal move is found rather than
generating the full list.
2026-10-04: Reign in extensions the make the tree smaller.
2026-10-04: Modify self-play harness to record eval score / PVs per
move in the PGN output. Make self-play harness able to play crafty
and then test the HEAD/candidate against crafty.
Eval term for connected passers vs. rooks. Or 2+ passers vs. rooks.
Poor king play -- tell it to support own passers or blockade enemy
passers once king activity phase starts.
|
