Author: Christophe Theron
Date: 09:26:02 05/31/99
Go up one level in this thread
On May 31, 1999 at 05:26:24, Bernhard Bauer wrote:
>On May 31, 1999 at 02:13:14, Christophe Theron wrote:
>
>>On May 31, 1999 at 00:57:00, eric guttenberg wrote:
>>
>>>Cristophe,
>>>
>>>Can you explain then why F5.32 will solve the problem immediately when
>>>the position is set up in infinite analysis rather player v Fritz?
>>>
>>>eric
>>
>>I don't know exactly what's in Fritz, but I not very surprised that something
>>like that happens.
>>
>>Explaining you why is a very difficult task if you don't have strong knowledge
>>of computer chess programming.
>>
>>Null move is used together with the alphabeta algorithm. Alpha and beta are two
>>values used during the search algorithm. Alpha is meant to be less than the
>>actual score of the best move, beta is a value that is above the best score.
>>Alpha and beta are used (amongst other things) to decide when to do a null move
>>search, and when the result of null move search says that you can ignore the
>>rest of the line.
>>
>>Normally, the alphabeta search is only able to say which is the best move. You
>>have no idea of what move is the second best and so on.
>>
>>In order to find the second best move you have to play with the values of alpha
>>and beta and start the search again. In this case, the null move algorithm is
>>going to prune away different parts of the tree (because alpha and beta are not
>>the same as in the first search), and there is a chance that something that was
>>overlooked in the first search is found in the second one.
>>
>>That's why Fritz finds different things when in normal mode and when he has to
>>show the first best moves (Paulo Soares said that Fritz as found the move in
>>infinite mode with TWO OR MORE VARIANTS).
>>
>>I'm not sure it's very clear, but believe me: Fritz behaviour is NOT a bug. It's
>>only a side effect of the alphabeta algorithm together with the use of the null
>>move algorithm.
>>
>>I don't know why I'm spending so much time trying to explain this. Frans should
>>come here and explain it himself. You know, Fritz will be a tough opponent for
>>my program Tiger in the next World Championship! :)
>>
>>Please direct any further question to Bob: first he explains this very well, and
>>second he likes to answer! :)
>>
>>
>> Christophe
>
>We are get used to it: "It's not a bug it's a feature!"
>And when the programmers tell us we have to believe.
>So its not a good attitude to come up with such positions.
>
>Anyway everybody knows that crafty uses the null move technique and therefore
>cannot find the solution. Give it a try:
>
>FEN: kbK/pp/1P/8/8/8/8/R w
>
> +---+---+---+---+---+---+---+---+
> 8 | *K| *B| K | | | | | |
> +---+---+---+---+---+---+---+---+
> 7 | *P| *P| | | | | | |
> +---+---+---+---+---+---+---+---+
> 6 | | P | | | | | | |
> +---+---+---+---+---+---+---+---+
> 5 | | | | | | | | |
> +---+---+---+---+---+---+---+---+
> 4 | | | | | | | | |
> +---+---+---+---+---+---+---+---+
> 3 | | | | | | | | |
> +---+---+---+---+---+---+---+---+
> 2 | | | | | | | | |
> +---+---+---+---+---+---+---+---+
> 1 | R | | | | | | | |
> +---+---+---+---+---+---+---+---+
> a b c d e f g h
>
>White(1): end-game phase
> clearing hash tables
> time surplus 0.00 time limit 15:00 (15:00)
> s depth time score variation (1)
>starting thread 1
> 4 0.01 Mat02 1. Ra6 bxa6 2. b7#
> 4-> 0.01 Mat02 1. Ra6 bxa6 2. b7#
> time=0.01 cpu=13050% mat=1 n=1934 fh=80% nps=10000
> ext-> checks=38 recaps=10 pawns=16 1rep=10 thrt:0
> predicted=0 nodes=1934 evals=1307
> endgame tablebase-> probes done=0 successful=0
> SMP-> split=11 stop=1 data=2/64 cpu=2.61 elap=0.02
>
>mate in 2 moves.
>
>
>White(1): Ra6
>
>The law "a null move program cannot do this simply doesn't exist".
>
>The question is: How do you implement the null move technique.
>And if you do it wrong, it remains a bug.
>
>Kind regards
>
>Bernhard
You can find many other positions where Crafty will fail badly because of the
null move algorithm. The fact that Crafty is able to solve this position does
not prove that my explanation is wrong.
I repeat that finding it or not depends on 2 things at least:
* The evaluation: a small change in evaluation from one program to another gives
different values for alpha and beta, and depending on these values the program
could solve the problem or not.
* The "zugzwang detection" rule. A programmer may choose a more risky rule,
because it generally gives a program that play better. But of course you could
find more positions where the program fails.
I could even add to this list:
* The hash table policy: it can affect such positions, especially if you don't
clear your hash tables from one search to the next one.
You can find blunders like this one in any program. It's always funny to find
one, but this implies nothing about the program's strength or quality.
You can call this a bug if you want, but it is not a bug. The programmer is
aware of the problem but has choosen consciently to keep the algorithm because
it is an improvement overall.
As a chess programmer myself I make this kind of choice everyday. It is always
sad to discover that a new algorithm fails to solve a given position, but if the
program is generally stronger (wins more games) I would be a fool to reject
it...
So believe it or not, it's not a bug, it's a feature... And it is true. It is
not a bad excuse. Why would I give a wrong explanation to defend Fritz, which
will be one of my enemies in the next World Championship???
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.