Author: Gerd Isenberg
Date: 06:13:29 05/05/04
Go up one level in this thread
On May 05, 2004 at 07:37:06, Vincent Diepeveen wrote: >On May 05, 2004 at 06:52:06, Gerd Isenberg wrote: > >>On May 05, 2004 at 03:03:15, Daniel Shawul wrote: >> >>>Hello >>> >>>Is incremental attack table slower than creating them on fly? >>>I have both versions working properly right now but the incremental >>>one further drops NPS by 30% , though InCheck and Checks are for free in this >>>case. Anybody have similar experience? I am sure i have made no mistake in >>>updating because i checked it with the known perft positions and node count is >>>perfect. >>> >>>best >>>daniel >> >> >>Incremental attack table update in one stage has probably (depending on your >>design and structures) the drawback, that it is done in make/unmake, even if >>those moves result in "lazy" (leaf) nodes, where most attack information is not >>needed at all. > >Gerd, Note that >for lazy eval you do not need to do an expensive makemove + function call in >your qsearch to lazy eval a node. You can do it the ply before, even before >making the move. So you save out 3 expensive function calls to lazy eval. Yes, that's correct. Pruning before calling qsearch (score + gain(move) + margin <= alfa) versus lazy eval and beta cut. The goal is to avoid or minimize not necessary work. Gerd > >> >>Another aspect with incremental attacks is that the amount of work depends on >>the number of squares with changed controls. So IMHO programs that do >>incremental attack generation probably become relative weaker in some endings >>with sliding pieces. >> >>Gerd
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.