Author: Bernhard Bauer
Date: 22:47:16 05/31/99
Go up one level in this thread
On May 31, 1999 at 12:26:02, Christophe Theron wrote: >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. > Yes, there are positions where Crafty fails because of null move. Yes, the fact that Crafty solves this position does *not* prove that your explanation of the null move algorithm is wrong. But, it shows that there are other ways to do and it shows that your explanation is incomplete. >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. > And it simply depends whether you use null move or not. In the above position it's a poor idea to use null move. Generally, if the mobility of the pieces is small, may be due to few pieces you should *not* use null move. >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. > May be there are blunders in *any* program. But I don't want do get used to it. I simly do not accept it. A blunder is a blunder. Humans do not like blunders in there play. Programs should not make such poor blunders like above. However, I agree with you that this does nothing imply about strengt. >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. > Ok lets call it a missing feature. The programmer accept some flaws in his program. Using null move in situations where it should not be used is hardly an overall improvement - while it generally may be an improvment. >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... > You should not do "this kind of choice everyday" because it's a poor choice even your program is very strong and may become champion. Anyway a program should be able to play chess and win such an easy position. IMHO you would not be a fool if you would do it right. >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??? The explanation "the computer can't do it" has proven wrong in decades. The question remains: what is the best way to do it. There are ways that will not slow down your program and will succeed in other positions. So I hope you can understand my point of view. The commercial aspect could be: Many users want a reliable analysis tool. They are not content with a program that solves 99% of positions in incredible short time, they want to be sure that there is no bug in the analysis. If there is a bug they will not be glad of the fact that their program solves some different positions faster than another program. Kind regards Bernhard > > > 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.