Author: Ed Schröder
Date: 23:48:25 11/23/99
Go up one level in this thread
>Posted by Christophe Theron on November 23, 1999 at 11:59:46: > >>No alpha/beta, no windows, no Q-search, the program could only think >>in steps of 2 plies. Thus 2,4,6,8 etc. > > >??? > >How did it work? Why the always even depth? The even ply depth was the second (obliged) stage of the search. Before that a (first stage) 1,3,5,7 etc. search was done. The second stage was needed to check stage one (the odd ply search) a kind of safety search that should find and correct the errors of stage one. Quite confusing I assume but what can you expect from a first try? In more detail, start position as an example... Stage one came up with 1.e4 e5 2.Nf3 (0.20) Stage two did a 3-ply search on 1.e4 to safety check 1.e4 (thus 4-plies in total). The new main-variation: 1.e4 e5 2.Nf3 Nc6 (0.12) Since the score of stage 2 was in a reasonable margin of only 0.08 the move 1.e4 was played (or stayed as best move). This (weird) system was needed because of the static evaluation. The big disadvantage of static evaluation is its impossibility to judge a complicated position in a reliable way. >Nice. That's of course much faster than cross-compiling, then downloading >to the Apple (or the standalone 6502 prototypes). > >Never had problems with subtle differences between the real thing and the >emulator? Nope. Note that the 6502 is a very simple processor. It was a relative very easy job to program it. I believe I have spend not more than 1-2 weeks programming the emulator. >That's funny. That's exactly what my first program did. At the horizon it >used a static exchange evaluator to stop the search and give an evaluation. > >The SEE was complex and time consuming. I could compute only 10 positions per >second. Pathetic. > >But writting the SEE in itself was already a good challenge. > >I have been using a similar technique until 1993. > >The fact that a QSearch runs very quickly is counter intuitive. Common sense >says that it can have to compute complex sequences of capture/capture on >several plies with a branching factor of 2 or 3. > >Without trying it actually, I would still be using the inferior SEE only >approach. Right. When I introduced Q-Search in Rebel I noticed the big improvement in positional play. The static evaluation couldn't detect several cases of hanging pieces who in practice did not hang at all (overloading, pins etc). As a result static evaluation considered a piece as lost where it was not lost at all. Q-Search solved this all and made Rebel a lot more reliable in tactics but most of all in positional play. The static evaluation even had a mate detector. That is: if a check was given Rebel was able to see if it was a checkmate or not without going one ply deeper. Glad all of this is out now... Ed
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.