From 1216f4e159af037a32323aa7c942e64fcecafb05 Mon Sep 17 00:00:00 2001 From: Scott Gasch Date: Sat, 5 Sep 2026 10:01:41 -0700 Subject: Queen attack/mobility: bitboard rewrite (two-pass rook/bishop lookups); fix rook/bishop mobility to credit squares beyond a battery partner _EvalQueen's mobility ray-walk and QMobCaseTable switch replaced with two passes of the same unified chain-walk technique rook/bishop use -- _RookAttacksBB for the orthogonal-direction pass, _BishopAttacksBB for the diagonal-direction pass (MOVEGEN_MIGRATION.md/EVAL.md already established a combined 8-ray table measures slower than reusing the rook/bishop tables separately, per the stashed first bitboard-eval attempt's _EvalQueenOccupancyBB PoC -- reused that structure instead of rediscovering the regression). Continue-set per pass: friendly queen in both, friendly rook only in the rook-direction pass, friendly bishop only in the bishop-direction pass -- QMOB_FRIEND_ROOK/_BISHOP's old fOrthogonalRay flag is entirely subsumed by which lookup a blocker shows up in. Queen never x-rays through any enemy piece (unlike rook/bishop), so each pass's continue-set has no enemy side. Adds pos->bbQueenAttacks[2]/bbQueenXrayAttacks[2] and the corresponding _IsSquareAttackedByQueen/_IsSquareXrayedByQueen transitional helpers (DEBUG-cross-checked against an independent mailbox walk, same pattern as the rook/minor helpers), with _WhoControlsSquareFast and _EvalKing's bvAttack/bvXray/bvDefend/uQueenNearKing computations updated to read them instead of the old per-square bvAttacks bits queen no longer writes. Also fixes a real, previously-unnoticed fidelity gap in the already-committed rook and bishop conversions: the old mailbox walk doesn't just x-ray past a friendly battery partner (or, for rook/ bishop specifically, an x-rayable enemy queen/king) for attack-bit purposes -- it keeps walking and keeps crediting *mobility* for whatever safe/empty squares and further captures lie beyond, however many such blockers are stacked on one ray. The originally-committed bitboard versions only ever computed mobility from the near side (up to the first blocker via the magic lookup) and treated the chain purely as an attack-bit population exercise. Caught by direct comparison against the pre-conversion mailbox binary on battery positions (rook: two same-color rooks on an open file, old code credited 13 mobility to one rook via squares beyond its companion vs. 9 for the near-side-only bitboard version; bishop: two same-color bishops on one diagonal, 12/8 old vs. 11/5 near-side-only). Fixed by merging each piece's mobility and x-ray-population computation into a single chain-walk that credits mobility at every layer, not just the first -- queen's own conversion was written with this fix in from the start and verified against the same kind of battery position (two queens on a file, queen+rook, queen+bishop) before landing. Verified via precommit_check.sh (self-test + DEBUG smoke test, several hand-built multi-piece-battery positions run directly against a DEBUG binary to exercise the new cross-checks) after each step. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01XxmVi2sTMwpPp4i6WYFjan --- src/chess.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'src/chess.h') diff --git a/src/chess.h b/src/chess.h index 421667f..6b09840 100755 --- a/src/chess.h +++ b/src/chess.h @@ -752,6 +752,24 @@ typedef struct _POSITION BITBOARD bbRookAttacks[2]; BITBOARD bbRookXrayAttacks[2]; + // Queen's turn to convert (board_representation/EVAL.md section + // 9, 2026-09-05): "which squares does this side's queen(s) + // attack," ORed in from the two-pass rook-direction/bishop- + // direction magic lookups _EvalQueen's mobility computation + // already needs (MOVEGEN_MIGRATION.md's own already-tested + // "combined 8-ray table measured slower than reusing the + // rook/bishop tables in two passes" finding -- reuse that + // structure here too). bbQueenXrayAttacks mirrors + // bbRookXrayAttacks/bbMinorXrayAttacks: squares seen past a + // friendly queen/rook/bishop battery partner, chained arbitrarily + // deep like rook's (not single-hop like bishop's original cut) -- + // queen's own case table never x-rays past an enemy piece (unlike + // rook/bishop), only through friendly battery partners. King + // hasn't converted yet and still writes its own bits into the old + // bvAttacks structure. + BITBOARD bbQueenAttacks[2]; + BITBOARD bbQueenXrayAttacks[2]; + ULONG uWhiteSqBishopCount[2]; // num bishops on white squares SCORE iMaterialBalance[2]; // material balance -- cgit v1.3