Author: Vasik Rajlich
Date: 15:27:00 12/29/03
Go up one level in this thread
On December 29, 2003 at 08:44:15, Tord Romstad wrote: >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 That's true. I wonder though if you couldn't restrict yourself only to extensions which depend on a static analysis of A and the move (A->B), rather than including what happened before A. For example, the recapture extension could be reformulated as an extension for moves which capture a piece and restore material equality. This doesn't seem inferior in any way. I would guess that node A itself should contain all the information you need. Vas
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.