Author: Robert Hyatt
Date: 21:45:35 03/09/03
Go up one level in this thread
On March 09, 2003 at 02:42:00, Peter McKenzie wrote: >On March 09, 2003 at 01:14:12, Robert Hyatt wrote: > >>On March 09, 2003 at 00:35:49, Uri Blass wrote: >> >>>On March 08, 2003 at 23:34:35, Robert Hyatt wrote: >>> >>>>On March 08, 2003 at 12:05:59, Russell Reagan wrote: >>>> >>>>>On March 08, 2003 at 09:41:18, Robert Hyatt wrote: >>>>> >>>>>>Sure you can. You can evaluate all the pawn-only stuff, and then you can >>>>>>pre-cmpute whatever you need such as passed pawn locations, weak pawn locations, >>>>>>weak square locations, open file locations, half-open-file locations, and so >>>>>>forth. You stuff that in the pawn hash table, and then use it when you evaluate >>>>>>pieces to get the "coordination". >>>>> >>>>>I wonder if it would be faster (or reasonable) to keep track of this stuff >>>>>incrementally. For example, from the starting position, you know that if a pawn >>>>>makes a capture, or is captured, then that file is half open. So you can keep >>>>>track of how many captures have been made to or from a file, and keep track of >>>>>isolated pawns that way. I guess using a pawn hash would still be faster or more >>>>>generally useful, and as with all things incrementally updated, you do some >>>>>wasted updating computations where you may not use it. >>>> >>>> >>>>This is a tough thing to figure out. IE incremental updates cost something. >>>>You hope it costs less than computing from scratch, which it generally does if >>>>done well. But if you start to search pretty deeply, then the payoff drops >>>>off quickly, as you keep re-updating the incremental stuff multiple times >>>>before you use it once when you reach the tips. >>> >>>1)It is the case only if you do not evaluate every node and there are programs >>>that do it >>>Rebel does it and movei also does it. >>> >>>Rebel does not do incremental evaluation but the reason is not that it is >>>impossible to do it but the fact that Ed found it difficult to do it without >>>bugs. >>> >>>2)The original question was about comparing incremental updating to pawn hash >>>tables. >>>I assume that for pawn structure, hash tables are faster because you may get >>>almost 100% hits. >>> >>>Uri >> >>Yep. Even with a hash size of _one_, you can get decent results, because > >Thats something I'd never considered before but its a pretty cool observation! > >On the general question of pawn hash tables, I'm with you Bob. Very useful, >very cheap, very fast, a rare combination in computer chess! > That is the basis for the small trick you see in my evaluation code. I simply save the last "pawn hash signature" and when I enter evaluate(), if the new pawn hash signature is the same, I just grab the last score and use it as the right values are in the current pawn hash record without even probing the pawn hash table again. Saves copying from pawn hash table into the current data, since it is the same if the signatures are the same. >>the same pawn structure happens in successive positions many times.
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.