Author: Bernhard Bauer
Date: 02:26:24 05/31/99
Go up one level in this thread
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
This page took 0.01 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.