Question regarding WAC number 2

[Roman Hartmann]

My engine used to have troubles with that position too. The previous version 0.039 took almost a minute to find the move while the new (unreleased) version finds the move in about 5s on the same machine. The only difference between these two versions is the search.

8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - 0 1

Analysis by Roce 0.0395:

1...c4-c3 2.b2xc3 Tb3xc3 3.Td2-a2 d3-d2 4.Kf3-e2
-/+ (-1.31) Tiefe: 6/6 00:00:00 9kN
1...c4-c3 2.b2xc3 Tb3xc3 3.Td2-a2 d3-d2 4.Kf3-e2 Tc3xe3+ 5.Ke2xd2
-/+ (-1.31) Tiefe: 7/7 00:00:00 21kN
1...c4-c3 2.b2xc3 Tb3xc3 3.e3-e4 Tc3xa3 4.e4-e5+ Kf6-g7 5.e5-e6 h7-h5
-+ (-1.45) Tiefe: 8/8 00:00:00 51kN
1...c4-c3 2.b2xc3 Tb3xc3 3.e3-e4 f5xe4+ 4.Kf3xe4 Tc3xa3 5.h2-h4 h7-h5 6.Td2xd3
-/+ (-1.12) Tiefe: 9/9 00:00:00 115kN
1...c4-c3 2.b2xc3 Tb3xc3 3.e3-e4 f5xe4+ 4.Kf3xe4 Tc3xa3 5.h2-h4 Ta3-a1 6.Td2xd3 a4-a3
-/+ (-1.27) Tiefe: 10/10 00:00:00 276kN
1...c4-c3 2.b2xc3 Tb3xc3 3.e3-e4 f5xe4+ 4.Kf3xe4 Tc3xa3 5.h2-h4 Ta3-a1 6.Td2xd3 a4-a3 7.Td3-d7
-/+ (-1.17) Tiefe: 11/11 00:00:00 658kN
1...c4-c3 2.b2xc3 Tb3xc3 3.e3-e4 f5xe4+ 4.Kf3xe4 Tc3xa3 5.h2-h4 Ta3-b3 6.Td2xd3 Tb3xd3 7.Ke4xd3 a4-a3
-/+ (-1.27) Tiefe: 12/12 00:00:01 2128kN
1...Tb3xb2 2.Td2xb2 c4-c3 3.Tb2-b6+ Kf6-e7 4.Tb6-b7+ Ke7-d8 5.Tb7-b8+ Kd8-c7 6.Tb8-b4 c3-c2 7.Tb4-c4+ Kc7-d7 8.Tc4-d4+ Kd7-e7 9.Td4-c4 d3-d2 10.Tc4-c7+
-+ (-1.75) Tiefe: 13/13 00:00:04 5389kN
1...Tb3xb2 2.Td2xb2 c4-c3 3.Tb2-b6+ Kf6-g7 4.Tb6-b7+ Kg7-h6 5.Tb7-b6+ Kh6-h5
-+ (-2.82) Tiefe: 14/14 00:00:18 23682kN

[jacobbl]

Thanks for your comment.

I get the feeling that my engine (Sjakk) is too soft on the pruning. I reach the correct position at depth 14, but it takes about 250 seconds on a 3 GHz machine. (Just 1 CPU 32 bit.) Since my engine is programmed in Visual Basic (and with a lot of my bad programming ) it is quite slow (175Kn/s).

I was thinking it might be an idea to extend checks with more than 1 ply if the side in check has a threat or is material up a lot. The idea being that these kind of checks probably are checks trying to delay progress. I'm not sure if I will manage to implement this without causing an explosion in the search tree.

Have anybody implemented something like this, and is it a good idea?

Regards Jacob

[Michel]

Gnuchess needs 6 seconds (on a core duo@2.4GHz) to find the move but resolving the fail high takes a bit longer.
[d]8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - 0 1[/d]

18 172 1091 4428859 c3 bxc3 Rxc3 Ra2 Ke6 Rb2 Rb3 Ra2 Kd5 h3 Kc5 Rg2 Rxa3 Rg7 Kd6 Rxh7 d2 Ke2
18 196 1302 6239980 Rxb2!
....
18 521 2165 12597550 Rxb2!
18 511 2297 13498217 Rxb2 Rxb2 c3 Rb6+ Ke7 Kf2 c2 Rc6 d2 Rxc2 d1=Q Rc7+ Ke6 Rxh7 Qd2+ Kf3 Qd5+ Kg3 Qc5 Kf3 Qxa3 h4

[Michel]

Sorry. That was 13 seconds.

[bob]

Thanks for your comment.

I get the feeling that my engine (Sjakk) is too soft on the pruning. I reach the correct position at depth 14, but it takes about 250 seconds on a 3 GHz machine. (Just 1 CPU 32 bit.) Since my engine is programmed in Visual Basic (and with a lot of my bad programming ) it is quite slow (175Kn/s).

I was thinking it might be an idea to extend checks with more than 1 ply if the side in check has a threat or is material up a lot. The idea being that these kind of checks probably are checks trying to delay progress. I'm not sure if I will manage to implement this without causing an explosion in the search tree.

Have anybody implemented something like this, and is it a good idea?

Regards Jacob

I am almost certain it will hurt more than it helps. When you extend by more than 1 ply, you can get into a non-terminating search.

[jacobbl]

Are you saying that you never extend by more than 1 ply? I extend up to 1.5 plies sometimes (single move check evasion), but I haven't tested as much as you...

Regards
Jacob

[bob]

Are you saying that you never extend by more than 1 ply? I extend up to 1.5 plies sometimes (single move check evasion), but I haven't tested as much as you...

Regards
Jacob

Correct. Never more than one ply, and the only thing I extend is moves that give check. Not getting out of check. No one-legal-reply. no passed pawn pushes. Etc.

[jacobbl]

Interesting, it doesn't seem logical that a so simple rule is the optimal solution, but I will try it. But then I suspect you have advanced pruning/reductions in your engine.

Regards
Jacob

[jacobbl]

That's interesting. Would you mind to share what improvements you have made? Pruning, reduction, move ordering etc ?

Regards Jacob

[bob]

Interesting, it doesn't seem logical that a so simple rule is the optimal solution, but I will try it. But then I suspect you have advanced pruning/reductions in your engine.

Regards
Jacob

In chess, everything is a trade-off. If you extend some moves, all the others must be searched to a lower depth to keep the search space size unchanged, since that is constrained by time. Each time you trade some time to look deeper over here, you look less deep over there. The accuracy of that decision really affects engine strength. Extending all checks is a bad idea. No point in extending a check where your opponent just rips the checking piece off the board, or casually moves away with no danger...