Author: Omid David
Date: 06:44:59 06/22/02
Go up one level in this thread
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 If the results of odd plies are incorrect, that's most probably a bug as Sune mentioned. However an interesting issue is that number of cutoffs in even plies is more than odd plies when using transposition table (hash table), and as a result if you count number of nodes at each ply you'll see that in odd plies you have to search more than you'd expect at first glance. For detailed explanation refer to: Aske Platt (1996), Research Re: Search and Re-search, PhD thesis. You can download it in postscript format at http://www.cs.biu.ac.il/~davoudo/articles.html
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.