Static evaluation of the immobile pieces

[Arpad Rusz]

The static evaluation should severely penalize the black rook and bishop in the following position (Clausen, 1930). Even the knight must get a big penalty.
On the other hand the white king has much less attacking value than the black one.
Effectively only the R+P vs K+N is fighting and white has the upper hand. White eventually even wins the game!

[D]8/8/1k6/8/6p1/6p1/P2R1pPp/n4Kbr w - - 0 1

[Arpad Rusz]

Engines usually give a big bonus for the passed pawns. So the pawns are rewarded for being able to reach the promotion square (their main target) on a "frozen board". Probably the static evaluation can be made more dynamic also for other pieces. They should receive rewards (or penalties) for their ability/inability to reach some targets ("hot squares"). E.g. a piece which cannot give a check or cannot capture even having a "frozen board walk" should be penalized. A king which cannot "find" the other king should be given a penalty. Of course, a piece which cannot move at all should be penalized even more. Your own pieces/pawns can be also targets ("how quickly can you defend them?").

I don't know how expensive these walks are but I suspect there could exist some clever algorithms to calculate them cheaply. The occupied and the attacked squares have to be excluded from the walk and that greatly reduces the size of the board. Allowing only a reduced number of steps or using these walks only in the endgame also helps.

Maybe this approach also gives a hope to solve the fortress issue with the engines.

[hgm]

This is often difficult to see statically, and certainly whether the trapping is permanent. There are also cases where pieces have legal moves, but they are all tactically punished with loss of the piece. Or where it does have safe legal moves, but ca only move back and forth.

The case of the Knight is usually solved by givig a high value to the 7th-rank passer. E.g. in micro-Max such a Pawn would be worth ~280 cP, leaving only a surplus of 45cP for the N-vs-P in that corner.

To sensibly search positions like this, it is needed to not search by depth, but by tree size. I.e. start with a node budget (which increases during iteration), and divide the budget over the children until you run out. This prevents the part of the tree where the branching factor explodes (because you released trapped pieces) from soaking up all nodes, and allows the branch that keeps the pieces trapped to reach high depth.

[mclane]

The program breakthrough had a
Nice approach that calculated this ...

A piece that cannot move anymore should not have the same value like a piece that has squares to move.

[Nordlandia]

A piece that cannot move anymore should not have the same value like a piece that has squares to move.

Bishop at h6 has value of zero.

Fortress draw.

[d]6bk/5pp1/3N1p1b/8/4p1p1/5PPp/4pPNP/4K3 w - - 0 1

[pgn][Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "New game"]
[Black "?"]
[Result "*"]
[SetUp "1"]
[FEN "6bk/5pp1/3N1p1b/8/4p1p1/5PPp/4pPNP/4K3 w - - 0 1"]
[PlyCount "9"]

{[#]} 1. Nh4 exf3 2. Ng6+ fxg6 3. Nf7+ Kh7 4. Ng5+ fxg5 5. Kd2 *

[/pgn]

[hgm]

I think it is a mistake to ascribe a fortress draw to the value of a particular piece.

[Nordlandia]

Three bishop of same color ->

[d]q7/1p1p2b1/3P1pP1/2R2K1p/3P3k/3p2pP/p3p1P1/8 w - - 0 1

[corres]

There are chess programs for problem solving and there are for playing chess. These positions are not derived from natural chess play so it is not a good thing to wait for a normal chess engine to solve this issue.
To handle fortresses there are some solutions but these heavy hurt the playing power of engines.

[peter]

White eventually even wins the game!

[D]8/8/1k6/8/6p1/6p1/P2R1pPp/n4Kbr w - - 0 1

That's a clear white win, Arpad, don't you think so too?

8/8/1k6/8/6p1/6p1/P2R1pPp/n4Kbr w - - 0 1

Analysis by Komodo 11.2.2 64-bit:

1.Rb2+ Ka7 2.a4 Ka6 3.a5 Kxa5 4.Ra2+ Kb6 5.Rxa1 Kc5 6.Ra3 Kd6 7.Rxg3 Ke5 8.Rxg4 Kf6 9.Rc4 Kf5 10.Rd4 Kg5 11.Rd5+ Kh4 12.Rc5 Kg3 13.Rc3+ Kf4 14.Rb3 Kg4 15.Rb4+ Kg3 16.Rb6 Kg4 17.Rf6 Kg5 18.Rf7 Kg4 19.Rf3 Kg5 20.Rf8 Kg6 21.g3 Kg7 22.Rb8 Kg6 23.Rg8+ Kf5 24.Rg7 Ke6
+- (250.00) Depth: 42 00:03:15 4872MN, tb=35995682

Full Syzygys, nullmove was turned off and I had already done some Forward- Backward to get the output.

Really funny how rating list leading engines with empty hash change from black winning eval to 0.00 and stick to it for a while.

I saw a game H6-SF at 30'+5" with full Syzygys both (it's better to switch tbs off probably here ) ending drawn after 6 moves because of repeated 0.00- evals adjudicated by the GUI.

Thanks for the position, Arpad

[Arpad Rusz]

Yes, it is a clear win for white!
The author's solution was this:

[pgn][Event "Tidskrift for Schack#218 (v)"]
[Site "?"]
[Date "1930.??.??"]
[Round "?"]
[White "Clausen=S"]
[Black "(+0433.24f1b6)"]
[Result "1-0"]
[SetUp "1"]
[FEN "8/8/1k6/8/6p1/6p1/P2R1pPp/n4Kbr w - - 0 1"]
[PlyCount "77"]
[EventDate "1930.??.??"]

1. Rb2+ Ka6 2. a3 Ka5 3. a4 Ka6 4. a5 Ka7 5. a6 Ka8 6. a7 Kxa7 7.
Ra2+ Kb6 8. Rxa1 Kc5 9. Ra4 Kd5 10. Rxg4 Ke5 11. Rxg3 Kf5 12. Rg7 Kf4 13. Rg8
Kf5 14. g3 Kf6 15. g4 Kf7 16. Ra8 Kg6 17. Ra3 Kg5 18. Rg3 Kf4 19. g5 Kxg3 20.
g6 Kf4 21. g7 Ke4 22. g8=Q Ke5 23. Qc4 Kf5 24. Qd4 Kg5 25. Qe4 Kf6 26. Qd5 Ke7
27. Qc6 Kf7 28. Qd6 Kg7 29. Qe6 Kf8 30. Qd7 Kg8 31. Qe7 Kh8 32. Qg5 Kh7 33. Qg2
Kh6 34. Ke2 Kh7 35. Kf3 Kh6 36. Ke4 Kh7 37. Kf5 f1=Q+ 38. Qxf1 Kg7 39. Qg2+ 1-0[/pgn]