Author: Uri Blass
Date: 12:58:58 01/20/03
Go up one level in this thread
On January 20, 2003 at 00:15:31, Scott Gasch wrote: >Hi all, > >I'm pondering a major code overhaul of the engine to implement some ideas I've >been thinking about for a while. One of these is attack tables. So I wanted to >seek the advice of those of you who have attack tables in your engines already. > >First, I assume attack tables are things you want to do incrementally. This >seems really expensive though -- not only do you have to update the squares >attacked by the moving piece but also you have to look for attacks exposed by >the vacated square and attacks blocked by the destination square. I'm not >missing any more clever way to handle this incrementally am I? > >Next, on Ed's page he talks a little about attack tables in Rebel. He said he >generates them non-incrementally (in eval from scratch) and he says he only uses >a few bits per side. Like a single P, N, B, R, Q, K bit and a count. I wonder >why not burn a few extra bits and have P, P, N, N, B, R, R, Q, K (10 total): it >would make the square control lookup table much more accurate and not too big (I >get 1M entries)? > >Any feedback / advice appreciated. >Scott 1)Ed used it when the hardware was slow so even 1M table may be too big at that time. 2)Ed already use 16 bits(8 per side) What do you exactly suggest? If you use instead of 1 bit 3 bits for bishop and knights you already have 10 bits per side If you use instead of 1 boit per rook 2 bits per rook you have 11 per side. and 2 bits per pawns instead of one give you 12 bits per side that means 24 bits 2^24=16M 3)I am afraid that using a big table often may do the program slower. Uri
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.