Author: Roberto Waldteufel
Date: 06:23:09 05/05/98
Go up one level in this thread
>On May 04, 1998 at 20:48:16, Bruce Moreland wrote: > >On May 04, 1998 at 16:38:43, Roberto Waldteufel wrote: > >>This has the effect of pusuing forcing lines for the machine >>much deeper, even if some quiet moves are interspersed between the >checks. It works very well for some tactical positions where the machine >>can mate or win material through a long sequence of moves, most, but not >>all of which are checks. > >How do you know it works well? Have you run test suites with this? > >bruce I have only tested the method on a very small set of positions in which the side to move has a long forcing variation. My basic engine is not very sophisticated in that it uses little more than material balance for its evaluation (plus a bonus for the bishop pair and for castling), and the test positions were deliberately chosen to be beyond its full-width horizon. The idea was not necessarily to use this method in all positions, but rather as a way of doing a specialised tactical search in sharp positions where the machine may have a material-winning or a mating combination. Bearing in mind that the basic search was only managing in the allotted time to search to 4-5 plies full-width (not counting getting out of check as a ply) plus captures, it failed to find many deep and some not-sodeep sacrificial combinations. I was therefore trying to find a way to "sculpt" the shape of the tree so as to make it search deeper on "promising" lines. I have tried may different approaches to the problem, generally involving variable depth reductions at each ply (extending the idea of getting out of check not counting as a ply). Mostly the results were dissapponting: either the search blew up or the combination was not found. The logarithm method metioned in my message seems the most promising in that the search can be prevented from blowing up by making modest increments to the root-ply depth value at the start of each new iteration. I know that much more testing is needed, but so far testing on 10 positions previously unsolved has resulted in correct solutions to 5 of them, while the correct move was found in one position leading to the win of two pawns (according to the program), whereas one more ply would have ended the opponents delaying moves and allowded the program to find a mate. All the moves found leading to the two pawns were correct. Of course this is too small a set of positions, but at the moment I am more concerned with trying to tweak the parameters so as to balance number of iterations required versus risk of spending an axcessive time on any one iteration. I think the method is promising, but still needs further experimentation. Roberto Waldteufel
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.