Author: Gerd Isenberg
Date: 05:04:37 04/14/04
Hi All, Some thoughts about the recently discussed attack table stuff with or w/o bitboards (the still active "sliding attacks in three #define" thread). Are attack tables necessary or helpfull for (most) QNodes, cut nodes as well as all nodes? What about the general rule to calculate things as late as possible and to hope for an early return? Better to conditionally calculate things twice or more often in seldom cases (or to cache them for a while) instead of calculate things for nothing at most nodes. Most important for speed considerations are QNodes (draft <= 0). There are following conditions, that a QNode (not in check) becomes a terminal node, in the order of their occurrence and dependent on the design of the engine: 1. A repetion was found. 2. A hash hit inside window 3. recognizer hit 4. Lazy cutoffs LazyEval(if any) - SOMEMARGIN >= beta hashed eval >= beta 5. Eval >= beta Mate in one detected (by Eval) Real Stalemate, requires at least the "generation" of one legal move. 6. No (good) captures (or checks...) available Some further remarks on that points: 1. I guess repetition detection based on the hashvalue of the position is not used in all engines qsearch. Further i guess that the amount of returns is rather negligible, except some pathological cases. No need for attack tables here. 2. Even probing hash is not implemented in all engines qsearch due to a possible huge latency. Do we want to check whether the stored move is legal? If yes, an already generated or incremental updated attack table and pinned pieces may help - but it's like breaking a butterfly on a wheel. 3. Some small egtbs in ram and some rule based special ending knowledge, if implemented at all in qsearch. For the rule based knowledge, attack tables may help. 4. I guess this point is important (if some kind of lazy eval is implemeted)! No attack information is needed. Maybe pawneval hash probing or even eval hash probing is done. a) lazyScore - worstCasePositionalValue(previous nodes) >= beta In case of eval hash hit (may be combined with 2.): b) hashedEvalHitScore >= beta How often does a) occur? Specially what impact does futility pruning at frontier nodes and qnodes have on this kind of lazy eval cuts. b) is similar to 2 and may safe generating attack tables too. 5. It depends on your eval and heuristics to evaluate things more expensive and "accurate" than other "unimportant aspects". Parent node(s) and/or move to node may enable/disable some heuristics. In my current eval i have rare triggers based on previous node (most kingsafety). I aggregate attacks during the first eval run. Whether 5a or even 5b is worth to do, is questionable. Anyway i like it, and with huge kingeval the first is almost a waste product (not exactly :-) 6. With some appropriate bookholding one may first try some obvoius winning captures like PxQ, PxR, PxB or PxN, KxX, NxQ, NxR without the need of some sliding attack generation. OTOH having attacks and en prised pieces and doing SEE helps to prune a lot of captures in qsearch. Conclusion(?) There are a lot of cutnodes in qsearch, where (sliding) attack information is not necessary at all. Not a big issue for rotated lookups - but probably for incremental updated attacks or fill based attack generation. My point with fill based (kogge stone) attack generation from scratch, including pinned and enprise determination, is doing it before "huge" Eval and legal movegen, but after looking for lazy stuff. Did i miss something? Cheers, Gerd
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.