This position came up in the general forum two weeks ago and I tried it on crafty.
[d]8/b7/8/3kBp1p/p1p2PpP/P5P1/1P2K3/8 b - - 0 1
It reached ply 34 after about an hour, but had not found the solution, so I let it run in the background. It has been 338 hours and not only has it not finished ply 35, it has not failed high or low or finished the first move. The node count updates regularly and the nps seems reasonable. I have seen fail highs take a long time to resolve, but I have never seen crafty spend so long on a move without some output.
Odd crafty problem
Moderator: Ras
-
bob
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Odd crafty problem
That happens when there is a "magic boundary" somewhere. For example, here, it might be that a 33 ply search can not force a pawn thru and create a new queen. While at depth 34 this can be forced. But once a queen is allowed anywhere in the tree, it is allowed everywhere, which can blow the search completely up. It has happened every now and then and there is not much that can be done.jwes wrote:This position came up in the general forum two weeks ago and I tried it on crafty.
[d]8/b7/8/3kBp1p/p1p2PpP/P5P1/1P2K3/8 b - - 0 1
It reached ply 34 after about an hour, but had not found the solution, so I let it run in the background. It has been 338 hours and not only has it not finished ply 35, it has not failed high or low or finished the first move. The node count updates regularly and the nps seems reasonable. I have seen fail highs take a long time to resolve, but I have never seen crafty spend so long on a move without some output.
-
Martin Brown
- Posts: 46
- Joined: Sun Oct 18, 2009 12:07 pm
Re: Odd crafty problem
That isn't half so odd as what happened when I left Shredder10 running it overnight. Q6600 2.4GHz 4G ram using 834MB hash table crashed Shredder exception(1) after 2h 13m depth 30/63 considering 1. ... Bf2 (ranked 10th).jwes wrote:This position came up in the general forum two weeks ago and I tried it on crafty.
8/b7/8/3kBp1p/p1p2PpP/P5P1/1P2K3/8 b - - 0 1
It reached ply 34 after about an hour, but had not found the solution, so I let it run in the background. It has been 338 hours and not only has it not finished ply 35, it has not failed high or low or finished the first move. The node count updates regularly and the nps seems reasonable. I have seen fail highs take a long time to resolve, but I have never seen crafty spend so long on a move without some output.
I haven't seen many positions that crash commercial engines...
Stockfish1.51 reached ply 34 fairly easily but is now stuck on 12. ... Be3 (eval 98.58 @ ply 33) after 2 hours with no sign of getting a result. The annoying thing is that the 9 plausible moves that do not immediately lose the bishop were still relatively quick to process. It is lines arising after the three dud moves that really grind it to a standstill.
Martin Brown
-
Don
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: Odd crafty problem
What is the solution? My program plays Ke4 after the first 4 or 5 iterations but with no score revelations of any kind. In fact, I think it is seeing a draw - the score goes to zero at higher depths.
With the white pawns on the black squares, I assume there is a win here for black, right?
With the white pawns on the black squares, I assume there is a win here for black, right?
Martin Brown wrote:That isn't half so odd as what happened when I left Shredder10 running it overnight. Q6600 2.4GHz 4G ram using 834MB hash table crashed Shredder exception(1) after 2h 13m depth 30/63 considering 1. ... Bf2 (ranked 10th).jwes wrote:This position came up in the general forum two weeks ago and I tried it on crafty.
8/b7/8/3kBp1p/p1p2PpP/P5P1/1P2K3/8 b - - 0 1
It reached ply 34 after about an hour, but had not found the solution, so I let it run in the background. It has been 338 hours and not only has it not finished ply 35, it has not failed high or low or finished the first move. The node count updates regularly and the nps seems reasonable. I have seen fail highs take a long time to resolve, but I have never seen crafty spend so long on a move without some output.
I haven't seen many positions that crash commercial engines...
Stockfish1.51 reached ply 34 fairly easily but is now stuck on 12. ... Be3 (eval 98.58 @ ply 33) after 2 hours with no sign of getting a result. The annoying thing is that the 9 plausible moves that do not immediately lose the bishop were still relatively quick to process. It is lines arising after the three dud moves that really grind it to a standstill.
-
metax
- Posts: 344
- Joined: Wed Sep 23, 2009 5:56 pm
- Location: Germany
Re: Odd crafty problem
Stockfish 1.5 on my computer only sees a draw until ply 34, which was finished after about 4 minutes.
-
jwes
- Posts: 778
- Joined: Sat Jul 01, 2006 7:11 am
Re: Odd crafty problem
c3 is supposed to be the solution.
-
Don
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: Odd crafty problem
I just realized that my program does see the answer, it just took a long time.jwes wrote:c3 is supposed to be the solution.
Notice the huge time gap when it found the solution. It went from 60 seconds to 10 minutes at depth 29.
Here is UCI output:
info depth 27 time 28773 nodes 32299437 score cp 0 nps 1122560 pv d5e4 e5f6 a7b6 f6h8 b6g1 h8c3
info depth 27 time 30841 nodes 34592898 score cp 0 nps 1121652 pv d5e4 e5f6 a7b6 f6h8 b6g1 h8c3
info depth 28 time 40722 nodes 45204388 score cp 0 nps 1110072 pv d5e4 e5f6 a7b6 f6h8 b6g1 h8c3
info depth 28 time 43598 nodes 48319598 score cp 0 nps 1108298 pv d5e4 e5f6 a7b6 f6h8 b6g1 h8c3
info depth 29 time 65044 nodes 71563478 score cp 0 nps 1100231 pv d5e4 e5f6 a7b6 f6h8 b6g1 h8c3
info depth 29 time 606741 nodes 602485666 score cp 176 nps 992986 pv c4c3 e5c3 a7b6 c3g7 d5c4
info depth 29 time 606929 nodes 602676182 score cp 176 nps 992992 pv c4c3 e5c3 a7b6 c3g7 d5c4
info depth 30 time 1662327 nodes 1616784450 score cp 175 nps 972603 pv c4c3 e5c3 a7b6 c3g7 d5c4
info depth 30 time 1685356 nodes 1639494025 score cp 175 nps 972787 pv c4c3 e5c3 a7b6 c3g7 d5c4
info depth 31 time 2958036 nodes 2849620915 score cp 194 nps 963348 pv c4c3 e5c3 a7b6 c3g7 d5c4
info depth 31 time 3000098 nodes 2890488438 score cp 194 nps 963464 pv c4c3 e5c3 a7b6 c3g7 d5c4
info depth 32 time 5163665 nodes 4915377758 score cp 204 nps 951916 pv c4c3 e5c3 a7b6 c3g7 d5c4
info depth 32 time 5274444 nodes 5022824846 score cp 204 nps 952294 pv c4c3 e5c3 a7b6 c3g7 d5c4
-
Dann Corbit
- Posts: 12792
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Odd crafty problem
Naum coughed up a lung and did not solve it at great depth:jwes wrote:This position came up in the general forum two weeks ago and I tried it on crafty.
[d]8/b7/8/3kBp1p/p1p2PpP/P5P1/1P2K3/8 b - - 0 1
It reached ply 34 after about an hour, but had not found the solution, so I let it run in the background. It has been 338 hours and not only has it not finished ply 35, it has not failed high or low or finished the first move. The node count updates regularly and the nps seems reasonable. I have seen fail highs take a long time to resolve, but I have never seen crafty spend so long on a move without some output.
Code: Select all
Analysis from C:\test\c3.epd
11/11/2009 12:52:03 PM Level: 2000 Seconds
Analyzing engine: Naum-4:64-bit
1) c3;
Searching move: c4-c3
Best move (Naum-4:64-bit): Ba7-c5
Not found in: 33:20
2/5 00:00 70 70.000 +0.19 Ba7c5 Be5c3
3/5 00:00 148 148.000 +0.19 Ba7c5 Be5c3 Kd5e4
4/6 00:00 292 292.000 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3e5
5/7 00:00 404 134.666 +0.14 Ba7c5 Be5c3 Kd5e4 Bc3e5 Bc5d4
6/9 00:00 582 145.500 +0.14 Ba7c5 Be5c3 Kd5e4 Bc3e5 Bc5d4 Be5xd4
7/9 00:00 829 165.800 +0.14 Ba7c5 Be5c3 Kd5e4 Bc3e5 Bc5d4 Be5xd4 Ke4xd4
8/10 00:00 1.303 260.600 +0.14 Ba7c5 Be5c3 Kd5e4 Bc3e5 Bc5d4 Be5xd4 Ke4xd4 Ke2d2
9/11 00:00 2.031 338.500 +0.14 Ba7c5 Be5c3 Kd5e4 Bc3e5 Bc5d4 Be5xd4 Ke4xd4 Ke2d2 Kd4e4
10/11 00:00 3.128 446.857 +0.14 Ba7c5 Be5c3 Kd5e4 Bc3e5 Bc5d4 Be5xd4 Ke4xd4 Ke2d2 Kd4e4 Kd2e2
11/13 00:00 8.364 836.400 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3e5 Bc5e7 Be5c3 Be7d6 Ke2d2 Bd6c5 Kd2e2 Ke4d5
12/16 00:00 15.916 1.224.307 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Bf8d6 Be1d2 Ke4d5 Bd2e3 c4c3
13/15 00:00 24.033 1.413.705 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Bc5d6 Ke2d2 Bd6c5
14/17 00:00 35.610 1.548.260 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8
15/17 00:00 50.578 1.806.357 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8
16/21 00:00 72.534 2.072.399 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8
17/25 00:00 119.608 2.440.979 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8
18/20 00:00 170.297 2.703.126 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8
19/28 00:00 245.177 2.918.773 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8 Be5h8 Bf8d6 Bh8f6
20/25 00:00 353.899 3.104.377 +0.19 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8 Be5h8 Bf8d6 Bh8f6 Ke4d5 Ke2d2 Bd6c5 Kd2e2
21/34 00:00 549.332 3.390.938 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8 Be5h8 Bf8e7 Bh8c3 Be7d6 Bc3f6
22/35 00:00 815.381 3.529.787 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7
23/37 00:00 1.425.255 3.750.671 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5e1 Ke4d5 Be1c3 Bf8c5 Bc3g7 Kd5e4 Bg7e5 Bc5f8 Be5h8 Bf8d6 Bh8g7 Ke4d5 Bg7c3 Bd6e7 Bc3g7 Kd5e4 Bg7c3 Be7d6
24/39 00:01 2.359.298 3.880.424 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5d6 Bg7c3 Bd6c7 Bc3e1 Bc7d8 Be1c3 Ke4d5 Ke2e3 Bd8e7 Bc3h8 Be7c5+ Ke3e2 Kd5e4 Bh8c3
25/40 00:01 3.512.153 4.027.698 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5d6 Bg7c3 Ke4d5 Ke2e3 Bd6c7 Bc3d4 Bc7d8 Bd4c3 Bd8e7 Bc3h8 Be7c5+ Ke3e2 Kd5e4 Bh8c3 Bc5e3
26/40 00:01 5.139.514 4.101.766 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5d6 Bg7c3 Ke4d5 Ke2e3 Bd6c7 Bc3d4 Bc7d8 Bd4c3 Bd8e7 Bc3d4 Be7c5 Bd4xc5 Kd5xc5 Ke3e2 Kc5c6 Ke2d2
27/41 00:02 8.197.249 4.133.761 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5d6 Bg7c3 Ke4d5 Ke2e3 Bd6c7 Bc3d4 Bc7d8 Bd4c3 Bd8e7 Bc3d4
28/46 00:03 12.939.700 4.248.095 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5d6 Bg7c3 Bd6f8 Bc3e5 Ke4d5 Ke2d1 Bf8c5 Kd1e2 Bc5b6 Be5g7 Kd5e4 Bg7c3 Bb6e3 Bc3g7 Be3b6
29/46 00:04 19.118.904 4.250.534 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5d6 Bg7c3 Bd6f8 Bc3e5 Ke4d5 Ke2e1 Bf8c5 Ke1e2 Bc5e7 Be5g7 Be7d6 Ke2e3 Bd6c7 Bg7c3 Bc7d6 Bc3h8 Bd6c5+ Ke3e2
30/46 00:07 28.003.306 4.099.444 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Ke4d5 Bg7e5 Kd5e6 Be5c3 Bb6c7 Ke2f2 Ke6d5 Kf2e2 Kd5e4 Bc3b4
31/51 00:10 42.140.932 4.114.521 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7e3
32/49 00:14 61.121.184 4.260.800 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7e3
33/52 00:24 103.158.569 4.322.044 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7e3
34/57 00:37 160.815.874 4.336.412 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7e3
35/55 00:57 247.153.290 4.326.534 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Bb6a7
36/58 01:30 387.287.926 4.276.542 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Ke4d5 Bg7e5 Bb6d8 Be5c3 Bd8c7 Bc3g7 Bc7a5 Bg7f6
37/62 02:33 651.803.105 4.254.256 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Ke4d5 Bg7e5 Bb6d8 Be5c3 Bd8e7 Ke2e3 Be7d6 Bc3h8 Bd6c5+ Ke3e2 Bc5e7 Bh8g7 Be7d6 Ke2e3 Bd6c7 Ke3e2 Bc7a5
38/61 04:19 1.079.309.199 4.163.840 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Ke4d5 Bg7e5 Bb6d8 Be5c3 Kd5e4 Bc3e1 Bd8e7 Be1c3 Be7d6 Bc3e1 Bd6c7 Be1c3 Ke4d5 Bc3g7 Bc7a5 Bg7f6
39/62 07:11 1.773.736.069 4.112.553 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Bb6a7
40/62 11:54 3.000.500,290 4.201.048 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Bb6a7
41/62 22:33 5.784.850,650 4.274.269 +0.18 Ba7c5 Be5c3 Kd5e4 Bc3a5 Bc5f8 Ba5c3 Bf8e7 Bc3e5 Be7c5 Be5g7 Bc5b6 Bg7c3 Bb6e3 Bc3g7 Be3c5 Bg7e5 Bc5a7 Be5c3 Ba7b6 Bc3g7 Ke4d5 Bg7c3 Bb6d8 Ke2e3 Bd8c7 Bc3d4 Bc7a5 Bd4c3 Ba5d8 Ke3e2 Kd5e4 Bc3e1 Bd8f6 Be1c3 Bf6e7
11/11/2009 1:20:33 PM, Time for this analysis: 00:28:24, Rated time: 33:20
-
Dann Corbit
- Posts: 12792
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Odd crafty problem
Rybka did not fare much better:
Code: Select all
Analysis from C:\test\c3.epd
11/11/2009 1:21:12 PM Level: 2000 Seconds
Analyzing engine: Rybka 3
1) c3;
Searching move: c4-c3
Best move (Rybka 3): Kd5-e4
Not found in: 33:20
2 00:00 64 2.048 +0.15 Ba7d4
2 00:00 110 3.520 +0.44 Kd5e4
3 00:00 158 5.056 +0.30 Kd5e4
4 00:00 216 6.912 +0.30 Kd5e4
5 00:00 293 9.376 +0.29 Kd5e4 Be5c3
6 00:00 487 15.584 +0.26 Kd5e4 Be5c3 Ba7c5
7 00:00 668 21.376 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8
8 00:00 985 31.520 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3
9 00:00 1.642 35.029 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
10 00:00 2.594 55.338 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
11 00:00 4.207 89.749 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
12 00:00 6.752 108.032 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
13 00:00 10.928 174.848 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
14 00:00 14.975 194.106 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
15 00:00 20.162 217.325 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
16 00:00 29.226 237.519 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
17 00:00 38.302 276.205 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3
18 00:00 64.018 297.974 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
19 00:00 94.223 323.772 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
20 00:00 132.184 346.180 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
21 00:00 196.430 357.272 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
22 00:01 323.404 372.096 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
23 00:01 515.576 367.653 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
24 00:02 741.884 368.781 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
25 00:03 1.093.083 375.483 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
26 00:08 1.620.986 386.830 +0.26 Kd5e4 Be5c3
27 00:13 2.586.419 371.405 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
28 00:13 4.509.289 364.934 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
29 00:22 7.411.485 345.017 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
30 00:39 12.773.073 329.171 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5 Be3b6 Be5c3 Bb6c7
31 01:10 22.653.445 329.556 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
32 02:07 42.200.635 339.424 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
33 03:55 79.748.299 346.140 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
34 08:30 174.231.249 349.540 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
35 11:58 239.829.764 341.909 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
36 22:24 481.996.580 367.044 +0.26 Kd5e4 Be5c3 Ba7c5 Bc3h8 Bc5e3 Bh8e5
11/11/2009 1:54:44 PM, Time for this analysis: 00:33:20, Rated time: 33:20
0 of 1 matching moves
11/11/2009 1:54:45 PM, Total time: 12:33:33 AM
Rated time: 33:20 = 2000 Seconds
-
hgm
- Posts: 28390
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Odd crafty problem
This behavior is a consequence of the desire to search every branch to the same effective depth (equating the "effective depth" of a null move to R+1 ply). From a chessic perspective this is a non-sensical desire: after having concluded that promotion is unavoidable, and takes 35 moves against best defense, it is not satisfied (and thus will not give the 35-ply score) before it has searched all other branches to that depth as well. Also those branches that, against very stupid defense, already promoted after 15 ply. Before those braches were null-move pruned to almost nothing, because there was no need to move the Queen: it could just be sitting there on the promotion square while you null-moved, until you finally received its big fat score in the material evaluation of the much-reduced end leaf, which would make these null-moves fail high.
But when merely having a Queen is no longer guarantee for fail high, because the PV now has a Queen too, the Queen has suddenly to take offensive action in those sub-trees, exploding them completely. It will be making an attempt to figure out how much damage that Queen can do in the remaining 20 ply, of which it had no idea before. (So this is a completely uninformed search.)
Humans don't think that way; they think more in a DTC metric. First you try to delay the Queening as much as possible. When you finally proved that Queening is unavoidable, you start analyzing the next phase of the game, where you start counting the depth from the point where you promoted. Allowing an early promotion might be a much beter defense; before you discovered that promotion was unavoidable the tree will contain many horizon moves sacrificing material or position just to delay promotion. So it makes sense to compare early promotions to delayed promotions, with the same number of ply after the promotion. If you don't, the late promotion is likely to (unjustly) look better for many more plies, because there is less depth to see the sme (or worse) disasters. Basically you are just cultivating the horizon effect. To make a sensible choice between the promotion positions, you need to compare their search scores at the same remaining depth.
This is not impossible to implement in an engine: one could propagate the "depth after resolution", defined as depth searched past the point where the static eval approximated the search score, back towards the root with the PV score. In a sense it would be a tag to the window limit, and should also be propagated upward through the tree, together with this window limit. As long as the static eval is very far from the window limit, depth for daughter nodes would be decreased as usual. But as soon as the static eval reaches the window limit again (e.g. because you are in a branch that promoted early), so that this new branch could become PV, the remaining depth should be reduced to the depth of resolution of the window limit we are comparing it against.
Another, more general method, which also ameliorates problems like this, is node-balancing: use fractional ply, and could each ply made from a given position for log(nr_of_moves). This would count plies after promotion more heavily than plies before promotion, reducing the search work in the early-promotion branches somewhat. This method would also help in the opposite situation, where you trade your last piece. The plies in the resulting Pawn ending would be counted for much less, increasing the true search depth there.
But when merely having a Queen is no longer guarantee for fail high, because the PV now has a Queen too, the Queen has suddenly to take offensive action in those sub-trees, exploding them completely. It will be making an attempt to figure out how much damage that Queen can do in the remaining 20 ply, of which it had no idea before. (So this is a completely uninformed search.)
Humans don't think that way; they think more in a DTC metric. First you try to delay the Queening as much as possible. When you finally proved that Queening is unavoidable, you start analyzing the next phase of the game, where you start counting the depth from the point where you promoted. Allowing an early promotion might be a much beter defense; before you discovered that promotion was unavoidable the tree will contain many horizon moves sacrificing material or position just to delay promotion. So it makes sense to compare early promotions to delayed promotions, with the same number of ply after the promotion. If you don't, the late promotion is likely to (unjustly) look better for many more plies, because there is less depth to see the sme (or worse) disasters. Basically you are just cultivating the horizon effect. To make a sensible choice between the promotion positions, you need to compare their search scores at the same remaining depth.
This is not impossible to implement in an engine: one could propagate the "depth after resolution", defined as depth searched past the point where the static eval approximated the search score, back towards the root with the PV score. In a sense it would be a tag to the window limit, and should also be propagated upward through the tree, together with this window limit. As long as the static eval is very far from the window limit, depth for daughter nodes would be decreased as usual. But as soon as the static eval reaches the window limit again (e.g. because you are in a branch that promoted early), so that this new branch could become PV, the remaining depth should be reduced to the depth of resolution of the window limit we are comparing it against.
Another, more general method, which also ameliorates problems like this, is node-balancing: use fractional ply, and could each ply made from a given position for log(nr_of_moves). This would count plies after promotion more heavily than plies before promotion, reducing the search work in the early-promotion branches somewhat. This method would also help in the opposite situation, where you trade your last piece. The plies in the resulting Pawn ending would be counted for much less, increasing the true search depth there.