Challenge

[Kempelen]

The important question, of course, is if the ability to find the solution to this problem makes the engine stronger or weaker.

Any opinions on that?

My conjecture is that being able to find the mate here is an indication that the engine wastes too much time on searching unlikely lines, and thus is unneccesary weak.

My opinion is that if solving the problem is not the real question to know if a engine is strong or not. I think a engine would be strong if has the detection mode or have a way that let it solve the problem disabling null move.
If a engine can not solving this king of problem becuase null move, then is a little weak because that... it is posible that it dischards many winning position.

[smrf]

... How to solve this easy problem ?

[d] 8/6B1/p5p1/Pp4kp/1P5r/5P1Q/4q1PK/8 w - - 0 32 bm Qxh4
...

SMIRF MS-174d-0 computes:

Code: Select all

01:00.1 (20.01=) +5.936 32.Qxh4+ (=/=) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.Bf4 gxf3 38.gxf3 Kh3 39.Kf2 Kh4
00:50.4 (19.01=) +5.936 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.Bf4 gxf3 38.gxf3 Kh3 39.Kf2 Kh4
00:42.4 (18.01=) +5.756 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.Bf4 gxf3 38.gxf3 Kh3 39.Kf2 Kh4
00:41.1 (18.01+) +4.764 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4 38.Bf6+ Kg3 39.Bd4 Kh4
00:25.5 (17.01=) +0.639 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4 38.Bd6 g3 39.Be7+ Kh5
00:25.3 (17.01+) +0.639 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4 38.Bd6 g3 39.Be7+ Kh5
00:14.4 (16.01=) +0.473 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4 38.Bd6 g3 39.Be7+ Kh5
00:14.3 (16.01+) +0.473 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4 38.Bd6 g3 39.Be7+ Kh5
00:13.2 (15.03=) +0.328 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4 38.Bd6 g3
00:13.1 (15.03+) +0.328 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4 38.Bd6 g3
00:07.5 (15.01=) +0.326 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Ke6 34.Qh3+ Kf6 35.Qg3 Qe7 36.Qf4+ Kg7 37.Qd2 Kh7 38.Kg1 Qe5 39.Kf1 Kg7
00:04.5 (14.03=) +0.326 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Ke6 34.Qg3 Qe5 35.Qxe5+ Kxe5 36.g3 g5 37.Kg2 g4 38.f4+ Ke6 39.Kf1 h4
00:03.8 (14.02=) +0.326 32.Bf6+ (Qxh4+) Kxf6 33.Qxh4+ Ke6 34.Qg3 Qe5 35.Qxe5+ Kxe5 36.g3 g5 37.Kg2 g4 38.f4+ Ke6 39.Kf1 h4
00:02.5 (13.03=) +0.301 32.Qxh4+ (Bf6+) Kxh4 33.Bf6+ g5 34.Bc3 Qf2 35.Be5 Qg1+ 36.Kxg1 g4 37.fxg4 hxg4
00:02.0 (13.01=) +0.299 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Ke6 34.Qg3 Qe5 35.Qxe5+ Kxe5 36.g3 g5 37.Kg2 Ke6 38.f4 g4 39.Kf1 Kf7
00:01.1 (12.01=) +0.367 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Ke6 34.Qg3 Qe5 35.Qxe5+ Kxe5 36.g3 Kf6 37.Kg2 Kf7 38.f4 g5 39.fxg5 h4
00:00.7 (11.01=) +0.381 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Ke6 34.Qg3 Qe5 35.Qxe5+ Kxe5 36.g3 Kf6 37.Kg2 Kf7 38.f4 g5
00:00.3 (10.01=) +0.609 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Kg7 34.Qd4+ Kf7 35.f4 Qe6 36.Qd8 Qe1 37.g4
00:00.1 (09.01=) +0.627 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Kf5 34.Kh3 Qe5 35.g3 Ke6 36.Qd8 g5 37.f4
00:00.0 (08.01=) +0.654 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Kf7 34.Qf4+ Kg7 35.Qd4+ Kh6 36.Qh8+ Kg5 37.f4+ Kxf4 38.Qf6+ Kg4 39.Qxg6+ Kf4
00:00.0 (07.01=) +0.639 32.Bf6+ (Bh6+) Kxf6 33.Qxh4+ Kf7 34.Qf4+ Kg7 35.Qd4+ Kh6 36.Qf4+ g5 37.Qf6+ Kh7

The problem is not using a nullmove heuristic but the kind it has been implemented.

[hgm]

If a engine can not solving this king of problem becuase null move, then is a little weak because that... it is posible that it dischards many winning position.

This is exactly what I doubt. Especially the first position is extremely contrived, and positions like that will almost never occur in real games. Verifying every null move (either explicitly, or through double null move) in positions with this many pieces is almost always a waste of time, and the nodes thus wasted go at the expense of other nodes that had a high probability for finding something relevant (which could have been searched in stead). Even if they are simply nodes at the tips of the tree (i.e. extra depth).

[bob]

this is one of those classic anti-nullmove positions. Not worth worrying over since they are practically never seen in real games...

[sje]

With null move active, Symbolic goes on and on...

Without null move, after eight seconds and 6,264,328 nodes:

PV: 1. Rh1 d4 2. Ra1 d3 3. Ra3 bxa3+ 4. Ka1 a2 5. Ba3 Kxf6 6. Bb2# Score: MateIn6

[Eelco de Groot]

With some luck Acalagon found it, it uses Nullmove just like Glaurung, and is probably saved by the Verification Search. It depends also on the rest of the parameters though, with default Mobility 100, and maybe this 100 is too much, the right move 1. Rh1 is found at 16 ply but a mate score will probably take longer.

In these 006i settings Mobility is at 90; less Mobility can sometimes help to more quickly find tactics when they are present. Mobility at 100 is still much less than in Glaurung where Mobility 100 in the UCI options is translated to 0x100 in the program, by the Internal Weight conversion.

This also happens with Passed Pawns and Pawn Structure I believe, their internal Defaults are set at 0x100 or 256 in Glaurung initially in this part of the code:

Code: Select all

  // Internal evaluation weights.  These are applied on top of the evaluation
  // weights read from UCI parameters.  The purpose is to be able to change
  // the evaluation weights while keeping the default values of the UCI
  // parameters at 100, which looks prettier.
  const int WeightMobilityMidgameInternal = 0x100;
  const int WeightMobilityEndgameInternal = 0x100;
  const int WeightPawnStructureMidgameInternal = 0x100;
  const int WeightPawnStructureEndgameInternal = 0x100;
  const int WeightPassedPawnsMidgameInternal = 0x100;
  const int WeightPassedPawnsEndgameInternal = 0x100;
  const int WeightKingSafetyInternal = 0x100;

, but in Ancalagon these are all just reset at 100 internally by the altered compute_weight conversion routine

Code: Select all

 
 // compute_weight() computes the value of an evaluation weight, by combining
  // an UCI-configurable weight with an internal weight.

  int compute_weight(int uciWeight, int internalWeight) {
    // uciWeight = (uciWeight * 0x100) / 100; //[EdG: This changes defaults to 0x100 but is commented out in Ancalagon for now]
    return (uciWeight * internalWeight) / 0x100;
  }

n1N3br/2p1Bpkr/1pP2R1b/pP1p1PpR/Pp4P1/1P6/1K1P4/8 w - -

Engine: Ancalagon 2.0 Beta 006j (64 MB)
by Tord Romstad, Eelco de Groot

9.00 0:00 +1.88 1.Nd6 cxd6 2.Rxd6 f6 3.Bxf6+ Kf7
4.Bxh8 Rxh8 5.Rdxh6 Rxh6 6.Rxh6 Nc7
7.Kc2 (45.358) 263

10.00 0:00 +2.54 1.Nd6 cxd6 2.Rxd6 f6 3.Bxf6+ Kf7
4.Bxh8 Rxh8 5.Rdxh6 Rxh6 6.Rxh6 Nc7
7.Rg6 d4 8.Rxg5 (84.894) 339

11.00 0:00 +2.54 1.Nd6 cxd6 2.Rxd6 f6 3.Bxf6+ Kf7
4.Bxh8 Rxh8 5.Rdxh6 Rxh6 6.Rxh6 Nc7
7.Rg6 d4 8.Rxg5 (345.491) 433

12.01 0:01 +2.78 1.Nd6 cxd6 2.Rxd6 f6 3.Bxf6+ Kf8
4.Bxh8 Rxh8 5.Rdxh6 Rxh6 6.Rxh6 Nc7
7.Rg6 Kf7 8.Rxg5 d4 (801.260) 453

13.01 0:04 +2.35 1.Nd6 cxd6 2.Rxd6 f6 3.Bxf6+ Kf7
4.Bxh8 Rxh8 5.Rdxh6 Rxh6 6.Rxh6 Ke7
7.Rh8 Kf7 8.Rh5 Kf6 9.Kc2 (2.019.014) 450

13.03 0:05 +3.07 1.Kc2 d4 2.Nd6 cxd6 3.Rxd6 f6
4.Bxf6+ Kf7 5.Bxh8 Rxh8 6.Rdxh6 Rxh6
7.Rxh6 Nc7 8.Rd6 Ke8 9.Rxd4 (2.357.833) 450

14.01 0:08 +3.17 1.Kc2 d4 2.Nd6 cxd6 3.Rxd6 f6
4.Bxf6+ Kf7 5.Bxh8 Rxh8 6.Rhxh6 Rxh6
7.Rxh6 Nc7 8.Rd6 Ke8 9.Rd7 Nd5 (3.800.783) 459

15.01 0:17 +3.01 1.Kc2 d4 2.Nd6 cxd6 3.Rxd6 f6
4.Bxf6+ Kf8 5.Bxh8 Rxh8 6.Rdxh6 Rxh6
7.Rxh6 d3+ 8.Kb2 Ke8 9.Rd6 Nc7
10.Rd7 Nd5 (8.146.887) 459

15.03 0:26 +3.66 1.Rh1 d4 2.Nd6 cxd6 3.Rxd6 f6
4.Bxf6+ Kf7 5.Bxd4 Nc7 6.Rd7+ Kf8
7.Bxh8 Rxh8 8.Rxc7 Bf7 9.d4 Kg7
10.Re7 (11.675.145) 448

16.01 0:44 +3.88 1.Rh1 d4 2.Nd6 cxd6 3.Rxd6 f6
4.Bxf6+ Kf7 5.Bxd4 Nc7 6.Rd7+ Kf8
7.Bxh8 Rxh8 8.Rxc7 Bf7 9.Rc8+ Be8
10.Re1 Bg7+ 11.Kc2 Kf7 (20.142.410) 457

17.01 2:01 +3.94 1.Rh1 d4 2.Nd6 cxd6 3.Rxd6 f6
4.Bxf6+ Kf7 5.Bxd4 Nc7 6.Rd7+ Kf8
7.Bxh8 Rxh8 8.Rxc7 Bf7 9.Rc8+ Be8
10.d4 Rh7 11.Re1 Re7 (55.248.430) 456

18.01 5:07 +M9 1.Rh1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7
5.Ka2 Kf8 6.Rd7 Kg7 7.Rg6+ Kf8
8.Be7+ Ke8 9.Rd8+ (139.766.651) 454

19.01 5:10 +M9 1.Rh1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7
5.Ka2 Kf8 6.Rd7 Kg7 7.Rg6+ Kf8
8.Be7+ Ke8 9.Rd8+ (141.435.378) 455

20.01 5:19 +M9 1.Rh1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7
5.Ka2 Kf8 6.Rd7 Kg7 7.Rg6+ Kf8
8.Be7+ Ke8 9.Rd8+ (146.288.763) 457

21.01 5:40 +M9 1.Rh1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7
5.Ka2 Kf8 6.Rd7 Kg7 7.Rg6+ Kf8
8.Be7+ Ke8 9.Rd8+ (157.659.090) 463

22.01 6:21 +M9 1.Rh1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7
5.Ka2 Kf8 6.Rd7 Kg7 7.Rg6+ Kf8
8.Be7+ Ke8 9.Rd8+ (181.467.104) 475

23.01 7:50 +M9 1.Rh1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7
5.Ka2 Kf8 6.Rd7 Kg7 7.Rg6+ Kf8
8.Be7+ Ke8 9.Rd8+ (233.025.031) 494

24.01 11:03 +M9 1.Rh1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7
5.Ka2 Kf8 6.Rd7 Kg7 7.Rg6+ Kf8
8.Be7+ Ke8 9.Rd8+ (344.097.570) 518

25.01 18:34 +M6 1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2
5.Ba3 Kxf6 6.Bb2+ (611.671.512) 548

26.01 18:55 +M6 1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2
5.Ba3 Kxf6 6.Bb2+ (630.553.794) 555

27.01 19:11 +M6 1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2
5.Ba3 Kxf6 6.Bb2+ (646.002.644) 561

28.01 19:24 +M6 1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2
5.Ba3 Kxf6 6.Bb2+ (660.720.387) 567

29.01 19:36 +M6 1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2
5.Ba3 Kxf6 6.Bb2+ (675.136.670) 573

30.01 19:47 +M6 1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2
5.Ba3 Kxf6 6.Bb2+ (689.525.281) 580

31.01 19:57 +M6 1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2
5.Ba3 Kxf6 6.Bb2+ (703.846.844) 587

best move: Rh5-h1 time: 20:04.234 min n/s: 592.093 nodes: 713.010.000

[Uri Blass]

This problem is mate in 6!!!.


FEN: n1N3br/2p1Bpkr/1pP2R1b/pP1p1PpR/Pp4P1/1P6/1K1P4/8 w - - 0

I have not found any engine that can solve it. I thought strong engines would fine the mate in a few seconds. Craft need more than two minutes in my machine to find a very looooong sequence for mate, but the mate in 6 is hidden to it.

why?

You did not try movei
Movei does not use null move pruning here because black has not enough legal moves to justify using null move pruning.

New game
n1N3br/2p1Bpkr/1pP2R1b/pP1p1PpR/Pp4P1/1P6/1K1P4/8 w - - 0 1

Analysis by Movei00_8_438:

1.Kb1 d4 2.Rh3 d3
² (0.46) Depth: 2 00:00:00
1.Kb1 d4 2.Rh3 d3
² (0.46) Depth: 2 00:00:00
1.Ka1
² (0.47) Depth: 2 00:00:00
1.Ka1 d4 2.Rh3 d3
² (0.53) Depth: 2 00:00:00
1.Ka1 d4 2.Rh3 d3
² (0.53) Depth: 2 00:00:00
1.Ka1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3
² (0.41) Depth: 3 00:00:00
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3
² (0.45) Depth: 3 00:00:00
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3
² (0.45) Depth: 3 00:00:00
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3
² (0.45) Depth: 3 00:00:00
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3
² (0.45) Depth: 4 00:00:00
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3
² (0.45) Depth: 4 00:00:00
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Ke8
² (0.66) Depth: 5 00:00:00
1.d3
² (0.67) Depth: 5 00:00:00
1.d3 d4 2.Nd6 cxd6 3.Rxd6 Nc7 4.Bf6+ Kf8 5.Bxh8 Rxh8 6.Rdxh6 Rxh6 7.Rxh6
± (0.84) Depth: 5 00:00:00
1.d3 d4 2.Nd6 cxd6 3.Rxd6 Nc7 4.Bf6+ Kf8 5.Bxh8 Rxh8 6.Rdxh6 Rxh6 7.Rxh6
± (0.84) Depth: 5 00:00:00
1.d3 d4 2.Nd6 cxd6 3.Rxd6 Nc7 4.Bf6+ Kf8 5.Bxh8 Rxh8 6.Rdxh6 Rxh6 7.Rxh6
± (0.84) Depth: 6 00:00:00 48kN
1.Kb1
± (0.85) Depth: 6 00:00:00 63kN
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Ke8 5.Be7
± (1.05) Depth: 6 00:00:00 72kN
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Ke8 5.Be7
± (1.05) Depth: 6 00:00:00 100kN
1.Kb1
± (1.35) Depth: 7 00:00:00 100kN
1.Kb1 d4 2.Rh3 d3 3.Bd8 Kf8 4.Rxd3 Kg7 5.Re3 Kf8 6.Be7+ Kg7
± (1.40) Depth: 7 00:00:00 116kN
1.Rh1
+- (1.70) Depth: 7 00:00:00 122kN
1.Rh1
+- (1.70) Depth: 7 00:00:00 122kN
1.Rh1 d4 2.Re1 d3 3.Nd6 cxd6 4.Rxd6 f6 5.Bxf6+ Kf8 6.Rd8+ Kf7 7.Bxh8 Rxh8 8.Rxa8
+- (4.39) Depth: 7 00:00:00 131kN
1.Rh1 d4 2.Re1 d3 3.Nd6 cxd6 4.Rxd6 f6 5.Bxf6+ Kf8 6.Rd8+ Kf7 7.Bxh8 Rxh8 8.Rxa8
+- (4.39) Depth: 7 00:00:00 151kN
1.Rh1
+- (4.09) Depth: 8 00:00:00 192kN
1.Rh1 d4 2.Re1 d3 3.Nd6 cxd6 4.Rxd6 f6 5.Bxf6+ Kf8 6.Bxh8
+- (3.95) Depth: 8 00:00:00 236kN
1.Rh1 d4 2.Re1 d3 3.Nd6 cxd6 4.Rxd6 f6 5.Bxf6+ Kf8 6.Bxh8
+- (3.95) Depth: 8 00:00:00 329kN
1.Rh1
+- (4.25) Depth: 9 00:00:01 382kN
1.Rh1
+- (4.95) Depth: 9 00:00:01 382kN
1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2 5.Ba3 Kxf6 6.Bb2#
+- (#6) Depth: 9 00:00:01 415kN
1.Rh1 d4 2.Ra1 d3 3.Ra3 bxa3+ 4.Ka1 a2 5.Ba3 Kxf6 6.Bb2#
+- (#6) Depth: 9 00:00:01 514kN

(Uri, MyTown 25.06.2008)

[Kempelen]

You did not try movei
Movei does not use null move pruning here because black has not enough legal moves to justify using null move pruning.

If you check the number of legal moves before null-move try, isn't that a waste of time? I dont generate moves before null-move try. I intuit zugwang position are less than null-move cut positions, so generating moves before null move could be a wasting time, no?

[Uri Blass]

You did not try movei
Movei does not use null move pruning here because black has not enough legal moves to justify using null move pruning.

If you check the number of legal moves before null-move try, isn't that a waste of time? I dont generate moves before null-move try. I intuit zugwang position are less than null-move cut positions, so generating moves before null move could be a wasting time, no?

It may be a waste of time but I always generate legal moves or at least count them even if I do not save them in a list.

when the king is not in check
number of legal moves for every piece is used for the mobility evaluation
and if I already calculate number of legal moves for every piece then calculating also the number of legal moves is relatively cheap.

You can say that it may be better not to count legal moves but I think that
not counting illegal moves for pinned pieces is better evaluation.

Uri

[Kempelen]

You did not try movei
Movei does not use null move pruning here because black has not enough legal moves to justify using null move pruning.

If you check the number of legal moves before null-move try, isn't that a waste of time? I dont generate moves before null-move try. I intuit zugwang position are less than null-move cut positions, so generating moves before null move could be a wasting time, no?

It may be a waste of time but I always generate legal moves or at least count them even if I do not save them in a list.

when the king is not in check
number of legal moves for every piece is used for the mobility evaluation
and if I already calculate number of legal moves for every piece then calculating also the number of legal moves is relatively cheap.

You can say that it may be better not to count legal moves but I think that
not counting illegal moves for pinned pieces is better evaluation.

Uri

Then, as I understand, you are calling evaluation and mobilitiy in all internal nodes and not the leaf ones, isn't it?