Author: Tom Likens
Date: 17:56:06 12/28/03
Go up one level in this thread
On December 28, 2003 at 20:01:36, Geoff wrote: >Hello Tom > >>So far the results have been exciting, but also potentially frustrating. >>The main problem I've encountered is that any pruning or extensions based on >>the previous node's score cause hashing problems because this becomes path >>dependent. > >For us new(ish) chess programmers could you clarify what problem this >modification exactly causes ? Is it simply that you get less hash hits in the >hash search or something more subtle ? > >Incidentally, your new version 828 looks to have solved the crash bug I was >seeing with Arena. Thanks > > Regards Geoff Geoff, I'll give it a shot. Essentially, what I've been experimenting with is aggressively reducing and/or pruning various branches of the tree depending on the current evaluation of the position and the previous level evaluation. If things don't seem to be improving (or getting worse) then I either... 1) reduce the depth the branch is searched or 2) eliminate it altogether. So far I've restricted this rather severely to positions where neither king is in check, no other extensions have been triggered, the last move played was not a null move, non-winning captures, non-hanging pieces etc. One of the problems I've identified is that two identical positions may not be pruned/reduced in exactly the same way, if their parent scores differ. Storing the score for these nodes in the hash table is potential trouble, since transpositions may have different scores. Uri's idea of only using these nodes for move ordering may do the trick but I haven't really evaluated it yet. More than likely in the next day or two, I'll add some scaffolding to my code to catch these type of nodes and gather some statistics. Right now it's mostly guesswork. regards, --tom
This page took 0.01 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.