Author: Bert van den Bosch
Date: 06:03:21 10/18/05
Go up one level in this thread
On October 18, 2005 at 07:01:26, Volker Böhm wrote: >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 Hi Volker. In qsearch usually programs do (if val > beta do cutoff) as stand pat. So when I am in qsearch I can see in the attack tables if this condition is satisfied one ply earlier, so to speak I don't go into qsearch, I can use the attacktables to get the board value + the piece hitted, and check if eval would create a beta cutoff if I would indeed go into the qsearch. What I mean is I have two ways of making moves, makemove which generates all moves for attacktable and makeshallowmove which simply makes hits and puts the offsetboard right. Then I use makeshallowmove to get an eval of the position, in order to profit of the fact I do a lot of work in all the makemove 's. I also use an incremental undo. Actually I have two functions Insertpiece and Removepiece which handle all incremental attacktable updates. Makemove and Undomove simply make use of these two functions. I have a two dimensional array [64][15] which keeps track on where the field is attacked from. So I have a lot of information, and also I have implemented in SEE when two rooks are on one line and a queen and bishop are on one line. It is indeed costly when the queen moves, so I was thinking on generating inexpensive moves before the costly ones, but I don't take that into account yet. Using the SEE I have accounts to a very good move ordering with which I am quite happy. It was a lot of work though when I started making all the exceptions in move generation, pieces being uncovered etc. Most annoying were the pawns though, but when I got a error free (efficient I hope) implementation the fun could go on. greetings Bert
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.