Author: Mridul Muralidharan
Date: 08:17:49 03/23/04
Go up one level in this thread
On March 23, 2004 at 10:04:42, Uri Blass wrote: >On March 23, 2004 at 09:44:42, Mridul Muralidharan wrote: > >>On March 23, 2004 at 04:42:31, Uri Blass wrote: >> >>>On March 23, 2004 at 02:00:13, Mridul Muralidharan wrote: >>> >>>>On March 22, 2004 at 19:30:35, Anthony Cozzie wrote: >>>> >>>>>On March 22, 2004 at 17:18:49, Dann Corbit wrote: >>>>> >>>>>>On March 22, 2004 at 16:18:19, Anthony Cozzie wrote: >>>>>> >>>>>>>On March 22, 2004 at 03:40:57, Daniel Shawul wrote: >>>>>>> >>>>>>>>Hello >>>>>>>> >>>>>>>>I have decided to use attack tables. I just did >>>>>>>>a rough implementation of it at the beginning of the eval >>>>>>>>according to Ed's paper. The problem is the thing dropped the nodecount >>>>>>>>by almost 40% . Initial position nodecount was 800000 and now it is 500000. >>>>>>>>Do incremental move attack tables help? And how do i update the table? It seems >>>>>>>>very difficult to update a sliding move and other special cases. >>>>>>>> >>>>>>>>thanks >>>>>>>>daniel >>>>>>> >>>>>>>I have some code for incremental attack tables if you want it. However, it took >>>>>>>Tord 4 months to figure out :) I don't use attack tables in Zappa; i wrote this >>>>>>>when i was considering switching to a piecelist based engine. >>>>>> >>>>>>Is your code 0x88 or bitboard based? >>>>> >>>>>board[64]. Its based on Vincent's move generator. >>>>> >>>>>anthony >>>> >>>>Hi Anthony, >>>> >>>> I had done an incremental attacktable but was not quiet sucessful with it - it >>>>was almost same speed as the previous one : and so removed - potential for more >>>>bugs (kiss). >>> >>>I am very surprised to read it because my attack table was extremely slow and >>>this is the reason that I worked months on updating them incrementally. >>> >>>Calculating the directions that every square is attacked by white and black >>>from scratch is very expensive. >>> >>>It means doing a loop on all squares of the board after every move and for every >>>square doing a loop on all directions to see the direction that it is attacked >>>and the square of the attacker from every direction. >>> >>>Uri >> >>As I had already opsted in this forum , my attacktable generator is based on >>Vincent's move generator - and there are other optimisations possible with it >>that has not been presented in his post. >>And , I am not a bitboarder - and follow a board structure which is quiet >>similar to GNUChess 4. >>This makes it not that expensive - but still quiet expensive :( >> >>Mridul > >I am also not a bitboarder and my attack tables is not based on bitboards. > >I have 32 bit numbers that tell me the direction that every square is >attacked(16 possible directions from white and 16 possible direction from >black). > >64*16 array is needed to give the square of the attacker based on the attacked >square and the direction when this information is relevant only after finding >that a square is attacked from a specific direction(otherwise the value of the >64*16 array is not used so I do not need to care if it is wrong). > >I started by not having piece list so I needed to do loop on all squares and all >directions so it was very slow(of course piece list could improve the speed >but I implemented it only after I already have incremental move generator so I >really do not know right comparison between incremental move generator and not >incremental when I do loop on all the pieces and update the attack tables based >on the attacked square of every piece). > >Uri Yes , I can see why incremental could possibly be fast for you ... for me it was almost breakeven in my last attempt. And so , I ditched it (after writing and debugging for 1+ month :( ) It has potential for more bugs .... And it was an already buggy engine !! Mridul
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.