Author: Christophe Theron
Date: 10:51:29 06/22/02
Go up one level in this thread
On June 22, 2002 at 09:45:37, Robert Hyatt wrote:
>On June 22, 2002 at 08:23:01, Stan Arts wrote:
>
>>Hello,
>>
>>Last time I wrote a question regarding strange behaviour of my simple fixed
>>depth alpha beta program. Indeed there was a bug in the program causing this
>>behaviour. Thanks for suggesting this because I had looked over my program
>>many times thinking there weren´t so I simply experimented a lot until I
>>located the error. Thanks! It now calculates "perfect" it seems! (=play as
>>should be expected upto X ply deep) Just like a real chessprogram... :)
>>
>>Anyway, now I noticed something else strange to the play of my program. When
>>it´s searching, on EVEN ply´s (for instance 6, or 8) it seems to play 100%
>>correct. But on ODD ply´s (like 5 or 7) sometimes it makes mistakes. (In the
>>calculationtree I count the 1st ply to be the possible moves by the computer,
>>of which one of these will actually be played after calculation. , so say a
>>5 ply deep search by my program is 3 moves by the computer, and 2 by the
>>opponent, and therefore, the deepest ply (5th) is that way a computermove)
>>Now I looked over the code very often, but can not find an error, but this
>>morning I suddenly thought of this: When doing a fixed depth search, without
>>extensions, would these evaluation errors on ODD ply´s come from the fact
>>that on this 5th ply it would for instance plunge it´s queen into a random
>>(protected) pawn because on the deepest move, ofcourse it can´t see a
>>recapture? And therefore mess up the evaluation because it thinks it can get
>>this material back? It seems to happen just rarely luckly, but I imagine in
>>some occasions with a queen centrally located for instance and on a shallow
>>search such as just 5 ply (not much change to the total position), this
>>material gain would show up in EVERY branch and therefore mess up the
>>evaluation?
>>
>>Would this be right and did anyone have the same problem? because then it´s
>>not a bug and I would sleep a little better at night...
>>
>>:)
>>
>>Stan
>
>
>There is no reason for odd plies to produce errors. Odd plies are harder to
>search than even plies. IE if you compare your effective branching factor for
>odd plies you will find it higher. The reason is that for odd plies, every
>branch at the frontier must be searched once you have searched the first root
>move. For even plies, you only search one move at the frontier before alpha/
>beta cuts it off. Even ply searches (fixed depth like you are doing) double
>the nodes for the previous depth. Odd ply searches multiply the previous search
>by roughly 38..
>
>But it should not produce errors if you don't have a bug.
I guess the problem is that he is not using a SEE or QSearch at the leaves, he
is just using the static evaluation at the horizon.
Christophe
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.