Author: Christophe Theron
Date: 07:14:06 08/02/98
Go up one level in this thread
On August 02, 1998 at 03:35:04, Ed Schröder wrote:
>>Posted by Howard Exner on August 01, 1998 at 18:48:04:
>
>>When analysing positions with Rebel 8 it often happens that the
>>correct move is locked onto in conjunction with a plus sign appearing
>>beside the move. eg. Qh6 (+).
>
>Chess programmers call this a "fail-high". It means for the move in question
>that the score is out of the "alpha-beta-window". Therefore the move must
>be re-searched with a new "alpha-beta-window" to get the correct score
>for the move in question.
>
>>The actual move however can take a long
>>time before it becomes the first choice among the other move choices.
>
>It usually takes a bit longer because of the wider "alpha-beta-window".
>
>>Why is there such a long delay in deciding to make this the first choice
>>when almost always the move turns out to be correct? Did this occur in
>>Rebel 9 also? Will the new Rebel have that long delay between marking
>>the move with the plus sign and actually making the move the top choice?
>
>In Rebel10 when a "fail-high" or (+) appears Rebel will immediately mark
>the move as "best-move" and THEN start the re-search to figure out the
>correct score. This because of the growing popularity of finding key-moves
>in the so called computer test sets. As far as I know all (most?) chess
>programs act like this.
>
>This change will result in finding key-moves average 20% faster and
>therefore Rebel10 will perform a little bit better in computer test sets.
>
>Still you will notice that sometimes (say in 5% of the cases) the "fail-high"
>or (+) is NOT rewarded by the "re-search". In this cases Rebel10 will
>stick to the previous "best-move".
>
>I have noticed that other chess programs (all??) do not show this
>behavior. When they "fail-high" the move always becomes the
>"best-move".
>
>Is the latter true or are there programs around who behave like Rebel
>in this respect?
>
>- Ed -
Chess Tiger could behave like that. The problem is that I play a lot with the
values of alpha and beta in my selective algorithms, and a re-search with
different values can give a different result and invalidate the fail high (the
move that was supposed to be superior turns out to be worse than the previous
best).
So recently I decided to do the following (soft way): when a fail high is
detected, I don't record the move as being the best. Instead, I start a
re-search, and I set a flag somewhere so that the time management system does
not interrupt the search now (unless it takes really too much time).
This approach has proven (for me) to be worse than the classic one (hard way):
record the move as being the best as soon as the fail high is detected, accept
to be interrupted by the time management during the re-search. Accept that the
fail high is not confirmed by the re-search (in this case I play the move
without being really sure it is the best).
Anyway the "soft way" is complex to implement because I have to get rid of the
hash table problem: the hash table has recorded the fail high and a lower bound
for the move score has been set. In the re-search I would have to selectively
ignore this bound if I don't trust the fail high.
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.