Author: Ed Schröder
Date: 11:25:46 11/24/99
Go up one level in this thread
>Posted by Christophe Theron on November 24, 1999 at 13:06:15: > >>>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). > >What happened when the second search "failed low"? No re-search was needed because alpha/beta + an alpha/beta window was unknown for me at that time so Rebel immediately had the right score. Then Rebel just picked the next best move from the move-list based on the result of search phase one. >It's funny because I had a similar system in a very old version. I saw my >program computing one ply less deep than Sargon and wanted that extra ply >at any cost. Right, get the commercials :-) >However I did this "re-search" at the last ply, not at the root. > >In your example I would have searched again Nf3 at 2 plies deep instead of >one. > >Once again the problem is what do you do if the second search fails low? There >are two main alternatives: >1) trust the score of the second search. >2) decide that the 1-ply search (the one that gave Nf3) is too unstable and >search again 2 plies deep. > > >Was it so stupid after all? I dropped the system because I did not see an >improvement, but at that time I was not able to judge correctly the >improvements, and anyway my program was so weak that it was still loosing >almost every game. > >Maybe it was no so bad after all? One extra ply at a low cost is something to >consider... It's still in my mind only that the current way of search (variable depth) isn't exactly suited for my old system. Ed >>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. > >Right. I was trying to add specific cases in my SEE, but it is a never ending >story. You add pins, multiple hanging pieces and so on, and always find a case >where it fails. > > > >>>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. > >Aha. Go ahead and try to explain to some people here that a better search >is not for tactics but is mainly to get a better 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... > >Another specific case we had to program... > > > > 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.