Selected Goodies of DarkThought

1. Selected Goodies of DarkThought Ernst A. Heinz M.I.T. Laboratory for Computer Science (until June 2001) <heinz @ supertech.lcs.mit.edu> <heinz @ mit.edu>

2. Overview • Previously Published Specialties • More on Material Signatures • Caching and Hash-Table Tricks • Details of Search Extensions • Top-level Search Specifics

3. Previously Published Specialties • Adaptive Null-Move Pruning (1999) (reduction factor R varies with search depth and material) • Extd. Futility Pruning, Limited Razoring (1998) (static forward pruning at pre- and pre-pre-frontier nodes) • Efficient Interior-Node Recognition (1998) (material signatures, perfect endgame knowledge) • Knowledgeable Endgame Databases (1999) (in RAM, a-priori knowledge for compression & indexing)

4. Material Signatures (I) • bit vectors of available piece types (Q R B N P = 010112R+N+P yes, but no Q or B) • versatile abstraction of material balance • excellent for table indexing (e.g. evaluation) • for other “knowledge questions” too (m_sig & X == Xtest signature for presence of X)

5. Material Signatures (II) • efficient MVV/LVA capture generation a0_sig = mat_sig(side); v_sig = mat_sig(opponent); while ((mvv = MVV_clear(&v_sig)) != 0) { a_sig = a0_sig; while ((lva=LVA_clear(&a_sig)) != 0) { gen_caps(mvv, lva, &caps, &dead); if (dead) clear_bit(a0_sig, lva); }}

6. King+Pawn Evaluation Caching • separate tables for P and K+P standard (1x P, 1x bK+P, 1x wK+P  3x accesses, 3x hash locks) • idea: embed table for P in those of K+P (pros: less accesses and less “wasted” space for hash locks, cons: lower hash efficiency for pure P accesses) • trick: also use pure P hash key in K+P (retains hash efficiency of P accesses despite K+P misses)

7. Other Hash-Table Tricks • store static evaluation scores in TT • maintain additional evaluation cache (hit rates poor in middlegames, good in endgames, use full hash key as index and simply overwrite for replacement) • save mate-threat and single legal move information in TT (for efficient move generation and extensions later on)

8. Details of Search Extensions (I) • disabled in upper tree to prevent search blow-up: • check extensions in single major-piece endgames • mate-threat extensions (except for single-reply nodes) • disabled in whole tree to prevent search blow-up: • check ext. in Pawn and single minor-piece endgames • enabled near horizon to cope with null-move failures: • direct mate-threat extensions if defending side has great material advantage while opponent pieces still dangerous

9. Details of Search Extensions (II) • various different Pawn extensions: • all Pawn moves to 7th / 2nd rank (captures and pushes) • attacks on two enemy Pawns on 7th / 2nd in Pawn endings • midgame pushes attacking Pawns in enemy King shield • sophisticated passed-Pawn extensions: • pushes to 6th / 3rd rank in endings or near search horizon • pushes and some (all) captures to 5th+6th / 3rd+4th rank in (very) late endings (at most one piece  very late game)

10. Top-level Search Specifics • extensive static root analysis (“oracle” with automatic management of all hash tables) • true-value searches in first 2 iterations ( good initial aspiration window and hash fill, speed OK) • PVS with lazy alpha-bounding and narrow aspiration window (about 0.25 Pawns)

11. Top-level Alpha Bounding • direct resolution of new best moves not necessary (resolve bound only after next MWS fails high) • lazy  resolve by single researches and delay top-level failures also across iterations • time-controlled  if remaining search time less than 0.3*target time, resolve directly, otherwise allocate more time to finish “shaky” iteration (resolution delay across iterations acts like a PV extension)

12. Epilogue • Countless treasures wait to be unearthed in each and every single game-playing program. Please, everybody, publish them !!!