Author: Andrew Williams
Date: 03:35:03 03/01/01
Go up one level in this thread
On February 28, 2001 at 22:37:11, Scott Gasch wrote: >Hi all, > >I've really thought that attack tables were missing from my program for a while >now. I already spend a bunch of time in eval computing the control of squares >near the king as part of my king safety term. I also compute square control in >front of passers currently. > >So I am now considering keeping an incremental attack table as part of the >position structure and updating at MakeMove and UnmakeMove. The attack table >entry for a particular square will have info about the number of white/black >K/P/N/B/R/Qs that directly attack that square. This is going to slow me WAY >down, I understand. I will recoup some speed in routines like InCheck, SEE and >ControlsSquare, though... > >I hope to use the attack table for more than I currently do in eval. Terms like >control of center, bonus for placing pieces where they are protected, who >controls more of the total board etc... become possible. > >Before undertaking such a fundamental change to my program, though, I wondered >what advice others who may have tried this before might have for me... > >Thanks, >Scott I have incremental attack tables, but I started by calculating them from scratch on demand. I think it's best to start this way so that you have something you can compare with when you go incremental. My implementation just has one bit per piece on the board. So the table is made up of sixty-four 32-bit integers. If I want to know how many pieces of a certain type are attacking a square, I need to calculate that. I ended up using an array (bitcounts), which tells me how many bits are set and gives me a list of their positions for any sixteen bit number. I tried other methods for this, including some assembler, but this worked out best. To get the information I need, I grab the sixteen "white" bits or the sixteen "black" bits and use them as the index into bitcounts. For quite spectacular bugs, try grabbing the wrong sixteen bits. Another thing I'd consider keeping a version of make_move() which doesn't update the attack tables. Doing the incremental update is extremely slow in my program, yet there are many cases where I do make_move() but I don't need to update the tables (eg grabbing my PV from my hash table). Hope it works out. Andrew
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.