Author: Volker Böhm
Date: 04:01:26 10/18/05
Go up one level in this thread
I am using attacktables in Spike that are generated incrementally too. Bert: What do you mean by "Also I use it to quickly see cutoffs one ply ahead in qsearch"? My experiences with incrementally attacktables: Incremental build of attack tables is 3-5 times faster that building it fully every move. It depends most upon the position of the queen, as a queen move is extremely expensive. I discovered too, that it is less expensive to incrementally undo a move from an attacktable than to copy the attacktable before every change and to undo it by using the copy. You have to store informations about the attack-direction for a fast implementation of incremental attack-tables, else you cannot compute exposed pices efficiently. In Spike we are using 24 bit for every field. 16 bits are containing the attack signatures (which pieces are attacking the field) and 8 bits are containing attack direction informations. The only problem I have left with incremental attack -tables are pieces that are attacking indirectly, example tow rooks in a row attacking a field. Our current implementation does not know that the second rook is attacking the field too. In a full generated attack table I would have handled this case correctly (in effect IceSpell had this implementation). Greetings Volker
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.