A question for engine programmers

[Jack Lad]

According to Mark Uniacke of HIARCS engines can be programmed to understand certain positions.
[d] b6k/8/p1prprp1/PpPpPpPp/1P1P1P1P/2K5/8/8 w - - 0 1
For example in this position it takes SF just over a minute on my computer to realise that it is bad to take a rook.

[d] r5k1/pp1n3r/2pq1np1/6B1/3P3P/8/PPP2PP1/R2QR1K1 b - - 0 1
In this position black should try to keep the queen and trade the rooks by playing Re7.

Both these positions are quite easy for human intuition to see immediately what to do but how do engines know what to to do?

[bob]

According to Mark Uniacke of HIARCS engines can be programmed to understand certain positions.
[d] b6k/8/p1prprp1/PpPpPpPp/1P1P1P1P/2K5/8/8 w - - 0 1
For example in this position it takes SF just over a minute on my computer to realise that it is bad to take a rook.

[d] r5k1/pp1n3r/2pq1np1/6B1/3P3P/8/PPP2PP1/R2QR1K1 b - - 0 1
In this position black should try to keep the queen and trade the rooks by playing Re7.

Both these positions are quite easy for human intuition to see immediately what to do but how do engines know what to to do?

There are some old versions of Crafty that solve this type of position almost instantly and correctly. But the "fix" is somewhat harmful overall. You have to recognize blocked pawns first, and realize that unless YOU do something to unblock them, it is a draw. And if you are behind in material, that would be the trigger. But to recognize the original necessary condition of "blocked unless I do something" takes CPU cycles, and those cycles are wasted in almost 100% of the cases, EXCEPT for these kinds of positions. So you have to ask yourself, am I willing to slow the search down in 100% of the positions, by X%, so that I can correctly deal with the one in a zillion position where this will help?" You can sort of guess why this is not being done. In the old versions of Crafty, someone submitted the code to me and it worked, but the slow-down was unacceptable. I turned it into a compile-time option. I don't remember what it was, exactly, perhaps -DDRAW or -DDETECT_DRAWS or something similar, so that those that wanted the feature could have it without making everyone accept the resulting loss of speed.

[Eelco de Groot]

Hi Mc Mad,

Just wanted to add that most programs, especially those not so heavy on knowledge, really have no special features for this. Stockfish at least has to rely on brute force. Maybe Sting knows something about the completely closed position one, but I'm not sure. Shredder I believe has some code and Crafty if you compile the code in, was it Jeremiah Penery who developed the special code for Crafty?

In the second position, Stockfish would see that the white Rook has an open e-file so after it exchanges rooks, the position is a bit more even when neither have a rook controlling an open file. That is all, rest is search. And the first position also it is pure search of the tactical consequences of any possible capture and it has to see it goes wrong. It helps that Stockfish almost only looks at captures, checks, pawn promotions in the last six plies. But still it is mostly saved here by extending the principal variation -the main line-, with singular extensions. If it does not do that and you can question if it should do that because it is pretty expensive just extending the PV to see if it fails, then it will not see the eval fall below -13.99 after any pawn capturing a rook, and thinks that any king move is worse, -14 or less. This is a big misevaluation of course when it is really a draw. Without singular extensions in the PV nodes, it takes five plies longer to go to -14 as in my version of Stockfish. The difference is not that big, although after a minute it is a few pawns difference, but that means it will see it much later than one minute here. Still I would like to limit these extesions a bit Basically the singular extensions only serve to cover up a 14 pawns misevaluation from Stockfish here ...

[D]b6k/8/p1prprp1/PpPpPpPp/1P1P1P1P/2K5/8/8 w - -

Engine: Sf20140810_016 MOD MP (Q6700, 4 threads, 512 MB)
-With no singular extensions in PV nodes
by Tord Romstad, Marco Costalba and Joona Kiiski

33/33 0:00 -8.39 1.cxd6 Rf8 2.Kd3 Kg7 3.Ke2 Kf7 4.Ke3 Rc8
5.Kd3 Ke8 6.Kc3 Rd8 7.Kc2 Kd7 8.Kc3 Bb7
9.Kd3 Re8 10.Ke2 Rf8 11.Kd2 Rd8
12.Kc3 Rf8 13.Kd3 Rd8 14.Ke3 (4.910.014) 4934

34/34 0:01 -8.34 1.cxd6 Rf8 2.Kd3 Kg7 3.Ke2 Kf7 4.Ke3 Rc8
5.Kd3 Ke8 6.Kc3 Rd8 7.Kc2 Kd7 8.Kc3 Bb7
9.Kd3 Re8 10.Ke2 Rf8 11.Kd2 Rg8
12.Kd3 Ba8 13.Kd2 Rb8 14.Kd3 (6.403.926) 4941

.
.
.
.

40/44 0:52 -10.64 1.gxf6 Rd8 2.Kd3 Bb7 3.Ke2 Kg8 4.Ke3 g5
5.fxg5 f4+ 6.Kxf4 Kf7 7.Kf3 Bc8
8.Ke2 Bd7 9.Ke3 Rf8 10.Ke2 Rb8
11.Kd1 Rd8 12.Ke2 Be8 13.Kf3 Kg6
14.Kg2 (306.777.678) 5884

41/44 0:59 -10.70-- 1.gxf6 Rd8 2.Kd3 Kh7 3.Kc3 Bb7 4.Kd3 g5
5.fxg5 f4 6.Ke2 Kg6 7.Kf3 Ra8 8.Kxf4 Bc8
9.Kg3 Kf5 10.Kf2 Bd7 11.Ke2 Be8
12.Kd3 Rd8 13.Ke3 (346.302.661) 5855

41/44 1:04 -10.77-- 1.gxf6 Rd8 2.Kd3 Kh7 3.Kc3 Bb7 4.Kd3 g5
5.fxg5 f4 6.g6+ (375.066.324) 5834

41/46 1:22 -10.85-- 1.gxf6 Rd8 2.Kd3 Kh7 3.Ke3 g5 4.fxg5 Kg6
5.Kf4 Kf7 6.Kg3 Re8 7.Kf3 Bb7 8.Kg3 f4+
9.Kf3 Rc8 10.Kxf4 Rg8 11.Ke3 Kg6
12.Kf4 Bc8 13.Ke3 Bd7 14.Kf3 (475.675.752) 5791

41/46 1:24 -10.97-- 1.gxf6 Rd8 2.Kd3 Kh7 3.Ke3 g5 4.fxg5 Rg8
5.Kf3 Kg6 6.Ke3 Bb7 7.Kf4 Rb8 8.Kf3 f4
9.Kxf4 Rf8 10.Kf3 Re8 11.Kf2 Bc8
12.Kf1 Rf8 13.Kg1 Kf5 14.Kg2 (487.570.493) 5782

41/46 1:36 -11.05 1.gxf6 Rd8 2.Kd3 Kh7 3.Ke3 Rh8 4.Ke2 g5
5.fxg5 Bb7 6.Kf2 Rd8 7.Kg3 f4+ 8.Kf3 Kg6
9.Kxf4 Bc8 10.Kf3 Kf5 11.Kf2 Bd7
12.Ke3 Be8 13.Kf3 Bf7 14.Ke3 (553.122.687) 5731
.
.
.
.

44/49 5:45 -13.37 1.gxf6 Rd7 2.Kd3 g5 3.fxg5 Kh7 4.Ke2 Kg6
5.Kf3 Rd8 6.Kf4 Kf7 7.Kg3 Re8 8.Kf3 Bb7
9.Kg3 f4+ 10.Kf3 Rg8 11.Kxf4 Rh8 (1.896.911.700) 5482

45/49 6:03 -13.44-- 1.gxf6 Rd7 2.Kd3 g5 3.fxg5 Kh7 4.Ke2 Bb7
5.Kf3 f4 6.Kxf4 Kg6 7.Kf3 Rc7 8.Kf2 Bc8
9.Ke2 Rd7 10.Kd3 Rf7 11.Kd2 Kf5
12.Ke2 Rd7 13.Kf2 Rd8 14.Kg2 (1.988.716.142) 5468

45/49 6:48 -13.31++ 1.exd6 Rf8 2.Kc2 Rd8 (2.225.823.699) 5453

45/49 6:53 -13.50-- 1.exd6 Rf8 2.Kc2 Rb8 3.Kd3 Rb7 4.Ke3 Rd7
5.Kd3 Rd8 6.Kc3 Kg7 7.Kc2 e5 8.dxe5 Kf7
9.Kd2 Ke6 10.Kc3 Rf8 11.Kd3 Re8
12.Ke3 Bb7 13.Kf2 d4 14.Kg2 (2.251.018.219) 5448

45/49 7:04 -13.62-- 1.exd6 Rf8 2.Kc2 Rb8 3.Kd3 Rb7 4.Ke3 Rd7
5.Kd3 Rd8 6.Kc3 Kg7 7.Kc2 e5 8.dxe5 Kf7
9.Kd2 Ke6 10.Kc3 d4+ 11.Kd3 Rf8
12.Kxd4 Bb7 13.Kc3 Bc8 14.Kd4 (2.311.047.841) 5441

45/49 7:16 -13.77-- 1.exd6 Rf8 2.Kc2 Rb8 3.Kc3 Bb7 4.Kd2 Kg8
5.Kc2 e5 6.dxe5 Kf7 7.Kb3 d4 8.Kb2 Ke6
9.Kc1 Re8 10.Kc2 Bc8 11.Kd3 Rf8
12.Kxd4 Re8 13.Ke3 Kd5 14.Kd3 (2.370.008.762) 5424

45/49 7:40 -13.99-- 1.exd6 Rf8 2.Kc2 Rb8 3.Kc3 Bb7 4.Kd2 Kg8
5.Kc2 e5 6.fxe5 Kf7 7.Kb3 (2.490.426.180) 5413

45/49 9:47 -14.00 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kf3 Rg8 10.Ke3 Ra8 11.Kd2 Rgd8
12.Kd3 Bc8 13.Kc3 Rf8 14.Kd3 (3.313.646.374) 5643

46/49 9:51 -14.00 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kf3 Rg8 10.Ke3 Ra8 11.Kd2 Rgd8
12.Kd3 Bc8 13.Kc3 Rf8 14.Kd3 (3.340.716.251) 5647

47/49 9:55 -13.99 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kd3 Ra8 10.Kc2 Bc8 11.Kd2 Rd8
12.Ke3 Bd7 13.Kf2 Rab8 14.Ke2 (3.362.354.269) 5650

48/49 9:56 -13.99 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kd3 Ra8 10.Kc2 Bc8 11.Kd2 Rd8
12.Ke3 Bd7 13.Kf2 Rab8 14.Ke2 (3.367.978.431) 5648

49/49 10:00 -13.99 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kd3 Ra8 10.Kc3 Kf7 11.Kd3 Kg7
12.Ke3 Rf8 13.Kd3 Rab8 14.Kc3 (3.393.331.616) 5649

50/50 10:10 -13.99 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kd3 Ra8 10.Kc3 Kf7 11.Kd3 Ke7 (3.449.540.311) 5654

51/51 10:20 -13.99 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kd3 Ra8 10.Kc3 Kf7 11.Kc2 Rg8
12.Kd3 Rgd8 13.Ke3 Ke7 14.Kf3 (3.511.647.537) 5661

52/52 10:23 -13.99 1.Kc2 Rd8 2.Kd3 Rff8 3.Ke3 Bb7 4.Kf3 Rc8
5.Kg2 Kg8 6.Kf2 Kf7 7.Kf3 Rfe8 8.Ke3 Ke7
9.Kd3 Ra8 10.Kc3 Kf7 11.Kc2 Rg8
12.Kd3 Rgd8 13.Ke3 Ke7 14.Kf3 (3.533.508.387) 5664

best move: Kc3-c2 time: 10:24.441 min n/s: 5.664.080 nodes: 3.533.508.387