Author: Heiner Marxen
Date: 09:07:42 06/01/02
Go up one level in this thread
On June 01, 2002 at 11:35:31, Dan Andersson wrote: >The idea is similar to enumerating the state space in simple endgames. Absolutely, yes. > You will >select a won or unevaluated state for the attacker and a drawn or unevaluated >state for the defender. This will become an exact graph of the state space after >the iterations produce no more states. Currently I have no plans to span a general graph. I pick one piece of both sides, and restrict to moving only those. There are 2x64x64 positions at most, and I handle it like a 2-piece EGTB. Hence the necessary memory can be allocated statically. > There are a few problems AFAIK. Yes, for sure. > When will >you trigger the start of the algorithm? First, I will trigger it by hand, i.e. I myself will select the positions, in order to study the results, and profile the efficiency/speed. Then I will try to develop triggers. For "permanent check" two consecutive checks by the defender with the same piece may be a good trigger. If far enough away from the leaves, I may try it always. > When is it cost effective, size of the >graph? See above, currently my graphs are statically limited in size. > How will you limit the enumeration, escape conditions? I do not understand ? > And it will work >much better when you have one attacker and one defender. That is exactly the (restricted) case I'm targeting (for now). > In an ordinary game >search the position might be ambigious as to the eventual outcome and attacker >and defender might switch place due to a latent mate threat for example. Very true! Within the recursive search the "at least draw" function may be triggered/tried at different levels and for different sides. Of course, by then we should have developed some method to cache the results. A single analysis does not only evaluate the one position that triggered the analysis, but also a whole bunch more. Would be a pity to just throw away that info. > The >idea will work wonders on fortress positions with locked pawns. Locked pawns could be a good trigger for the "corresponding squares" variant. > But for more >dynamic positions with distinct conversions, a proof-number search or lambda >search will be more efficient. A PN^2 search will find a draw as easily as a win >given the right termination conditions. For dynamic positions the technique I propose cannot be used. That is for sure. I just try to start small and collect experience and insight. Since PN (and PN^2) require complete trees to be stored explicitly, I have not yet considered that technique. I've read a paper or two, so I know the basics of the theory, but not more. Why do you think that draws (even with large/long cycles) are recognized easily with PN^2 ? Do you have experience? Data to share? Theoretic insight? >MvH Dan Andersson Cheers, Heiner
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.