From 9e995e7c39a83ae9b5ba86f3346e0281744bf773 Mon Sep 17 00:00:00 2001 From: Scott Gasch Date: Sat, 5 Sep 2026 21:52:40 -0700 Subject: King-safety recalibration, lazy-eval material floor, eval hot-path trimming Recalibrate iKingSwingP90 against the bitboard-rewritten CountKingSafetyDefects (~1.28B samples via new CALIBRATE_POSITIONAL/ CALIBRATE_BASE_MARGIN/CALIBRATE_MARGIN_SAFETY diagnostic build flags, board_representation/EVAL.md section 9). Add LAZY_EVAL_MIN_MATERIAL: measured the regular lazy exit's real swing exceeding its own assumed margin 20.6% of the time in near-bare-king endgames (vs <=0.36% elsewhere) -- skip lazy eval entirely below that material floor. Double the stale search.c/searchsup.c CountKingSafetyDefects extension thresholds as a stopgap pending their own recalibration. Eval hot-path trimming (measured via EVAL_TIME, ~1759 -> ~1386 avg cycles/eval on a representative middlegame position): - Pull _GetFileStormDefects out of EstimatePositionalScore's hot path (cost more than the "cheap cached lookup" it was assumed to be, running on ~90% of all Eval() calls). - Add pos->bbOccupiedSide[2], incrementally maintained alongside bbOccupied, so _BuildFriendlySideBB is a field read instead of a 6-term OR. - Switch CoorFromBitBoardRank8ToRank1/Rank1ToRank8 to the existing static-inline FastFirstBit/FastLastBit (same bsf/bsr instruction, no call/ret overhead). - Defer EvalPasserRaces' uRacerDist/fDontCountMeOut past its no-passer early return. - Remove the mailbox-era "max mobility in a row" term from _EvalBishop/_EvalRook (no bitboard-mobility equivalent need for it). - Simplify _EvalBishopPairs and rook file-openness/passer bonuses to flat DNA-tunable constants instead of distance/pawn-count-scaled tables, rook file-openness now a branchless bitboard-indexed lookup. - Remove pos->cPiece (write-only, no reader anywhere). - Collapse WHITE/BLACK mirror-branches (castle-rights block, rook-trapped-in-corner) to color-indexed constants. - Close the PAWN_BIT..KING_BIT gap (bits 7-3 -> bits 4-0), removing the bvPattern >>= 3 before its KING_COUNTER_BY_ATTACK_PATTERN lookup. This also fixes a real bug introduced earlier this session when _WhoControlsSquareFast was converted to read these constants directly: g_SwapTable is only [32][32], but the old bit values (up to 0xF8) indexed far out of bounds on any attacked square -- data.c's InitializeSwapTable was always built assuming the bits 0-4 range this change now actually produces. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01XxmVi2sTMwpPp4i6WYFjan --- src/board.c | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'src/board.c') diff --git a/src/board.c b/src/board.c index 814b045..9ed2f03 100755 --- a/src/board.c +++ b/src/board.c @@ -171,6 +171,7 @@ Return value: "bbPieces bitboard doesn't match piece list", "bbPawns bitboard doesn't match pawn list", "bbOccupied bitboard doesn't match piece list", + "bbOccupiedSide bitboard doesn't match piece list", }; ULONG u, v; COOR c; @@ -181,6 +182,7 @@ Return value: BITBOARD bbPieces[2][8]; BITBOARD bbPawns[2]; BITBOARD bbOccupied = 0; + BITBOARD bbOccupiedSide[2] = {0, 0}; ULONG uSigmaNonPawnCount[2] = {0, 0}; ULONG uWhiteSqBishopCount[2] = {0, 0}; UINT64 u64Computed; @@ -275,6 +277,7 @@ Return value: uPawnCount[u]++; bbPawns[u] |= COOR_TO_BB(c); bbOccupied |= COOR_TO_BB(c); + bbOccupiedSide[u] |= COOR_TO_BB(c); } } @@ -320,6 +323,7 @@ Return value: bbPieces[u][PIECE_TYPE(p)] |= COOR_TO_BB(c); } bbOccupied |= COOR_TO_BB(c); + bbOccupiedSide[u] |= COOR_TO_BB(c); uNonPawnMaterial[u] += PIECE_VALUE(p); if ((IS_BISHOP(p)) && (IS_WHITE_SQUARE_COOR(c))) @@ -404,6 +408,13 @@ Return value: goto end; } + if ((pos->bbOccupiedSide[WHITE] != bbOccupiedSide[WHITE]) || + (pos->bbOccupiedSide[BLACK] != bbOccupiedSide[BLACK])) + { + uReason = 24; + goto end; + } + // // Now walk the actual board and reduce the material counts we got // by walking the piece lists. If everything is ok then the -- cgit v1.3