Author: Robert Hyatt
Date: 13:51:03 03/17/98
Go up one level in this thread
On March 17, 1998 at 11:34:36, Christophe Theron wrote: >On March 17, 1998 at 08:29:42, Robert Hyatt wrote: > >>On March 17, 1998 at 07:44:31, Bernhard Bauer wrote: >> >>>On March 14, 1998 at 15:34:19, Sylvain Renard wrote: >>> >>>> During the World Micro Computer Chess Championship in Paris, >>>>Amir Ban told us that his program didn't use the null move technique. >>>>So I was rather surprised that Junior 4.6 could not find the winning >>>>move in this position: White Kh3, Ne7, pawns g3,h4; Black Kf3, >>>>Ne5, pawns g6,h5; black to move. 1...Ng4! >>>> This test was first used for computers in 1982 (!) by M. Pierre Nolot >>>>(Europe Echecs n°286 Octobre 1982). >>>> Fritz 2, 3 and 4 are also unable to find the solution because there >>>>are using the null move technique and there is a zugzwang in the main >>>>line. >>>>But Frans Morsch worked well and Fritz 5 now plays the good move. >>>> Can Amir Ban explain to us what is going wrong with Junior and this >>>>test? Thank you! >>> >>>You shouldn't blame the null move technique. It's the impementaton of >>>null move! >>>Some time ago crafty failed for this problem too. It's no. 11 on Pierre >>>Nolot's >>>set. This caused some difficulties, as the benchmark was not runnable, >>>because >>>of a log(sum of times) term. >>>However Robert Hyatt has overcome this problem and finds Ng4 in 1 sec on >>>my PPro200. >>> >> >>While I have solved *some* null-move problems, as Amir said later, the >>above >>position is *not* a null-move problem. I, too, have code that says that >>a king and single knight can not possibly win. Because I have never had >>a >>position where it was possible in a real game. As A result, I would >>call >>KN vs anything as no better than 0.00, and possibly lower depending on >>what the other side has. >> >>I can't solve the above test position either... unless I disable the >>quick >>"instant draw" check in "RepetitionCheck()" where I catch it. Then I >>find >>it instantly... > >Bernhard, Bob, Amir, I don't agree with your point of view. > >I think the problem IS null move in this position (or the use of the >"null move observation", which can be done without really trying a null >move). > >I made the following experiments with my program running on K5-100MHz >(=P200), 16Mb hash. > >1) version "A". Key move found at ply 12 in 4.34s, eval=+5.53. > >2) "A", but disable code to detect KN/KXXX is draw or lost. Key move >found at ply 12 in 4.34s, eval=+5.53. > >3) "A", but disable any use of the "Null Move Observation" (not really >null move in my case, but...): key move found at ply 8 in 1.20s, >eval=+3.58. > >4) "A", and disable both "NMO techniques" and "KN is draw or worse": key >move found at ply 8 in 1.20s, eval=+3.58. > >Maybe someone could try the same experiment with Crafty. > >Rebel9 seems to suffer from the same NMO problem. It has to go to ply >11, in 12s, to find the key move (K5-100, 10Mb hash). > >BTW, black has not only K and N in this position, but also 2 pawns. >While I agree that KN can only draw in the best case, KNPP is clearly >not a draw. > >Am I missing something? > > > Christophe In the case of Crafty, yes. Because the instant a capture is made that leaves one side with a king and knight, the score is dropped to 0.00 or lower, depending on what the other side has. This is done before *any* more searching, or evaluations or anything is done. The classic is the KNNKP ending. I instantly call this a draw, even though there are mates in 1 and 2 you can set up, because 99.9999% of KNN vs Kanything are drawn. I tested this with crafty and it never found the key move, even with null move totally disabled, because it kept running into the draw problem before it saw it could mate the opponent the next move or whatever. With the draw code disabled, it found it instantly...
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.