king safety eval - interesting position

[Eelco de Groot]

I think it is worth noting that the actual position, in spite of all the stacked pieces still looks like a draw if you do a deep search on this position or for example a shoot out, and that probably has to do with the blocked pawn position, however strange that may seem. So particularly for the static eval, if an advanced pawn eval considers this position as drawish just by the pawn structure, in this particular instance I think your static eval would be right. Bear in mind I am a very weak chessplayer though.

In this position, I coded Telepath to give bonus points for the rooks being on a semi-open file, a few more bonus points for being on a
semi-open file near the opposing king where it is the opponents pawns that are the reason it being semi-open (IOW, the rooks are attacking).

As a human chess player, I consider the bishops as mobile and temporarily blocking the rooks, so the rooks must get a bonus (small one). This helps the program position the rooks there instead of another semi-open file elsewhere. Given the bonus is relatively small, points are gained by moving the bishops and getting direct attacks.

The OLD chess axiom that applies here is "... don't move the pawns on the side where you are being attacked ...". Telepath plays ...Nf6 after 21 ply.

I take it you meant with that that h6 is maybe not the best move Charles? The output below has not so much to do with the position but I just like to relate that I was trying to get my version of the Stockfish search to work (using Jon's example more for stresstesting) and it just kept crashing with unclear error messages 0xc00000fd or 0xc0000005 or even without error messages and maybe it is something very simple, but I haven't figured it out yet. The same code did work in older versions of Stockfish but a lot has changed since then. So I was very glad when finally at least one of my attempts did not seem to crash anymore and I let it run for a long time on this position. It stayed with h6 for very long which maybe isn't the best move, my crashing versions all went for Nf6 before expiring but this is the output of the non crashing version at the end. There is a big Fail High it tries to resolve at depth 46 Going from a nullwindow search to a full PV search from scratch at depth 46 is probably too difficult, it is a common complaint on the Rybka forum too that such cases, using Rybka, simpy are not being resolved and users have a hard time understanding why this is so.


5rnk/r2q2pp/3p2B1/2p1pPB1/p1PnP2Q/Pp1P2RP/1P4R1/6K1 b - -

Engine: Rainbow Serpent 2.2.4 Build 002 (one thread on the old Athlon, Stockfish base code is that of the master at 29-03-2012 but most of the RS changes are in here, except some crashing search mods. Hashtables 256 MB)
by Tord Romstad, Marco Costalba and Joona Kiiski

44/77 42:11 -2.98 1...h6 2.Rf2 Rf6 3.Kh1 Qc7 4.Rgg2 Nc6
5.Rg1 Qe7 6.Qh5 Qc7 7.Rfg2 Nd4 8.Rf1 Ra6
9.Rgg1 Qb7 10.Rf2 Ra7 11.Rgf1 Qe7
12.Kh2 Ra8 13.Rg1 Qb7 14.Qh4 Ra7 (944.780.695) 373

45/77 47:51 -2.98 1...h6 2.Rf2 Rf6 3.Kh1 Qc7 4.Rgg2 Qe7
5.Kg1 Ra8 6.Qh5 Qc7 7.Kh1 Ra6 8.Qh4 Ra7
9.Kh2 Qb7 10.Kg1 Ra6 11.Kh1 Qe7
12.Rg4 (1.071.438.204) 373

46/77 56:46 -2.90++ 1...Nf6 2.Bd2 Qb7 3.Bg5 Nc2 4.Rf2 Kg8
5.Bxf6 (1.280.063.952) 375

46/81 59:39 -2.82++ 1...Nf6 2.Kh1 Qb7 3.Kg1 Nc2 4.Rf3 Qb8
5.Rfg3 Qc8 6.Rf2 Nd4 7.Bc1 Qb7
8.Rfg2 Nc2 9.Bd2 Nxa3 10.bxa3 b2
11.Be3 b1Q+ (1.349.238.280) 376

46/81 60:03 -2.70++ 1...Nf6 2.Kh1 Qb7 3.Kh2 Ra5 4.Qxh7+ Nxh7
5.Bxh7 Kxh7 (1.358.508.190) 377

46/81 61:32 -2.52++ 1...Nf6 2.Kh1 Qb7 3.Qxh7+ Nxh7
4.Bxh7 Kxh7 (1.394.107.747) 377

46/103 74:51 -2.25++ 1...Nf6 2.Qh6 gxh6 3.Bxf6+ Rxf6
4.Bxh7 Qxh7 5.Rg6 Rxg6 6.fxg6 Qxg6 (1.839.732.780) 409

46/103 76:09 -1.84++ 1...Nf6 2.Qh6 gxh6 3.Bxf6+ Rxf6
4.Bxh7 Qxh7 (1.871.865.740) 409

best move: Ng8-f6 time: 1551:14.125 min n/s: 409.604 nodes: 1.871.865.740

After more than 24 hours there was no sign that the FH for Nf6 would be resolved, I stopped the run then but as a stress-test it was a success that the engine still seemed to be doing calculations and I don't think it was in a search explosion but that is not certain. Unfortunately version 003 of the search is still crashing

Regards, Eelco

[mcostalba]

To clarify, I don't claim there's a win for White here - I just suspect that this and similar positions may be mis-evaluated, statically.

IMHO a single eval score says nothing. You always need at least 2: one of the current position (A) and one of a position without what you think gives the advantage (B). For instance in this case you may want to see the evaluation in a very similar position but with the rooks not doubled. Then, if eval(A) > eval(B) there is no case for discussion. I think it is critical to always have clear in mind what evaluations are used for in engines...and no, are not used to analyses the positions in a human like way, are used to decide what is the best move, completely different concept.

[jdart]

In this position, I coded Telepath to give bonus points for the rooks being on a semi-open file, a few more bonus points for being on a
semi-open file near the opposing king where it is the opponents pawns that are the reason it being semi-open (IOW, the rooks are attacking).

That seems reasonable although of course testing would be needed to see if that is really worth doing.

--Jon

[lucasart]

In this position, I coded Telepath to give bonus points for the rooks being on a semi-open file, a few more bonus points for being on a
semi-open file near the opposing king where it is the opponents pawns that are the reason it being semi-open (IOW, the rooks are attacking).

As a human chess player, I consider the bishops as mobile and temporarily blocking the rooks, so the rooks must get a bonus (small one). This helps the program position the rooks there instead of another semi-open file elsewhere. Given the bonus is relatively small, points are gained by moving the bishops and getting direct attacks.

The OLD chess axiom that applies here is "... don't move the pawns on the side where you are being attacked ...". Telepath plays ...Nf6 after 21 ply.

I think h6 is also valid here. White is of course better, but I can't see any forcing line to obtain any kind of decisive advantage.
Here's what DoubleCheck 3.1 says

Code: Select all

info score cp -103 depth 23 nodes 108800745 time 113440 pv h7h6 f5f6 f8f6 g5f6 g8f6 g1h2

So black gives up the exchange for a pawn and ends up ok-ish.