Author: Tord Romstad
Date: 05:44:15 12/29/03
Go up one level in this thread
On December 29, 2003 at 03:47:11, Vasik Rajlich wrote: >On December 28, 2003 at 21:07:34, Tom Likens wrote: > >>On December 28, 2003 at 16:55:49, Tord Romstad wrote: >> >>>Hi Tom! >>> >>>That's precisely what I am doing in Gothmog, as you probably know. I'm glad >>>to hear that you try similar ideas, and that your first results are promising. >>>I've found that it takes lots of tuning and testing before it works well, >>>but I think such techniques have great potential in the long run. If it's >>>done right, most of the improvements you do in your evaluation function will >>>automatically improve the accuracy of your search. >> >>When I first started experimenting with this idea I was *very* aggressive. >>Interesting it didn't really hurt the programs tactics and it seemed to >>reach much deeper depths while searching, so I was very excited. >>Unfortunately, when I played the new version against the older non-pruning >>version it lost rather badly. So, now I'm starting out in a more >>conservative fashion and tuning the reductions based on actual games. >> >>>>My (obvious) question, how do other programmers deal with this phenomenon? >>>>I suppose ignoring it is one option, but I'm hoping there is a better >>>>solution. >>> >>>I agree that this problem is extremely annoying, and I have spent lots of >>>time and effort trying to find a solution. Unfortunately, I still haven't >>>found any good ideas. I asked a question about exactly this problem here in >>>CCC just a couple of days ago, but the only person who replied was Dieter >>>Bürssner, who also hadn't found a better solution than just ignoring the >>>problem and hoping it wasn't too important. >>> >>>Tord >> >>The fact that neither yourself nor Dieter have found a satisfactory solution >>illustrates the difficulty of the problem. It may be possible to tag these >>nodes when they are saved into the hash table and simply use them for move >>ordering, as Uri suggested. I need to gather some data before I can make >>any kind of intelligent decision. I do agree though that the concept has >>*massive* potential. I wouldn't be surprised if this wasn't part of the >>"secret" of the commercial programs, (especially that Tiger fella) ;-) >> >>--tom > >Hello, > >It seems to me that there is a way to deal with this. > >Let's say you're at node A going to node B. You can statically evaluate node A, >statically evaluate the move (A->B) in the context of node A, apply the >appropriate reduction/extension, and enter node B with the already >extended/reduced search depth. In this case, node B will go into the hash table >with that new remaining search depth. As far as I can see, this doesn't solve the problem, but just moves it to a different node. Consider the simplest and most well-known path dependent extension: The recapture extension. The move (A->B) could be a recapture in one node and not be a recapture at a different node with the same position on the board. The node B will be stored correctly in the hash table, but there is a problem with node A. Tord
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.