SF misevaluating pawn endings

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Eelco de Groot
Posts: 4279
Joined: Sun Mar 12, 2006 1:40 am
Location: Groningen

Re: SF misevaluating pawn endings

Post by Eelco de Groot » Wed Dec 07, 2016 1:43 am

Joerg posted on https://github.com/official-stockfish/S ... issues/760
@Stefano80 @Kingdefender But will this also be helpful in positions with more pawns like the one mentioned above? Iam not sure, maybe I will give it a try tomorrow. It should be easy enough to try.
I rather reply here now because I think Rocky's issue gets a bit sidetracked. This is a very different position. I don't think treating KPk bitbase evals differently will help a lot here. Your suggestion for changing LMP will, but unfortunately you lose some speed I think. Stefano's suggestion is more a logical change because you make better use of exact results in the KPk bitbase. I guess, in positions where you hit KPk it should even be a little speedup because you don't need to search a draw position anymore (only in Root to get a move) but not so much that Marco will be satisfied by that. It should leave LMR intact though.

I don't know how much extra code is involved.... If your point of view is that Syzygy bases should solve this, I don't think we have much chance. I depends if it can be cleanly done?

By the way for Peer's position 1 I have an alternative suggestion that even lowers the benchnumber :) Old bench with Vondele's latest refactor patch:

bench: 5884767

New bench with modificated latest Development Stock:

Stockfish 20161205 MOD _02
===========================
Total time (ms) : 3112
Nodes searched : 5879059
Nodes/second : 1889157

Code: Select all

      // Step 13. Pruning at shallow depth
      if (   !rootNode
	       && !&#40;pos.count<ALL_PIECES>&#40;WHITE&#41; + pos.count<ALL_PIECES>&#40;BLACK&#41; <= 5&#41;  // New condition
	    /* && !&#40;PvNode && !pos.non_pawn_material&#40;pos.side_to_move&#40;))) */
          &&  bestValue > VALUE_MATED_IN_MAX_PLY&#41;
      &#123;
Will return always something like this


8/1p4p1/5k2/5p2/8/3K3P/5PP1/8 w - -

Engine: Stockfish 20161205 MOD _02 HT (7 threads, i7 6700, 512 MB)
by T. Romstad, M. Costalba, J. Kiiski, G. Linscott

30/55 0:01 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 f2 12.Kxf2 Kf4 13.Ke2 Ke4
14.Kf2 (28.197.992) 19857

31/55 0:01 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 f2 12.Kxf2 Kf4 13.Ke2 Ke4
14.Kf2 (33.953.160) 20114

32/55 0:01 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 f2 12.Kxf2 Kf4 13.Ke2 Ke4
14.Kf2 (40.140.731) 20222

33/55 0:02 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 f2 12.Kxf2 Kf4 13.Ke2 Ke4
14.Kf2 (57.295.204) 20706

34/55 0:03 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (80.122.010) 21286

35/55 0:05 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (113.809.223) 22407

36/55 0:09 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (234.291.665) 24842

37/55 0:10 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (253.566.325) 24964

38/55 0:12 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (304.774.696) 25387

39/55 0:19 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (516.614.250) 27164

40/55 1:34 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (2.782.650.592) 29573

41/55 4:04 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (7.373.300.745) 30140

42/55 4:09 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (7.490.207.986) 30054

43/55 4:31 0.00 1.f4 b5 2.Kd4 Ke6 3.g4 Kf7 4.Kc5 g5
5.Kxb5 gxf4 6.Kc4 fxg4 7.hxg4 Kf6
8.Kd3 Kg5 9.Ke2 Kxg4 10.Kf2 f3
11.Kf1 Kg3 12.Kg1 f2+ 13.Kf1 Kh2
14.Kxf2 (8.122.271.067) 29967
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan

Post Reply