Author: Christophe Theron
Date: 08:34:36 03/17/98
Go up one level in this thread
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
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.