Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Turning null-move off

Author: Paul

Date: 09:02:16 10/08/01

Go up one level in this thread


On October 08, 2001 at 11:28:49, Uri Blass wrote:

>On October 08, 2001 at 10:42:41, Paul wrote:
>
>>On October 08, 2001 at 09:31:57, Uri Blass wrote:
>>
>>>On October 08, 2001 at 07:29:04, Bernhard Bauer wrote:
>>>
>>>>On October 07, 2001 at 21:39:52, Robert Hyatt wrote:
>>>>
>>>>>
>>>>>2.  You can tone down (or even disable) the null-move search.  You can
>>>>>try sel=2/3 (the default) then sel=2/2, sel=1/1, and finally sel=0/0 which
>>>>>will turn null-move off.  This will further reduce the search depth and overall
>>>>>strength.
>>>>>
>>>>
>>>>From my experience sel=0/0 doesn't turn null-move completely off.
>>>>Here an example with sel=0/0
>>>>
>>>>[D]4B/8/6N/5p/1r4p/6pk/7b/4K2Q w - -
>>>>
>>>>
>>>>        (4)    6->   1.90  -0.44   1. Bc6 Rb1+ 2. Ke2 Rxh1 3. Nf4+ Kh4
>>>>                                   4. Bxh1 Kg5 5. Ke3
>>>>        (3)    7     1.96  -0.22   1. Bc6 Rb1+ 2. Ke2 Rxh1 3. Nf4+ Kh4
>>>>                                   4. Bxh1 Bg1 5. Bg2 Bd4
>>>>               7     2.75     ++   1. Kd2!!
>>>>        (2)    7     3.79   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3
>>>>        (2)    7->   6.29   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3
>>>>               8     8.14   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3 Qxe4+ 9. Kxe4
>>>>                                   Bg3
>>>>        (2)    8->  14.57   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3 Qxe4+ 9. Kxe4
>>>>                                   Bg3
>>>>               9    20.50   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3 Qxe4+ 9. Kxe4
>>>>                                   Bg3 10. Nf4
>>>>        (2)    9->  42.50   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3 Qxe4+ 9. Kxe4
>>>>                                   Bg3 10. Nf4
>>>>              10     1:05   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3 Qxe4+ 9. Kxe4
>>>>                                   Bg3 10. Nf4 Bxf4
>>>>        (2)   10->   2:22   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3 Qxe4+ 9. Kxe4
>>>>                                   Bg3 10. Nf4 Bxf4
>>>>              11     3:35   0.00   1. Kd2 g2 2. Qe1 g1=Q 3. Qh4+ Kg2 4.
>>>>                                   Bc6+ Re4 5. Bxe4+ fxe4 6. Qxg4+ Kh1
>>>>                                   7. Qxe4+ Qg2+ 8. Ke3 Qxe4+ 9. Kxe4
>>>>                                   Bg3 10. Nf4 Bxf4 11. Kxf4 Kh2
>>>>             time=5:00  cpu=201%  mat=4  n=142525014  fh=89%  nps=474k
>>>>             ext-> chk=10823921 cap=287226 pp=207595 1rep=668532 mate=112510
>>>>             predicted=0  nodes=142525014  evals=28834988
>>>>             endgame tablebase-> probes done=0  successful=0
>>>>             hashing-> trans/ref=47%  pawn=99%  used=99%
>>>>             SMP->  split=1018  stop=90  data=7/32  cpu=10:05  elap=5:00
>>>>
>>>>
>>>>Kind regards
>>>>Bernhard
>>>
>>>I am not sure if the problem here is null move pruning.
>>>
>>>The problem may be that programs need to know that there is a chance to win in
>>>KN vs something(otherwise they may evaluate it as not more than a draw and stop
>>>to search)
>>>
>>>There are programs without this knowledge so they cannot see that
>>>1.Bc6 Rb1+ 2.Ke2 Rxh1 3.Bg2+ is leading to a forced mate.
>>>
>>>Deep Fritz with the default parameters(null move pruning) has no problem to find
>>>the win because it has this knowledge that king and knight can mate.
>>>
>>>Uri
>>
>>Hi,
>>
>>I'm sure Bernhard is right here, checked with my own program (no endgame
>>knowledge) and the only thing that helps here is turning of recursive nullmove.
>>Just one nullmove per branch is still ok, but with recursive nullmove mine
>>doesn't get a winning score.
>
>You are right that the reason for Crafty is null move pruning but there are also
>other reasons to fail to find the right move(Junior cannot see that white wins
>because of the fact that it believes that knight cannot win).

Yes Uri, you're right about that, have seen you write that about Junior before.
A case of "almost correct" endgame knowledge to speed up the search, but that
works counterproductive here.

Paul

>>I think that Deep Fritz has a smarter kind of nullmove than older versions of
>>Fritz (double nullmove or whatever).

>Yes
>
>I know that there are cases when Deep Fritz fails to find moves because of null
>move pruning but not in this case.
>
>I guess that there are positions when it turns off null move pruning(it may be
>logical to do it in some simple positions when the number of moves of the
>opponent is small).
>
>Uri



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.