Author: Uri Blass
Date: 07:04:42 03/23/04
Go up one level in this thread
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
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.