Another interesting Anti-Null move position (from a real gam

[Jaime Benito de Valle Rui]

Geschrieben von:/Posted by: Jaime Benito de Valle Ruiz at 14 June 2004 22:37:18:


8/8/1p4p1/p5kp/Pp1QP1Pq/1P6/6K1/8 w - - 0 62

White moves and wins!
Can your engine find the right answer and give the proper "crushing" score
(around 9 pawns!) along with a proper PV? How long does it take?
Mine doesn't find anything after a long long time (over an hour), but with
null-move disabled, it takes only a few seconds to show the full PV.
(Some engines find the right answer, but with a small score, an absurd PV, and
they change their mind some plies later)
In this position the black king is in a very delicate position: After a couple
of moves, if the black queen moves, white checkmates inmediately, so both kings
and queens must remain still while pawns play on their own.
Any good suggestion to avoid this problem with null-move?
Regards,
Jaime

[Dieter Bürßner]

Geschrieben von:/Posted by: Dieter Bürßner at 15 June 2004 23:28:55:
Als Antwort auf:/In reply to: Another interesting Anti-Null move position (from a real game) geschrieben von:/posted by: Jaime Benito de Valle Ruiz at 14 June 2004 22:37:18:

8/8/1p4p1/p5kp/Pp1QP1Pq/1P6/6K1/8 w - - 0 62

White moves and wins!
Can your engine find the right answer and give the proper "crushing" score
(around 9 pawns!) along with a proper PV? How long does it take?
Mine doesn't find anything after a long long time (over an hour), but with
null-move disabled, it takes only a few seconds to show the full PV.
(Some engines find the right answer, but with a small score, an absurd PV, and
they change their mind some plies later)
In this position the black king is in a very delicate position: After a couple
of moves, if the black queen moves, white checkmates inmediately, so both kings
and queens must remain still while pawns play on their own.
Any good suggestion to avoid this problem with null-move?

Yace, 5 minutes to get score +6. 6 1/2 min for score 8.3 on P4 2.53 GHz.
You can try Vincent's idea of double null move. Or my idea (probably others had it independently of me) of null move "verification" (which is different to Omid's verification). Only allow a null move cutoff, when a search with much reduced depth (for example depth-R-2) without null move now (but allowed again deeper in the tree) also fails high. It makes search trees bigger in general, however. The double null move idea is actually very similar to this. Both methods will guarantee, that you will not get stuck with a Zugzwang problem, but it will need higher depth than a search without null move, to detect such problems.
Regards,
Dieter