Author: Christophe Theron
Date: 10:06:15 11/24/99
Go up one level in this thread
On November 24, 1999 at 02:48:25, Ed Schröder wrote:
>>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"?
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.
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...
>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.