king safety eval - interesting position

[pocopito]

From a human player point of view I'd take into account just the friendly pieces (black ones in this case) in order to evaluate the king security in the case of being near to a semiopen file.
Maybe counting white pieces as "semitransparent" in this kind of positions can be an approach worth to be tested.

PS: I'm assuming your question is for the general case, being this very position is a good example.

[diep]

This one has been in my files for a while:

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

Obviously the Black king is in some serious danger but my king safety function does not currently count the doubled Rooks as attacking the King, because of the presence of the two Bishops on the same file. In fact, only the Queen, Bishop on g6, and Pawn on f5 are counted as actual or potential attackers. Overall eval for King safety is about -0.75 pawns for Black.

I'm wondering if anyone evaluates this a lot higher and if so if it's worth considering White pieces "transparent" for the purposes of king safety eval (Arasan does this for stacked Rook/Queen or Bishop/Queen attackers but not in this case, because the bishops do not move in the same direction as rooks).

Yes i don't even need to test this, Diep will give some huge major bonus for attack here for the reasons you gave and a couple of others.

It's very tricky to get that to work though. Some 'cheapo code' won't help there. Will be major slowdown of your eval to fix it. Took me years to get somehow to work.

One of first victims of this code was Uri Blass in 2004.

He was talking about hardware there in all his forumposts, but if you look at the game it was an evaluation thing that worked well

You only need to look at the 1 ply evaluation here of an engine.

Score obviously from side to move viewpoint:
00:00 200 2 0 1 (0,0) -MATE01 Nd4xf5 Qh4xh7
00:00 500 5 0 1 (0,0) -3.765 h7-h6
00:00 800 8 0 1 (0,0) -2.604 Ng8-f6
00:00 7600 76 0 2 (0,1) -3.483 Ng8-f6 Kg1-h2
++ g8-h6 procnr=0 terug=-3465 org=[-3483;-3482] newwindow=[-3483;520000]
00:00 25400 254 0 2 (0,1) -3.279 Ng8-h6 Bg6-h5
00:00 53000 1060 0 3 (0,2) -2.263 Ng8-h6 f5-f6 h7xg6 f6xg7 Qd7xg7 Bg5xh6
00:00 85000 3400 0 4 (0,3) -2.263 Ng8-h6 f5-f6 h7xg6 f6xg7 Qd7xg7 Bg5xh6
00:00 107221 15011 0 5 (0,4) -3.408 Ng8-h6 f5-f6 Qd7-e6 Rg2-f2 Kh8-g8
++ g8-f6 procnr=0 terug=-3407 org=[-3408;-3407] newwindow=[-3408;520000]
00:00 104276 17727 0 5 (0,4) -2.809 Ng8-f6 Kg1-h1 Kh8-g8 Bg5xf6 h7xg6 Rg3xg6

In itself each individual pattern i usually give a very careful score, the huge scores Diep produces usually are a result of the vaste amount of patterns; this is why Diep needs total retuning today as well, as in positions with just 1 simple thing where the Rybka clones just give 1 massive bonus or penalty, you want to be tuned to the same level; am guessing better tuning really can improve it a lot.

How many games do you need to play to see the difference in tuning of 1 individual pattern in diep that has very little relevance to the overall value?

100 million games?

Note here is rest of output. Doing this on my laptop single core it overheats to 100 celcius. Not sure how i managed to play some games with it back in 2007. I hardly ever run Diep at laptop

00:00 109664 33996 0 6 (0,5) -2.051 Ng8-f6 Kg1-f2 Qd7-b7 Kf2-f1 Kh8-g8 Bg5xf6 h7xg6 Rg3xg6
00:00 120724 54326 0 7 (0,6) -1.842 Ng8-f6 Kg1-h1 Qd7-b7 Kh1-h2 Kh8-g8 Bg5xf6 h7xg6 Rg3xg6 Nd4-f3 Kh2-g3
00:00 125316 122810 0 8 (0,7) -2.051 Ng8-f6 Kg1-f1 Qd7-c7 Kf1-f2 Qc7-b7 Kf2-f1 Kh8-g8 Bg5xf6 h7xg6 Rg3xg6
00:01 128995 248961 0 9 (0,8) -2.073 Ng8-f6 Kg1-f2 Qd7-b7 Rg2-g1 Ra7-a8 Kf2-e3 Nd4-c2 Ke3-d2 Nc2-d4 Bg5-e3
00:03 130764 407985 0 10 (0,9) -2.208 Ng8-f6 Kg1-f2 Qd7-b7 Rg2-g1 Ra7-a8 Rg3-g2 Kh8-g8 Bg5xf6 h7xg6 Bf6xg7
00:04 133873 655982 0 11 (0,10) -1.806 Ng8-f6 Kg1-f2 Qd7-b7 Rg2-g1 Qb7-d7 Kf2-e3 Nd4-c2 Ke3-e2 Nc2-d4 Ke2-f2 Kh8-g8 Bg5xf6 h7xg6 Bf6xg7 Qd7xg7 Rg3xg6 Ra7-d7

133k nps single core. Bah no good for a core2 derivative

[diep]

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.

--Jon

I don't think it is relevant whether there is a win here.

h6 is a move i never play as a human here. directly 1-0 longterm i would guess.

Of course if it calculates the rest is even worse then so be it

The tricky thing in this position is that even if you win something kingside with white, queenside you never win here; so white needs to get through at kingside and if you manage to give away material and keep it solid closed there it's a draw.

My laptop 101C if i try h6.
That's not an eval, that's temperature of the laptop.
Macbookpro 17'', apple only designs stuff and sells it, never measures whether it's performing. Look to above when you want to complain about that.

In the small search depth diep reaches at this laptop single core with throttling (normal core2 at 2.4Ghz gets 200k nps single core handsdown here, though apple also only has oldie GCC, not the 4.7 that i use under linux in office), you see it wants to sacrafice at h6, so it is undertaking action.

Please note that anything i posted here might not win elo for your engine.

It is all nice what diep is doing here, but to win games with it, is yet another issue...

black timeleft=1:30.00.00
- = - = - r n k h7-h6 1 ...
r - = q = - o - ... 2 ...
- = - o - = B o ... 3 ...
= - o - o O B - ... 4 ...
o = O n O = - Q ... 5 ...
O o = O = - R O ... 6 ...
- O - = - = R = ... 7 ...
= - = - = - K - ... 8 ...
white timeleft=1:30.00.00
white to move type 'help' for command overview

anal
Analysis mode is on
putting engine to search errorlevel=0!
00:00 3 3 0 1 (0,0) -1.354 Bg5xh6 g7xh6
00:00 4 4 0 1 (0,0) 1.351 Rg2-h2
00:00 5 5 0 1 (0,0) 4.051 Bg5-e3
00:00 16 16 0 1 (0,0) 4.146 Kg1-h1
00:00 18 18 0 1 (0,0) 4.489 Kg1-h2
00:00 136 136 0 2 (0,1) 4.220 Kg1-h2 Ng8-e7
00:00 53600 536 0 3 (0,2) 4.341 Kg1-h2 Ng8-e7 Bg5xh6 Ne7xg6 Bh6xg7 Kh8xg7 Rg3xg6 Kg7-f7 Rg6-g7 Kf7-e8 Rg7xd7 Nd4-f3 Kh2-g3 Nf3xh4 Rd7xa7 Nh4xg2 Kg3xg2
00:00 53175 2127 0 4 (0,3) 3.717 Kg1-h2 Ng8-f6 Bg5-e3 Qd7-b7
++ g1-h1 procnr=0 terug=3718 org=[3717;3718] newwindow=[3717;520000]
00:00 55300 3871 0 4 (0,3) 4.140 Kg1-h1 Qd7-b7 Kh1-h2 Ng8-e7
00:00 63394 12045 0 5 (0,4) 3.828 Kg1-h1 Rf8-f6 Bg5-e3 Ng8-e7 Bg6-h5
++ g1-h2 procnr=0 terug=3829 org=[3828;3829] newwindow=[3828;520000]
00:00 63445 15227 0 5 (0,4) 3.944 Kg1-h2 Ng8-f6 Rg2-g1 Qd7-d8 Bg5-e3
00:00 66575 26630 0 6 (0,5) 3.692 Kg1-h2 Ng8-f6 Bg5-e3 Ra7-b7 Rg2-g1 Rb7-b8
++ g1-h1 procnr=0 terug=3693 org=[3692;3693] newwindow=[3692;520000]
00:01 75077 81834 0 7 (0,6) 3.677 Kg1-h2 Qd7-b7 Bg5-e3 Ng8-f6 Be3-d2 Ra7-a8 Bd2-e3
++ g1-h1 procnr=0 terug=3678 org=[3677;3678] newwindow=[3677;520000]
00:01 83646 159764 0 8 (0,7) 3.560 Kg1-h2 Qd7-b7 Bg5-e3 Ng8-f6 Be3-d2 Ra7-a8 Bd2-g5 Kh8-g8
++ g1-h1 procnr=0 terug=3561 org=[3560;3561] newwindow=[3560;520000]
00:02 88777 223720 0 8 (0,7) 3.627 Kg1-h1 Qd7-b7 Kh1-h2 Ng8-f6 Bg5-e3 Ra7-a8 Rg2-g1 Ra8-b8
00:04 100096 438422 0 9 (0,8) 2.720 Kg1-h1 Nd4-c6 Kh1-h2 Nc6-e7 Bg5-e3 Ne7xg6 Rg3xg6 Rf8-f6 Rg6-g4
++ g1-h2 procnr=0 terug=2721 org=[2720;2721] newwindow=[2720;520000]
00:06 108333 722584 0 9 (0,8) 2.825 Kg1-h2 Nd4-c6 Rg2-g1 Nc6-e7 Bg5-e3 Ne7xg6 Rg3xg6 Rf8-f6 Rg6-g2
00:08 114550 1002316 0 10 (0,9) 2.441 Kg1-h2 Nd4-c6 f5-f6 Rf8xf6 Bg5xf6 Ng8xf6 Bg6-f5 Qd7-e7 Rg3xg7 Qe7xg7 Rg2xg7 Kh8xg7
++ g1-h1 procnr=0 terug=2442 org=[2441;2442] newwindow=[2441;520000]
++ g2-f2 procnr=0 terug=2442 org=[2441;2442] newwindow=[2441;520000]
00:19 122405 2377109 0 11 (0,10) 2.441 Kg1-h2 Nd4-c6 f5-f6 Rf8xf6 Bg5xf6 Ng8xf6 Bg6-f5 Qd7-e7 Rg3xg7 Qe7xg7 Rg2xg7 Kh8xg7
++ g2-f2 procnr=0 terug=2442 org=[2441;2442] newwindow=[2441;520000]
00:35 127208 4575695 0 12 (0,11) 2.201 Kg1-h2 Nd4-c6 Bg5-d2 Qd7-d8 Qh4-g4 Ng8-f6 Qg4-f3 Qd8-c7 Rg2-g1 Nc6-e7 Bg6-h5 Ne7-c6
++ g1-h1 procnr=0 terug=2202 org=[2201;2202] newwindow=[2201;520000]
00:40 128823 5228962 0 12 (0,11) 2.431 Kg1-h1 Nd4-c6 f5-f6 Rf8xf6 Bg5xf6 Ng8xf6 Bg6-f5 Qd7-f7 Rg3xg7 Qf7xg7 Rg2xg7 Kh8xg7
++ g2-f2 procnr=0 terug=2432 org=[2431;2432] newwindow=[2431;520000]
01:11 130490 9268712 0 13 (0,12) 2.551 Kg1-h1 Nd4-c6 f5-f6 Rf8xf6 Bg5xf6 Ng8xf6 Bg6-f5 Qd7-f7 Rg3xg7 Qf7xg7 Rg2xg7 Kh8xg7 Qh4-f2
01:22 133921 11036488 0 14 (0,13) 2.692 Kg1-h1 Nd4-c6 f5-f6 Rf8xf6 Bg5xf6 Ng8xf6 Bg6-f5 Qd7-f7 Rg3xg7 Qf7xg7 Rg2xg7 Kh8xg7 Qh4-g3 Kg7-h8 Qg3-g6
03:36 129064 27977368 0 15 (0,14) 2.527 Kg1-h1 Qd7-c7 Bg5-e3 Qc7-d8 Qh4-g4 Ng8-f6 Qg4-d1 Nd4-c6 Qd1-d2 Nc6-e7 Be3xh6 Ne7xg6 Rg3xg6 g7xh6 Qd2xh6 Ra7-h7

[diep]

auch i see 0 extensions turned on on laptop i don't want it another 100+ celcius though. will try one of the 8 core nodes later.

[CRoberson]

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.

[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.