Author: Vincent Diepeveen
Date: 19:02:21 06/02/02
Go up one level in this thread
On June 01, 2002 at 11:35:31, Dan Andersson wrote:
Hello Dan,
You are talking in chinese for me, whereas an algorithm
is needed.
Please give some pseudo code will you of your idea?
Right now the pseudo code would be:
int MyIdea(int unknown) {
for( not interesting ) {
do enumerate(something useless);
}
conclusion = DoSomethingVague(which i won't show);
}
You present MyIdea and show the enumeration,
but the real problem is the problem below to 'dosomethingvague' in the
above example. And the fact that it won't ever get shown in
semi-pseudo code to the readers of the article.
Let's start with enumerating the state space.
Do you mean 'search space' perhaps? If so, HOW do you enumerate
and what is the USE of it?
To get concrete: I already give in debugmode each position diep searches a
64 bits number, starting by 0 then second position 1 etcetera.
Secondly, you seem to only look for a win for the attacker. How
about if score is -0.030. You talk about recognizing a draw
only however. There is a lot between losing, drawing and winning.
Even though the result of a game can always be seen as
losing or winning, it is pretty RUDE/CRUDE to divide it in
win/draw/loss. It means you get huge round off errors.
Right now in DIEP i evaluate a positoin between -infinite and +infinite
where infinite is about 1 million.
So i can get a score 0.020 which is better than 0.013, so there
is some discrimination. No rude rounded off values as in the below
text.
Mate threats are not relevant first 35 moves of the game or so,
chance i mate my opponent first 35 moves of the games is like zero.
With current search i already find mate in 20 without problems (especially
when it is forced).
However recognizing whether a difficult openings line leads to a draw
is pretty interesting.
How do you plan to search however, depth limited alfabeta?
The below description is not implementable.
Please show some pseudo code!
>The idea is similar to enumerating the state space in simple endgames. 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. There are a few problems AFAIK. When will
>you trigger the start of the algorithm? When is it cost effective, size of the
>graph? How will you limit the enumeration, escape conditions? And it will work
>much better when you have one attacker and one defender. 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. The
>idea will work wonders on fortress positions with locked pawns. 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.
>
>MvH Dan Andersson
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.