Stockfish: Strange behaviour in pawn ending

[Rocky640]

Try this with latest master (Simplify IID)

I made the experiment using an Abrok download, but same result with local compiles
http://abrok.eu/stockfish/builds/5596492f6ed72ebc52a4d0f65bed483568e48918/win64modern/stockfish_16081908_x64_modern.exe

It is very basic 3 men draw KPk position.
Something really strange happens at depth 2, * the score jumps to 39.77*
and this problem appears since April 30, 2016

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 3

info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 9000 tbhits 0 time 1 pv
c5c4
info depth 2 seldepth 2 multipv 1 score cp 3977 nodes 42 nps 21000 tbhits 0 time
2 pv c6d5 c3b3
info depth 3 seldepth 4 multipv 1 score cp 0 nodes 122 nps 61000 tbhits 0 time 2
pv c6d5 c3d3 c5c4 d3e2
bestmove c6d5 ponder c3d3

Now If I mirror the position, and white to move

Stockfish 190816 64 POPCNT by T. Romstad, M. Costalba, J. Kiiski, G. Linscott
position fen 8/8/2k5/8/2P5/2K5/8/8 w - - 0 9
go depth 20
the problem will happen at depth 14

...
info depth 11 seldepth 11 multipv 1 score cp 0 nodes 8384 nps 1048000 tbhits 0 t
ime 8 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 12 seldepth 12 multipv 1 score cp 7 nodes 14303 nps 1300272 tbhits 0
time 11 pv c4c5 c6b7 c5c6 b7c6 c3b3 c6d6 b3a4 d6c6 a4a5 c6c5 a5a6 c5d4
info depth 13 seldepth 15 multipv 1 score cp 7 nodes 21959 nps 1372437 tbhits 0
time 16 pv c3b4 c6b6 b4a4 b6c5 a4a5 c5c6 a5a6 c6c5 a6b7 c5d4 c4c5 d4c5 b7a6 c5d4
a6b5
info depth 14 seldepth 17 multipv 1 score cp 3977 nodes 27353 nps 1439631 tbhits
0 time 19 pv c3b4 c6b6 c4c5 b6c7 b4b5 c7b7 c5c6 b7c7 b5c5 c7c8 c5b6 c8b8 b6a6 b
8c7 a6b5 c7c8
info depth 15 seldepth 23 multipv 1 score cp 7 nodes 35734 nps 1553652 tbhits 0
time 23 pv c3b4 c6b6 c4c5 b6c7 b4b5 c7b7 c5c6 b7c8 b5b6 c8b8 b6c5 b8c7 c5d5 c7c8
d5c4 c8b8 c4c3 b8c7 c3c2 c7d6 c6c7 d6c7

I also tried same position shifted to other column, or mirrored.
Some does not exhibit the problem, and some behave wrong but slightly differently.

8/8/6k1/8/6P1/6K1/8/8 w - - 0 9
scores goes up to 48.84

8/8/5k2/5p2/8/5K2/8/8 b - - 0 1
39.77

8/8/1k6/1p6/8/1K6/8/8 b - - 0 1
39.77

As far as I can see, the problem started to appear since the following commit,
which was the only commit on that specific day.
However it looks completely unrelated to the problem we are seeing.

Author: Stéphane Nicolet
Date: Sat Apr 30 22:23:22 2016 +0100
Timestamp: 1462051402
Isolated pawn simplification

Is this the compiler which is doing unexpected tricks ?
Or simply a wrong output ?

[lucabrivio]

Something strange is happening in the evaluation:

position fen 8/8/8/2pk4/8/1K6/8/8 b - - 2 2
eval
      Eval term |    White    |    Black    |    Total    
                |   MG    EG  |   MG    EG  |   MG    EG  
----------------+-------------+-------------+-------------
       Material |   ---   --- |   ---   --- |  0.00  0.00 
      Imbalance |   ---   --- |   ---   --- |  0.00  0.00 
          Pawns |   ---   --- |   ---   --- |  0.00  0.00 
        Knights |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
         Bishop |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
          Rooks |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
         Queens |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
       Mobility |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
    King safety |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
        Threats |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
   Passed pawns |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
          Space |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
----------------+-------------+-------------+-------------
          Total |   ---   --- |   ---   --- |  0.00  0.00 

Total Evaluation: -39.77 (white side)

[lucabrivio]

The internal value before conversion to cp is -10261.

[jhellis3]

What is strange? That position (8/8/8/2pk4/8/1K6/8/8 b - - 2 2) is a win
in 16 for black.

If you are getting false known win blips that is likely due to null move.

On Mon, Aug 22, 2016 at 1:00 PM, Luca Brivio [email protected]
wrote:

Something strange is happening in the evaluation:

position fen 8/8/8/2pk4/8/1K6/8/8 b - - 2 2
eval
Eval term | White | Black | Total
| MG EG | MG EG | MG EG
----------------+-------------+-------------+-------------
Material | --- --- | --- --- | 0.00 0.00
Imbalance | --- --- | --- --- | 0.00 0.00
Pawns | --- --- | --- --- | 0.00 0.00
Knights | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
Bishop | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
Rooks | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
Queens | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
Mobility | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
King safety | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
Threats | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
Passed pawns | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
Space | 0.00 0.00 | 0.00 0.00 | 0.00 0.00
----------------+-------------+-------------+-------------
Total | --- --- | --- --- | 0.00 0.00

Total Evaluation: -39.77 (white side)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/official-stockfish/Stockfish/issues/760#issuecomment-241496725,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADihDUxIbjoSpeGRBs5_ERJnT7IhEQiAks5qieO0gaJpZM4Jpb1g
.

[jhellis3]

Yes, known win bonus is 10,000.

On Mon, Aug 22, 2016 at 1:27 PM, Luca Brivio [email protected]
wrote:

The internal value before conversion to cp is -10261.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/official-stockfish/Stockfish/issues/760#issuecomment-241504975,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADihDT2U0pub9au7xuDK_q_Xh8rb1jYNks5qieoSgaJpZM4Jpb1g
.

[lucabrivio]

It is indeed a win, the isolated pawn patch has just unmasked an issue (not really a bug?) with search at low depth...

[lucabrivio]

@jhellis3 So if I understand correctly, you mean that at that iteration the engine evaluates every move (after ...Kd5) as a known loss for black (probably due to null move) and just picks one...

[Rocky640]

Now back to main question, the original position is a draw,

Actually, I found this position while analyzing a more complex ending, which was showing those -39.77 at much higher depths.

Some of the positions I reported will have those "false blips" on consecutive depth 14, 15 and 16.

If it is demonstrated that NULL moves can have those side effects, should we disable NULL moves when in a specialized eval ? In this example, we are calling our own KPK bitbase which is perfectly accurate...no need to NULL move here. And I guess the same applies to syzygy tb positions.

[joergoster]

@Rocky640 Thanks for bringing this up again, Alain.
With only one change in search.cpp:

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1        
eval
      Eval term |    White    |    Black    |    Total    
                |   MG    EG  |   MG    EG  |   MG    EG  
----------------+-------------+-------------+-------------
       Material |   ---   --- |   ---   --- |  0.00  0.00 
      Imbalance |   ---   --- |   ---   --- |  0.00  0.00 
          Pawns |   ---   --- |   ---   --- |  0.00  0.00 
        Knights |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
         Bishop |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
          Rooks |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
         Queens |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
       Mobility |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
    King safety |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
        Threats |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
   Passed pawns |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
          Space |  0.00  0.00 |  0.00  0.00 |  0.00  0.00 
----------------+-------------+-------------+-------------
          Total |   ---   --- |   ---   --- |  0.00  0.00 

Total Evaluation: 0.00 (white side)

go depth 18
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0 time 3 pv c5c4
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 41 nps 10250 tbhits 0 time 4 pv c5c4 c3b2
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 200 nps 40000 tbhits 0 time 5 pv c6b6 c3d3 c5c4 d3e2
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 413 nps 82600 tbhits 0 time 5 pv c6b6 c3d3 c5c4 d3e2
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 779 nps 155800 tbhits 0 time 5 pv c6b6 c3d3 b6a5 d3c2 c5c4
info depth 6 seldepth 6 multipv 1 score cp 0 nodes 1647 nps 329400 tbhits 0 time 5 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 2399 nps 479800 tbhits 0 time 5 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6
info depth 8 seldepth 8 multipv 1 score cp 0 nodes 3654 nps 609000 tbhits 0 time 6 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6 c3d2
info depth 9 seldepth 9 multipv 1 score cp 0 nodes 4829 nps 804833 tbhits 0 time 6 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6 c3d2 b6a5
info depth 10 seldepth 11 multipv 1 score cp 0 nodes 8864 nps 1266285 tbhits 0 time 7 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6 c3d2 b6a5 d2d1
info depth 11 seldepth 11 multipv 1 score cp 0 nodes 12491 nps 1561375 tbhits 0 time 8 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b5 c3d2 b5a5 d2d1 a5b6
info depth 12 seldepth 16 multipv 1 score cp 7 nodes 23262 nps 1938500 tbhits 0 time 12 pv c6d5 c3d3 c5c4 d3c3 d5e5 c3d2 e5d4 d2c2 c4c3 c2c1 d4d3 c1d1 c3c2 d1c1 d3c4 c1c2
info depth 13 seldepth 20 multipv 1 score cp 7 nodes 28380 nps 2183076 tbhits 0 time 13 pv c6d5 c3d3 c5c4 d3c3 d5c5 c3c2 c5d4 c2d2 c4c3 d2c2 d4c4 c2c1 c4d3 c1d1 c3c2 d1c1 d3d4 c1c2
info depth 14 seldepth 20 multipv 1 score cp 7 nodes 32989 nps 2356357 tbhits 0 time 14 pv c6d5 c3d3 c5c4 d3c3 d5c5 c3c2 c5d4 c2d2 c4c3 d2c2 d4c4 c2c1 c4b3 c1b1 c3c2 b1c1 b3a3 c1c2
info depth 15 seldepth 20 multipv 1 score cp 7 nodes 39342 nps 2458875 tbhits 0 time 16 pv c6d5 c3d3 c5c4 d3c3 d5c5 c3c2 c5d4 c2d2 c4c3 d2c2 d4c4 c2c1 c4b3 c1b1 c3c2 b1c1 b3a3 c1c2 a3a2 c2c3
info depth 16 seldepth 22 multipv 1 score cp 7 nodes 47981 nps 2665611 tbhits 0 time 18 pv c6d5 c3d3 c5c4 d3c3 d5c5 c3c2 c5d4 c2d2 c4c3 d2c2 d4c4 c2c1 c4b3 c1b1 c3c2 b1c1 b3a3 c1c2 a3a2 c2c3 a2b1 c3d3
info depth 17 seldepth 22 multipv 1 score cp 7 nodes 55640 nps 2782000 tbhits 0 time 20 pv c6d5 c3d3 c5c4 d3c3 d5c5 c3c2 c5d4 c2d2 c4c3 d2c2 d4c4 c2c1 c4b3 c1b1 c3c2 b1c1 b3a3 c1c2 a3a2 c2c3 a2b1 c3d3
info depth 18 seldepth 22 multipv 1 score cp 7 nodes 65003 nps 2954681 tbhits 0 time 22 pv c6d5 c3d3 c5c4 d3c3 d5c5 c3c2 c5d4 c2d2 c4c3 d2c2 d4c4 c2c1 c4b3 c1b1 c3c2 b1c1 b3a3 c1c2 a3a2 c2c3 a2b1 c3d3
bestmove c6d5 ponder c3d3

Hint: I deactivated one search step. ;-)

I think the cause for this is Late Move Pruning. This is also the reason why you see this odd behaviour at different depths if you shift or flip the position, because it depends on move ordering which moves will get pruned. Deactivate step 13 and try it.
Once we are very low on material (very late endgame), LMP should be switched off. But such a patch would never pass, I guess.

[Kingdefender]

Hello Rocky,
I tried some things in standard Stockfish, such as no eval based futility step 13 if opponent only pawns.

// Futility pruning: parent node
if (   predictedDepth < 7 * ONE_PLY
    && pos.non_pawn_material(~pos.side_to_move())
    && ss->staticEval + 256 + 200 * predictedDepth / ONE_PLY <= alpha)
    continue;

Not enough, problem persists. Also not enough is instead of skipping nullmove altogether in pawn endgames, doing a verification search always. This also was not enough. I have not tried Joerg's solution of skipping step 13 totally.

Rainbow Serpent (old code base june 2016 06 26_039) does not seem affected by second position.

Stockfish 020816 64 BMI2 by T. Romstad, M. Costalba, J. Kiiski, G. Linscott
position fen 8/8/2k5/8/2P5/2K5/8/8 w - - 0 9
go depth 25
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 9000 tbhits 0 time 1 pv c4c5
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 33 nps 16500 tbhits 0 time 2 pv c4c5 c6b5
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 116 nps 58000 tbhits 0 time 2 pv c3b2 c6c5 b2a1
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 252 nps 126000 tbhits 0 time 2 pv c3b2 c6c5 b2a1 c5d6
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 379 nps 189500 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2
info depth 6 seldepth 6 multipv 1 score cp 0 nodes 689 nps 344500 tbhits 0 time 2 pv c3b2 c6d6 b2a1 d6c6 a1b2
info depth 7 seldepth 6 multipv 1 score cp 0 nodes 793 nps 264333 tbhits 0 time 3 pv c3b2 c6d6 b2a1 d6c6 a1b2
info depth 8 seldepth 6 multipv 1 score cp 0 nodes 911 nps 303666 tbhits 0 time 3 pv c3b2 c6d6 b2a1 d6c6 a1b2
info depth 9 seldepth 6 multipv 1 score cp 0 nodes 1202 nps 400666 tbhits 0 time 3 pv c3b2 c6d6 b2c3 d6c6
info depth 10 seldepth 6 multipv 1 score cp 0 nodes 1555 nps 518333 tbhits 0 time 3 pv c3b2 c6d6 b2c3 d6c6
info depth 11 seldepth 6 multipv 1 score cp 0 nodes 2404 nps 601000 tbhits 0 time 4 pv c3b2 c6d6 b2c3 d6c6
info depth 12 seldepth 6 multipv 1 score cp 0 nodes 2707 nps 676750 tbhits 0 time 4 pv c3b2 c6d6 b2c3 d6c6
info depth 13 seldepth 6 multipv 1 score cp 0 nodes 2992 nps 748000 tbhits 0 time 4 pv c3b2 c6d6 b2c3 d6c6
info depth 14 seldepth 6 multipv 1 score cp 0 nodes 3305 nps 826250 tbhits 0 time 4 pv c3b2 c6d6 b2c3 d6c6
info depth 15 seldepth 6 multipv 1 score cp 0 nodes 4077 nps 815400 tbhits 0 time 5 pv c3b2 c6d6 b2c3 d6c6
info depth 16 seldepth 6 multipv 1 score cp 0 nodes 4873 nps 812166 tbhits 0 time 6 pv c3b2 c6d6 b2c3 d6c6
info depth 17 seldepth 6 multipv 1 score cp 0 nodes 5510 nps 918333 tbhits 0 time 6 pv c3b2 c6d6 b2c3 d6c6
info depth 18 seldepth 6 multipv 1 score cp 0 nodes 6338 nps 905428 tbhits 0 time 7 pv c3b2 c6d6 b2c3 d6c6
info depth 19 seldepth 6 multipv 1 score cp 0 nodes 7858 nps 982250 tbhits 0 time 8 pv c3b2 c6d6 b2c3 d6c6
info depth 20 seldepth 6 multipv 1 score cp 0 nodes 8657 nps 1082125 tbhits 0 time 8 pv c3b2 c6d6 b2c3 d6c6
info depth 21 seldepth 6 multipv 1 score cp 0 nodes 10122 nps 1124666 tbhits 0 time 9 pv c3b2 c6d6 b2c3 d6c6
info depth 22 seldepth 6 multipv 1 score cp 0 nodes 11392 nps 1139200 tbhits 0 time 10 pv c3b2 c6d6 b2c3 d6c6
info depth 23 seldepth 6 multipv 1 score cp 0 nodes 13910 nps 1264545 tbhits 0 time 11 pv c3b2 c6d6 b2c3 d6c6
info depth 24 seldepth 6 multipv 1 score cp 0 nodes 16093 nps 1341083 tbhits 0 time 12 pv c3b2 c6d6 b2c3 d6c6
info depth 25 seldepth 35 multipv 1 score cp 7 nodes 80227 nps 2431121 tbhits 0 time 33 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4d5 b7c7 c5c6 c7c8 d5c4 c8b8 c4c5 b8c7 c5b5 c7c8 b5b6 c8b8 c6c7 b8c8 b6b5 c8c7 b5c5 c7d7 c5d5 d7c7 d5e6 c7b8 e6f7 b8c8 f7g7 c8d8 g7f8 d8c8 f8f7
bestmove c3b4 ponder c6b6

Now I'm not sure, but I think some of the Zugzwang problems (at low depths but they seem to persist sometimes like here position two,) could be avoided by doing something about the eval bug. For instance, second position, at low depths everything is fine. Static eval is accurate, because of the KPK base right? Then at higher depths the problem arises, possibly because eval is now accepted alone instead of also static eval. And if eval is based on Zugzwang not being recognized, you have problem. You can not completely eliminate that, but you can do _something_ about it. (It might not even be Zugzwang here, I'm not sure.)

(As an aside here, I am not terribly big fan of Stockfish doing nullmove at depth 1, because the searches at depth 1 can seed verification search later. But I am not sure it really helps, I have not tried the new codebase of Stockfish for Serpent, that does nullmove at depth 1 also. Maybe it did not help against Zugzwang at all, doing a real search at depth 1.)

[joergoster]

@Rocky640 It seems I was wrong and this is not only related to LMP. Only deactivating shallow depth pruning at whole seems to ged rid of these misevaluations. Most likely futility-pruning is also included.
I'm afraid we simply have to live with it.

[Kingdefender]

Hello Joerg,

I think you missed the part about the bug then. You don't have to live with bugs :bug: I thought I reported it already weeks ago but okay, in TalkChess and most people here don't read it. It was vacations.. :sunny: :bikini: :speedboat: I think Ronald got the point though. And I even gave sample code. Well, I did say in my second post I was not sure that the code as now wasn't actually bringing Elo in Stockfish. But on the other hand, honestly think it's just a bug and not a subtle one either. :rotating_light: It has been there for maybe 5, or 6 years or so? Since Stockfish first started to do a static eval in every node, it has been there.

[joergoster]

@Kingdefender Hi Eelco, I must admit I don't understand what the mentioned eval bug should be. And I also fail to see the relevance of your sample code given. In KPK endgame there is no null-move involved.

[joergoster]

In the next few postings I will provide some analyzing done with my no_pruning2 patch.
Here we go.

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 5
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0 time 3 pv c5c4
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 41 nps 10250 tbhits 0 time 4 pv c5c4 c3b2
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 200 nps 50000 tbhits 0 time 4 pv c6b6 c3d3 c5c4 d3e2
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 413 nps 82600 tbhits 0 time 5 pv c6b6 c3d3 c5c4 d3e2
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 779 nps 155800 tbhits 0 time 5 pv c6b6 c3d3 b6a5 d3c2 c5c4
bestmove c6b6 ponder c3d3

[joergoster]

position fen 8/8/2k5/8/2P5/2K5/8/8 w - - 0 9
go depth 20
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 4500 tbhits 0 time 2 pv c4c5
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 35 nps 17500 tbhits 0 time 2 pv c4c5 c6b5
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 146 nps 73000 tbhits 0 time 2 pv c3b2 c6c5 b2a1
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 351 nps 175500 tbhits 0 time 2 pv c3b2 c6c5 b2a1 c5d6
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 694 nps 347000 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2
info depth 6 seldepth 6 multipv 1 score cp 0 nodes 1323 nps 661500 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 1866 nps 933000 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 8 seldepth 7 multipv 1 score cp 0 nodes 2840 nps 1420000 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 9 seldepth 7 multipv 1 score cp 0 nodes 3571 nps 1190333 tbhits 0 time 3 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 10 seldepth 7 multipv 1 score cp 0 nodes 5525 nps 1841666 tbhits 0 time 3 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 11 seldepth 7 multipv 1 score cp 0 nodes 7462 nps 1865500 tbhits 0 time 4 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 12 seldepth 15 multipv 1 score cp 8 nodes 17421 nps 2488714 tbhits 0 time 7 pv c3b4 c6b6 c4c5 b6c6 b4a5 c6b7 a5b5 b7c7 c5c6 c7c8 c6c7 c8c7 b5a6 c7c6 a6a7
info depth 13 seldepth 18 multipv 1 score cp 8 nodes 22366 nps 2485111 tbhits 0 time 9 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 c6c7 c8c7 b5c5 c7c8 c5c6 c8b8 c6b6 b8c8
info depth 14 seldepth 18 multipv 1 score cp 8 nodes 24905 nps 2767222 tbhits 0 time 9 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 c6c7 c8c7 b5c5 c7c8 c5c6 c8b8 c6b6 b8c8
info depth 15 seldepth 18 multipv 1 score cp 8 nodes 31191 nps 2835545 tbhits 0 time 11 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 c6c7 c8c7 b5c5 c7c8 c5c6 c8b8 c6b6 b8c8
info depth 16 seldepth 19 multipv 1 score cp 8 nodes 38573 nps 2755214 tbhits 0 time 14 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 c6c7 c8c7 b5c5 c7c8 c5c6 c8b8 c6b6 b8c8 b6a7
info depth 17 seldepth 20 multipv 1 score cp 8 nodes 44583 nps 2972200 tbhits 0 time 15 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 c6c7 c8c7 b5c5 c7c8 c5c6 c8b8 c6b6 b8c8 b6a7 c8c7
info depth 18 seldepth 21 multipv 1 score cp 8 nodes 53029 nps 2946055 tbhits 0 time 18 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 b5b6 c8b8 c6c7 b8c8 b6b5 c8c7 b5c5 c7c8 c5c6 c8b8 c6b6
info depth 19 seldepth 22 multipv 1 score cp 8 nodes 67769 nps 3080409 tbhits 0 time 22 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 b5b6 c8b8 c6c7 b8c8 b6b5 c8c7 b5c5 c7c8 c5c6 c8b8 c6b6 b8c8
info depth 20 seldepth 30 multipv 1 score cp 0 nodes 94571 nps 3152366 tbhits 0 time 30 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4b5 b7c7 c5c6 c7c8 b5b6 c8b8 b6a6 b8c7 a6b5
bestmove c3b4 ponder c6b6

[joergoster]

position fen 8/8/6k1/8/6P1/6K1/8/8 w - - 0 9 
go depth 30
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 4500 tbhits 0 time 2 pv g4g5
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 35 nps 17500 tbhits 0 time 2 pv g4g5 g6f5
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 138 nps 69000 tbhits 0 time 2 pv g3f2 g6g5 f2e1
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 316 nps 158000 tbhits 0 time 2 pv g3f2 g6g5 f2e1 g5h6
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 611 nps 305500 tbhits 0 time 2 pv g3f2 g6g5 f2g3 g5h6 g3f2
info depth 6 seldepth 6 multipv 1 score cp 0 nodes 1212 nps 606000 tbhits 0 time 2 pv g3f2 g6g5 f2g3 g5h6 g3f2 h6g5
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 1665 nps 832500 tbhits 0 time 2 pv g3f2 g6g5 f2g3 g5h6 g3f2 h6g5
info depth 8 seldepth 7 multipv 1 score cp 0 nodes 2509 nps 836333 tbhits 0 time 3 pv g3f2 g6g5 f2g3 g5h6 g3f2 h6g5
info depth 9 seldepth 7 multipv 1 score cp 0 nodes 3564 nps 1188000 tbhits 0 time 3 pv g3f2 g6g5 f2g3 g5h6 g3f2 h6g5
info depth 10 seldepth 7 multipv 1 score cp 0 nodes 5279 nps 1759666 tbhits 0 time 3 pv g3f2 g6g5 f2g3 g5h6 g3f2 h6g5
info depth 11 seldepth 13 multipv 1 score cp 0 nodes 10810 nps 2162000 tbhits 0 time 5 pv g3f2 g6g5 f2g3 g5h6 g3f2 h6g5
info depth 12 seldepth 13 multipv 1 score cp 0 nodes 12074 nps 2012333 tbhits 0 time 6 pv g3f2 g6g5 f2g3 g5h6 g3f2 h6g5
info depth 13 seldepth 15 multipv 1 score cp 8 nodes 18597 nps 2324625 tbhits 0 time 8 pv g3f4 g6f6 g4g5 f6g6 f4e3 g6f7 g5g6 f7f8 g6g7 f8g8 e3f2 g8g7 f2e1 g7g6 e1d2
info depth 14 seldepth 16 multipv 1 score cp 8 nodes 24376 nps 2708444 tbhits 0 time 9 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g5g6 f7g7 g4g5 g7g8 g5f4 g8g7 f4f5 g7g8 g6g7 g8g7
info depth 15 seldepth 18 multipv 1 score cp 8 nodes 30394 nps 2763090 tbhits 0 time 11 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g6g7 g8g7 g5h5 g7f8
info depth 16 seldepth 21 multipv 1 score cp 8 nodes 37576 nps 2684000 tbhits 0 time 14 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g6g7 g8g7 g5h5 g7f8 h5g6 f8e7 g6h6
info depth 17 seldepth 24 multipv 1 score cp 0 nodes 51084 nps 2838000 tbhits 0 time 18 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 18 seldepth 24 multipv 1 score cp 0 nodes 57026 nps 2851300 tbhits 0 time 20 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 19 seldepth 24 multipv 1 score cp 0 nodes 61732 nps 2939619 tbhits 0 time 21 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 20 seldepth 24 multipv 1 score cp 0 nodes 68430 nps 2975217 tbhits 0 time 23 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 21 seldepth 24 multipv 1 score cp 0 nodes 74784 nps 2991360 tbhits 0 time 25 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 22 seldepth 24 multipv 1 score cp 0 nodes 84039 nps 3001392 tbhits 0 time 28 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 23 seldepth 24 multipv 1 score cp 0 nodes 93832 nps 3026838 tbhits 0 time 31 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 24 seldepth 24 multipv 1 score cp 0 nodes 105482 nps 3013771 tbhits 0 time 35 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 25 seldepth 24 multipv 1 score cp 0 nodes 119706 nps 3069384 tbhits 0 time 39 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 26 seldepth 24 multipv 1 score cp 0 nodes 153267 nps 3127897 tbhits 0 time 49 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 27 seldepth 24 multipv 1 score cp 0 nodes 188795 nps 3199915 tbhits 0 time 59 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 28 seldepth 24 multipv 1 score cp 0 nodes 237332 nps 3296277 tbhits 0 time 72 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 29 seldepth 24 multipv 1 score cp 0 nodes 308562 nps 3353934 tbhits 0 time 92 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
info depth 30 seldepth 24 multipv 1 score cp 0 nodes 393706 nps 3394017 tbhits 0 time 116 pv g3f4 g6f6 g4g5 f6g6 f4g4 g6f7 g4f5 f7g7 g5g6 g7g8 f5f4 g8g7 f4g5 g7g8 g5f4
bestmove g3f4 ponder g6f6

[joergoster]

position fen 8/8/5k2/5p2/8/5K2/8/8 b - - 0 1 
go depth 30
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 4500 tbhits 0 time 2 pv f5f4
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 41 nps 20500 tbhits 0 time 2 pv f5f4 f3e2
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 200 nps 100000 tbhits 0 time 2 pv f6e6 f3g3 f5f4 g3h2
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 413 nps 206500 tbhits 0 time 2 pv f6e6 f3g3 f5f4 g3h2
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 784 nps 392000 tbhits 0 time 2 pv f6e6 f3g3 e6d5 g3f2 f5f4
info depth 6 seldepth 6 multipv 1 score cp 0 nodes 1370 nps 685000 tbhits 0 time 2 pv f6e6 f3g3 e6d5 g3f2 f5f4 f2f3
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 1990 nps 995000 tbhits 0 time 2 pv f6e6 f3g3 e6d5 g3f2 f5f4 f2f3 d5e6
info depth 8 seldepth 8 multipv 1 score cp 0 nodes 3204 nps 1068000 tbhits 0 time 3 pv f6e6 f3g3 e6d5 g3f2 f5f4 f2f3 d5e6 f3g2
info depth 9 seldepth 9 multipv 1 score cp 0 nodes 3825 nps 1275000 tbhits 0 time 3 pv f6e6 f3g3 e6d5 g3f2 f5f4 f2f3 d5e6 f3g2 e6d5
info depth 10 seldepth 11 multipv 1 score cp 0 nodes 6864 nps 1716000 tbhits 0 time 4 pv f6e6 f3g3 e6d5 g3f3 f5f4 f3e2 d5e6 e2f3 e6d5
info depth 11 seldepth 13 multipv 1 score cp 8 nodes 13320 nps 2220000 tbhits 0 time 6 pv f5f4 f3e4 f4f3 e4f3 f6e5 f3g2 e5d6 g2g1 d6c7 g1f1 c7b7 f1g2
info depth 12 seldepth 13 multipv 1 score cp 8 nodes 16373 nps 2339000 tbhits 0 time 7 pv f5f4 f3e4 f6f7 e4d4 f4f3 d4d3 f7e6 d3d2 e6d5 d2e1 d5e6 e1d1
info depth 13 seldepth 17 multipv 1 score cp 8 nodes 23615 nps 2623888 tbhits 0 time 9 pv f6e6 f3g3 e6d5 g3f4 d5d4 f4f3 d4e5 f3e3 f5f4 e3f3 e5f5 f3f2 f5e4 f2e2 f4f3 e2f2 e4f4
info depth 14 seldepth 18 multipv 1 score cp 8 nodes 29320 nps 2665454 tbhits 0 time 11 pv f6g5 f3g3 f5f4 g3h2 g5f5 h2g2 f5e4 g2f2 f4f3 f2f1 e4e5 f1g1 e5f5 g1f1 f5e4 f1f2 e4f4
info depth 15 seldepth 20 multipv 1 score cp 8 nodes 33800 nps 2816666 tbhits 0 time 12 pv f6g5 f3g3 f5f4 g3h2 g5f5 h2g2 f5e4 g2f2 f4f3 f2f1 e4e3 f1e1 f3f2 e1f1 e3d2 f1f2 d2d1 f2f3 d1e1 f3g3
info depth 16 seldepth 24 multipv 1 score cp 8 nodes 39490 nps 2820714 tbhits 0 time 14 pv f6g5 f3g3 f5f4 g3h2 g5f5 h2g2 f5e4 g2f2 f4f3 f2f1 e4e3 f1e1 f3f2 e1f1 e3d3 f1f2 d3d2 f2f3 d2e1 f3g3 e1e2 g3g2 e2e3
info depth 17 seldepth 24 multipv 1 score cp 0 nodes 53256 nps 2958666 tbhits 0 time 18 pv f6g5 f3g3 f5f4 g3h2 g5f5 h2g2 f5e4 g2f2 f4f3 f2f1 e4f5 f1g1 f5e5 g1f2 e5f4 f2f1 f4f5
info depth 18 seldepth 24 multipv 1 score cp 0 nodes 55692 nps 2931157 tbhits 0 time 19 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5e4 g2f2 f4f3 f2f1 e4f5 f1g1 f5e5 g1f2 e5f4 f2f1 f4e4 f1f2 e4f4
info depth 19 seldepth 24 multipv 1 score cp 0 nodes 59381 nps 2969050 tbhits 0 time 20 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5e4 g2f2 f4f3 f2f1 e4f4 f1f2 f4g4 f2f1 g4f5 f1g1 f5g4 g1f1
info depth 20 seldepth 24 multipv 1 score cp 0 nodes 64312 nps 2923272 tbhits 0 time 22 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4f5 f1g1 f5g4 g1f1
info depth 21 seldepth 24 multipv 1 score cp 0 nodes 66676 nps 2898956 tbhits 0 time 23 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4f5 f1g1 f5g4 g1f1
info depth 22 seldepth 24 multipv 1 score cp 0 nodes 72410 nps 3017083 tbhits 0 time 24 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4f5 f1g1 f5g4 g1f1
info depth 23 seldepth 24 multipv 1 score cp 0 nodes 77252 nps 2971230 tbhits 0 time 26 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4f5 f1g1 f5g4 g1f1
info depth 24 seldepth 24 multipv 1 score cp 0 nodes 83264 nps 2973714 tbhits 0 time 28 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4f5 f1g1 f5g4 g1f1
info depth 25 seldepth 24 multipv 1 score cp 0 nodes 99580 nps 3017575 tbhits 0 time 33 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4f5 f1g1 f5g5 g1f1 g5f4 f1f2 f4g4
info depth 26 seldepth 24 multipv 1 score cp 0 nodes 113096 nps 3056648 tbhits 0 time 37 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4g5 f1g1 g5f5 g1f1 f5e4 f1f2 e4f4 f2f1 f4g5
info depth 27 seldepth 24 multipv 1 score cp 0 nodes 120691 nps 3094641 tbhits 0 time 39 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4g5 f1g1 g5f5 g1f1 f5e4 f1f2 e4f4 f2f1 f4g5
info depth 28 seldepth 24 multipv 1 score cp 0 nodes 132943 nps 3091697 tbhits 0 time 43 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4g5 f1g1 g5f5 g1f1 f5e4 f1f2 e4f4 f2f1 f4g5
info depth 29 seldepth 24 multipv 1 score cp 0 nodes 148820 nps 3166382 tbhits 0 time 47 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4g5 f1g1 g5f5 g1f1 f5e4 f1f2 e4f4 f2f1 f4g5
info depth 30 seldepth 24 multipv 1 score cp 0 nodes 170286 nps 3153444 tbhits 0 time 54 pv f6g5 f3g3 f5f4 g3f3 g5f5 f3g2 f5g4 g2f2 f4f3 f2f1 g4g5 f1g1 g5f5 g1f1 f5e4 f1f2 e4f4 f2f1 f4g5
bestmove f6g5 ponder f3g3

[joergoster]

A position reported by Uri:

position fen 8/8/1k3K2/8/3p4/3P4/8/8 w - - 0 78
go depth 30
info depth 1 seldepth 1 multipv 1 score cp 12 nodes 8 nps 4000 tbhits 0 time 2 pv f6e5
info depth 2 seldepth 2 multipv 1 score cp 16 nodes 33 nps 16500 tbhits 0 time 2 pv f6e5 b6c5
info depth 3 seldepth 3 multipv 1 score cp 3 nodes 123 nps 61500 tbhits 0 time 2 pv f6e5 b6c5 e5e4
info depth 4 seldepth 4 multipv 1 score cp 19 nodes 351 nps 175500 tbhits 0 time 2 pv f6e5 b6c6 e5e4 c6c5
info depth 5 seldepth 5 multipv 1 score cp 11 nodes 906 nps 453000 tbhits 0 time 2 pv f6f5 b6b5 f5f4 b5b4 f4e4
info depth 6 seldepth 6 multipv 1 score cp 25 nodes 1149 nps 574500 tbhits 0 time 2 pv f6f5 b6b5 f5f4 b5b4 f4e5 b4c5
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 2009 nps 669666 tbhits 0 time 3 pv f6f5 b6b5 f5e4 b5c5 e4e5 c5c6 e5e4
info depth 8 seldepth 8 multipv 1 score cp 0 nodes 2779 nps 926333 tbhits 0 time 3 pv f6f5 b6b5 f5f4 b5b6 f4e4 b6c5 e4e5 c5c6
info depth 9 seldepth 10 multipv 1 score cp 3 nodes 3474 nps 1158000 tbhits 0 time 3 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e2 c6c5 e2d2 c5d5
info depth 10 seldepth 12 multipv 1 score cp 4 nodes 4711 nps 1177750 tbhits 0 time 4 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e2 c6c5 e2d2 c5d6 d2c2 d6d5
info depth 11 seldepth 13 multipv 1 score cp 0 nodes 6469 nps 1617250 tbhits 0 time 4 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 12 seldepth 13 multipv 1 score cp 0 nodes 7865 nps 1573000 tbhits 0 time 5 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 13 seldepth 13 multipv 1 score cp 0 nodes 9679 nps 1935800 tbhits 0 time 5 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 14 seldepth 13 multipv 1 score cp 0 nodes 11531 nps 1921833 tbhits 0 time 6 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 15 seldepth 13 multipv 1 score cp 0 nodes 12339 nps 2056500 tbhits 0 time 6 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 16 seldepth 13 multipv 1 score cp 0 nodes 13830 nps 2305000 tbhits 0 time 6 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 17 seldepth 13 multipv 1 score cp 0 nodes 15488 nps 2212571 tbhits 0 time 7 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 18 seldepth 13 multipv 1 score cp 0 nodes 18556 nps 2319500 tbhits 0 time 8 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 19 seldepth 13 multipv 1 score cp 0 nodes 22872 nps 2541333 tbhits 0 time 9 pv f6f5 b6b5 f5f4 b5b6 f4f3 b6c6 f3e4 c6c5 e4e5 c5c6 e5e4
info depth 20 seldepth 21 multipv 1 score cp 8 nodes 31198 nps 2599833 tbhits 0 time 12 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5d5 d8d7 d5e4 d7c8 d6d7 c8d8 e4d4
info depth 21 seldepth 27 multipv 1 score cp 8 nodes 41212 nps 2747466 tbhits 0 time 15 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5d5 d8d7 d5c5 d7d8 c5c6 d8c8 d6d7 c8d8 c6d5 d8e7 d5e4 e7d8 e4d4
info depth 22 seldepth 30 multipv 1 score cp 0 nodes 50786 nps 2821444 tbhits 0 time 18 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5d5 d8d7 d5c5 d7d8 c5d5
info depth 23 seldepth 30 multipv 1 score cp 0 nodes 57568 nps 2741333 tbhits 0 time 21 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
info depth 24 seldepth 30 multipv 1 score cp 0 nodes 66109 nps 2874304 tbhits 0 time 23 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
info depth 25 seldepth 30 multipv 1 score cp 0 nodes 73896 nps 2842153 tbhits 0 time 26 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
info depth 26 seldepth 30 multipv 1 score cp 0 nodes 81122 nps 2897214 tbhits 0 time 28 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
info depth 27 seldepth 30 multipv 1 score cp 0 nodes 95631 nps 2897909 tbhits 0 time 33 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
info depth 28 seldepth 30 multipv 1 score cp 0 nodes 106486 nps 2957944 tbhits 0 time 36 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
info depth 29 seldepth 30 multipv 1 score cp 0 nodes 127654 nps 2968697 tbhits 0 time 43 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
info depth 30 seldepth 30 multipv 1 score cp 0 nodes 142510 nps 2968958 tbhits 0 time 48 pv f6e5 b6c6 e5d4 c6d6 d4e4 d6e6 d3d4 e6d6 d4d5 d6e7 e4e5 e7d7 d5d6 d7d8 e5e4 d8e8 e4d4 e8d7 d4d5 d7d8 d5e5 d8d7 e5d5
bestmove f6e5 ponder b6c6

[Kingdefender]

@Kingdefender Hi Eelco, I must admit I don't understand what the mentioned eval bug should be. And I also fail to see the relevance of your sample code given. In KPK endgame there is no null-move involved.

Hi Joerg,

Sorry for the late reply. You are right that in KPK we don't do Nullmove or Futility pruning at the top so there can't be any eval problem in those two places. (That leaves of the places where eval is used only Razoring but the potential problem there is already taken care of by condition that there is no ttMove. So eval can never be a lower bound TT result.)

So I don't relly know which difference it is thatcauses RS to have less problems with position two but it can't be the supposed eval problem. But I still have to explain what I meant. It is not complicated I think; only you could be a little more careful I think with the conditions under which you replace the static eval with a bound. We replace static eval with a lower bound if it is higher than static eval. That is correct, the only problem could be if it is higher but still so low that you would fall into razoring with it. That is not a big problem because eval would have to be very far below alpha and it also can't be a lower bound in practice because then there would also be a ttMove stored.

That leaves of step 6, 7, 8, where eval is used only the last two and there remains a slight problem if eval is an upper bound but still high enough to pass alpha. For instance we could now go into nullmove with this eval but there apparently already is a search result that said the node was below alpha. It must be a case in which alpha was previously higher, and even then the previous search will not be better at detecting Zugzwang unless for instance step 7 or 8 was previously skipped, but still, we did go below alpha in the past. I admit this will probably only be rare cases, but that also means you will not often skip 8.) nullmove or 7.) futility pruning at the top because of it.

Well, that was my explanation really. Thinking about it, I am not sure anymore now why I thought it was important. But it certainly will not cost very much either. And it was a functional change. But not convinced anymore this will really help against Zugzwang.

I will put the code up for reference. Sorry it took so long!

[snicolet]

I have verified that SF8 (and current SF9dev) still exhibit the same behaviour for the initial position of this threat given by Alain:

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1 go depth 2

Since this search at depth 2 only takes 42 nodes to complete, it should be possible to print in the console the successive evaluations of the search and understand the bug "by pen and paper".

[joergoster]

@snicolet This patch https://github.com/joergoster/Stockfish/compare/ab26c61...54bf3ea of mine solves this issue for me. And testing against a bunch of foreign opponents didn't show a severe regression.
But we seem to be losing some elo in self-testing. http://tests.stockfishchess.org/tests/view/57f409540ebc59038170f968

[joergoster]

@snicolet Basically, only one line of code is needed to solve this issue.

          && pos.non_pawn_material(pos.side_to_move())

This omits shallow pruning for endings with only pawns. I will submit a non-regression test with sprt[-3, 1] bounds.

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 2
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 4500 tbhits 0 time 2 pv c5c4
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 41 nps 20500 tbhits 0 time 2 pv c5c4 c3b2
bestmove c5c4 ponder c3b2

[mcostalba]

@joergoster can you please explain what is the root cause of this issue and how your patch fixes it?

[joergoster]

@mcostalba Like I wrote further above, the root cause seems to be Late Move Pruning.
For example, this position:

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0 time 3 pv c5c4
info depth 2 seldepth 2 multipv 1 score cp 4133 nodes 42 nps 10500 tbhits 0 time 4 pv c6d5 c3b3
info depth 3 seldepth 4 multipv 1 score cp 0 nodes 116 nps 29000 tbhits 0 time 4 pv c6d5 c3d3 c5c4 d3e2
info depth 4 seldepth 5 multipv 1 score cp 0 nodes 274 nps 68500 tbhits 0 time 4 pv c6d5 c3d3 c5c4 d3e2 d5d4
info depth 5 seldepth 6 multipv 1 score cp 0 nodes 435 nps 108750 tbhits 0 time 4 pv c6d5 c3d3 c5c4 d3e2 d5d4 e2d2
info depth 6 seldepth 7 multipv 1 score cp 0 nodes 863 nps 215750 tbhits 0 time 4 pv c6d5 c3d3 c5c4 d3e2 d5d4 e2d2 d4d5
info depth 7 seldepth 8 multipv 1 score cp 0 nodes 1560 nps 312000 tbhits 0 time 5 pv c6d5 c3d3 c5c4 d3e2 d5d4 e2d2 d4d5 d2e2
info depth 8 seldepth 9 multipv 1 score cp 0 nodes 2372 nps 474400 tbhits 0 time 5 pv c6d5 c3d3 c5c4 d3e2 d5d4 e2d2 d4d5 d2e2
info depth 9 seldepth 9 multipv 1 score cp 0 nodes 3180 nps 530000 tbhits 0 time 6 pv c6d5 c3d3 c5c4 d3e2 d5d4 e2d2 d4d5 d2e2
info depth 10 seldepth 9 multipv 1 score cp 0 nodes 4594 nps 765666 tbhits 0 time 6 pv c6d5 c3d3 c5c4 d3e2 d5d4 e2d2 d4d5 d2e2
bestmove c6d5 ponder c3d3

But when I flip the position, there is no wrong eval. I suspect because of different move ordering other moves get pruned.

flip
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 9000 tbhits 0 time 1 pv c4c5
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 33 nps 33000 tbhits 0 time 1 pv c4c5 c6b5
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 97 nps 97000 tbhits 0 time 1 pv c4c5 c6b5 c5c6
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 220 nps 220000 tbhits 0 time 1 pv c4c5 c6b5 c5c6 b5b6
info depth 5 seldepth 6 multipv 1 score cp 0 nodes 455 nps 455000 tbhits 0 time 1 pv c3b4 c6b6 c4c5 b6a6 c5c6 a6b6
info depth 6 seldepth 7 multipv 1 score cp 0 nodes 1139 nps 569500 tbhits 0 time 2 pv c3b4 c6b6 c4c5 b6a6 c5c6 a6b6 b4a3
info depth 7 seldepth 8 multipv 1 score cp 0 nodes 1709 nps 854500 tbhits 0 time 2 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c5c6 b7b6
info depth 8 seldepth 9 multipv 1 score cp 0 nodes 2547 nps 1273500 tbhits 0 time 2 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4d5 b7c8 c5c6
info depth 9 seldepth 11 multipv 1 score cp 8 nodes 4845 nps 1615000 tbhits 0 time 3 pv c4c5 c6d7 c5c6 d7d8 c3c4 d8c7 c4c5 c7c8 c6c7
info depth 10 seldepth 11 multipv 1 score cp 8 nodes 7178 nps 2392666 tbhits 0 time 3 pv c3b4 c6b6 c4c5 b6c6 b4c4 c6b7 c4d5 b7c7 c5c6 c7c8 d5c4
bestmove c3b4 ponder c6b6

And indeed, if I only deactivate move count pruning with

      moveCountPruning =   depth < 16 * ONE_PLY
                        && pos.non_pawn_material(pos.side_to_move())
                        && moveCount >= FutilityMoveCounts[improving][depth / ONE_PLY];

the problem seems to be gone at first glance.

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0 time 3 pv c5c4
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 41 nps 10250 tbhits 0 time 4 pv c5c4 c3b2
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 139 nps 34750 tbhits 0 time 4 pv c5c4 c3b2 c4c3 b2b1
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 271 nps 67750 tbhits 0 time 4 pv c5c4 c3b2 c4c3 b2b1
info depth 5 seldepth 6 multipv 1 score cp 0 nodes 572 nps 143000 tbhits 0 time 4 pv c6b5 c3b3 c5c4 b3b2 c4c3 b2b3
info depth 6 seldepth 7 multipv 1 score cp 0 nodes 1428 nps 285600 tbhits 0 time 5 pv c6b5 c3b3 c5c4 b3b2 b5a4 b2c2 c4c3
info depth 7 seldepth 8 multipv 1 score cp 0 nodes 2272 nps 454400 tbhits 0 time 5 pv c6b5 c3b3 c5c4 b3c2 b5a4 c2c3 a4a3 c3c2
info depth 8 seldepth 9 multipv 1 score cp 0 nodes 3309 nps 661800 tbhits 0 time 5 pv c6b5 c3b3 c5c4 b3c2 b5c5 c2d1 c4c3 d1c1 c3c2
info depth 9 seldepth 11 multipv 1 score cp 0 nodes 4623 nps 770500 tbhits 0 time 6 pv c6b5 c3b3 c5c4 b3c2 b5c5 c2d1 c4c3 d1c2 c5c4 c2c1 c3c2
info depth 10 seldepth 12 multipv 1 score cp 8 nodes 6373 nps 1062166 tbhits 0 time 6 pv c6b5 c3b3 c5c4 b3c2 c4c3 c2c3 b5c5 c3d3 c5b4 d3c2 b4c4
bestmove c6b5 ponder c3b3

But there are positions where this is not sufficient. (next post.)

[joergoster]

For example, this position posted at Talkchess http://talkchess.com/forum/viewtopic.php?t=62369

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

With only movecount pruning deactivated:

info depth 35 seldepth 71 multipv 1 score cp -206 nodes 84459973 nps 2815238 hashfull 999 tbhits 0 time 30001 pv f2f4 f6e6
bestmove f2f4 ponder f6e6

SF still loses track of the draw score.
Only deactivating step 13 at whole (current test running in fishtest) solves it:

info depth 37 seldepth 48 multipv 1 score cp 0 nodes 112332189 nps 3744281 hashfull 999 tbhits 0 time 30001 pv f2f4 f6e6 d3d4 b7b5 g2g4 e6f7 d4c5 g7g5 c5b5 g5f4 b5c4 f5g4 h3g4 f7g6 c4d3 g6g5 d3e2 g5g4 e2f2 f4f3 f2f1 g4f4 f1f2 f4e4 f2f1 e4f5 f1e1 f5g5 e1f2 g5f4 f2f1 f4g4 f1f2 g4f4
bestmove f2f4 ponder f6e6

I didn't investigate further which other pruning method in step 13 (futility pruning, countermove based pruning, SEE pruning) is causing this. Do I have to?
But I guess we don't want to add 1, 2 or even 3 additional conditions?

[Stefano80]

Hi,

actually, you're testing the patch with [-3, 1] bounds. Why? I mean: we now know that some complex endings sometimes get some crazy evaluations and your patch solves (some of) those.

I still think that if your patch adds code and does not solve a bug but just improves evaluation in a class of endings it should be tested with [0, 5].

Otherwise, one could just submit [-3, 1] patches for any code tweak which could help in fortresses, or opposite bishop endings or whenever you can prove to have some wrong evaluations...

[mcostalba]

@joergoster I agree with @Stefano80 here. Indeed the reason of my question was to understand if you had found a specific issue or bug, but LMR pruning is _not_ a bug. It is simply the way it works. Being a statistical method, as all the pruning facilities, sometime it works, sometime it does not and when it happens then maybe a strange evaluation appears, but this is not a bug, it is something we have to accept considering that usually it works and, indeed, on average it gives a big ELO boost.

Due to the statistics at the base of engines behaviors, you will always find some position that shows an odd evaluation, and, for the same reason, an ad-hoc tweak to silence that particular position, firstly will not fix the general problem (because you will always have other positions that show odd output), secondly it will possibly create a new side effect in another position that was working ok till that moment.

The only way for a patch that operates on the statistical behavior of the engine, to be merged is that it proves stronger in the average case, i.e. according to our rules, it passes SPRT[0, 5].

So not only I invite you to fix SPRT bounds of your test, but, now that we know that this issue is simply due to LMR, I am going to close this one as non issue.

[joergoster]

@Stefano80 I agree that this is not a bugfix. I would say this is unwanted behaviour. And it really looks very ugly. And as shown in the mentioned thread on talkchess, it can lead to grosse misevaluations and wrong move choice.
I just see Marco's reponse where he agrees with you. That is fine with me and I will resubmit with default bounds. Of course, test will fail.
I think this case is very similar to adding endgame knowledge which will almost always show no measurable elo gain, unfortunately.

[Rocky640]

@Stefano80 and @mcostalba
Please consider that we are talking about a very basic 3 men draw KPk position for which we should have perfect knowledge.

This is not exactly what the current test of joerg is doing,
but can we agree that we should skip LMR pruning (which seems to have known side effects)
or whatever sensible solution which would apply when we have perfect knowledge ?

a) using tablebase and we have a tb for the current position ?
b) using our perfect KPk database

[Stefano80]

@joergoster : it is unwanted and it looks ugly, I agree. Nevertheless, I think that the real problem resides with our testing framework. If we would have a good collection of endgames, we could test all these deuglifications in a statistical context... we really should do it.

[Stefano80]

@Rocky640 : well, what we could do is to assimilate TB and positions with perfect knowledge. Which means: in step 4a of search we could ask whether we have a 3-men position (for which we always have perfect knowledge) and then return a value from our specialized eval, as if it would be a TB probe. This will also never pass [0, 5] but I personally would feel more comfortable with this kind of test being tested as [-3, 1] since it would fix a proven inconsistency (we treat two cases of perfect knowledge differently).

[Kingdefender]

@Stefano: I wanted to say something similar but you said it much more precisely than I could have! In particular if with perfect knowledge static eval is a draw, search should never alter this result. The other case unfortunately is not true because of the 50 move rule. Bitbases do not know 50 move rule, so you can not totally do the same as with Syzygy bases I think...

Treating KPk as a Tablebase result woud also prevent issues in step 5 where you can replace static eval with a search result, Fail Low or Fail High, even if the static eval is a proven draw.

[joergoster]

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

[joergoster]

@mcostalba @Stefano80 There is one flaw in your reasoning, of course. :-)
We already do the exact same thing in futility and null move pruning. And for good reason!

See also https://github.com/official-stockfish/Stockfish/pull/713

[joergoster]

OK, I was curious to see the effect of probing the KPK bitbase during the search. I've put it right after the TB lookup.

    // Step 4b. KPK bitbase probe
    if (   !rootNode
        &&  depth <= 3 * ONE_PLY
        &&  pos.count<PAWN>(WHITE) + pos.count<PAWN>(BLACK) == 1
        && !pos.non_pawn_material(WHITE)
        && !pos.non_pawn_material(BLACK))
    {
        me = Material::probe(pos);
        return me->evaluate(pos);
    }

With an amazing result:

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0 time 3 pv c5c4
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 17 nps 5666 tbhits 0 time 3 pv c5c4
info depth 3 seldepth 2 multipv 1 score cp 0 nodes 25 nps 8333 tbhits 0 time 3 pv c5c4
info depth 4 seldepth 2 multipv 1 score cp 0 nodes 33 nps 11000 tbhits 0 time 3 pv c5c4
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 90 nps 30000 tbhits 0 time 3 pv c6b5 c3b3
info depth 6 seldepth 5 multipv 1 score cp 0 nodes 223 nps 55750 tbhits 0 time 4 pv c6b5 c3b3 c5c4 b3a3
info depth 7 seldepth 6 multipv 1 score cp 0 nodes 435 nps 108750 tbhits 0 time 4 pv c6b5 c3b3 c5c4 b3a3 b5c5
info depth 8 seldepth 7 multipv 1 score cp 0 nodes 859 nps 214750 tbhits 0 time 4 pv c6b5 c3b3 c5c4 b3a3 b5c5 a3b2
info depth 9 seldepth 9 multipv 1 score cp 0 nodes 1570 nps 392500 tbhits 0 time 4 pv c6b5 c3b3 c5c4 b3a3 b5c5 a3b2 c5b5 b2a3
info depth 10 seldepth 9 multipv 1 score cp 0 nodes 3568 nps 713600 tbhits 0 time 5 pv c6b5 c3b3 c5c4 b3a3 b5c5 a3b2 c5b5 b2a3
bestmove c6b5 ponder c3b3

flip position

flip
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 9000 tbhits 0 time 1 pv c4c5
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 17 nps 17000 tbhits 0 time 1 pv c4c5
info depth 3 seldepth 2 multipv 1 score cp 0 nodes 25 nps 25000 tbhits 0 time 1 pv c4c5
info depth 4 seldepth 2 multipv 1 score cp 0 nodes 33 nps 33000 tbhits 0 time 1 pv c4c5
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 88 nps 88000 tbhits 0 time 1 pv c3b2 c6c5
info depth 6 seldepth 5 multipv 1 score cp 0 nodes 226 nps 226000 tbhits 0 time 1 pv c3b2 c6c5 b2a1
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 549 nps 549000 tbhits 0 time 1 pv c3b2 c6c5 b2c3 c5c6
info depth 8 seldepth 7 multipv 1 score cp 0 nodes 1130 nps 1130000 tbhits 0 time 1 pv c3b2 c6c5 b2c3 c5c6
info depth 9 seldepth 7 multipv 1 score cp 0 nodes 1460 nps 1460000 tbhits 0 time 1 pv c3b2 c6c5 b2c3 c5c6
info depth 10 seldepth 7 multipv 1 score cp 0 nodes 1789 nps 894500 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5c6
bestmove c3b2 ponder c6c5

It also works perfectly for the position from Talkchess:

info depth 39 seldepth 36 multipv 1 score cp 0 nodes 103125684 nps 3437408 hashfull 999 tbhits 0 time 30001 pv f2f4 b7b5 d3d4 f6e6 g2g4 e6f7 d4c5 g7g5 c5b5 f5g4 h3g4 g5f4 b5c4 f7f6 c4d3 f6g5 d3e2 g5g4 e2f2 f4f3 f2f1 g4f4 f1f2 f4e4 f2f1 f3f2 f1f2 e4f4 f2g2 f4e4 g2f2
bestmove f2f4 ponder b7b5

So it seems I stand corrected and it is NOT necessary to skip shallow pruning in pawn endgames in general, but in KPK only. Next step is to confirm this theory.

Possible explanation:
The information stored in KPK is different from that of, for instance, KQKP endgame.
In a bitbase the result is stored per position, while in the other case we have a general information for nearly all possible positions (won), and only give specific rules for the exceptions (draw).

Does that make sense?

[joergoster]

Skipping shallow depth pruning in case of KPK only which requires a little bit more code.

    isKPK =   pos.count<ALL_PIECES>(WHITE) + pos.count<ALL_PIECES>(BLACK) == 3
           && pos.pieces(PAWN);
...
      // Step 13. Pruning at shallow depth
      if (   !rootNode
          && !isKPK
          &&  bestValue > VALUE_MATED_IN_MAX_PLY)

Test results seem to confirm the findings.

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0 time 3 pv c5c4
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 41 nps 10250 tbhits 0 time 4 pv c5c4 c3b2
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 198 nps 49500 tbhits 0 time 4 pv c6b6 c3d3 c5c4 d3e2
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 409 nps 102250 tbhits 0 time 4 pv c6b6 c3d3 c5c4 d3e2
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 734 nps 183500 tbhits 0 time 4 pv c6b6 c3d3 b6a5 d3c2 c5c4
info depth 6 seldepth 6 multipv 1 score cp 0 nodes 1427 nps 285400 tbhits 0 time 5 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 2049 nps 409800 tbhits 0 time 5 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6
info depth 8 seldepth 8 multipv 1 score cp 0 nodes 3096 nps 619200 tbhits 0 time 5 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6 c3d2
info depth 9 seldepth 9 multipv 1 score cp 0 nodes 3887 nps 647833 tbhits 0 time 6 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6 c3d2 b6a5
info depth 10 seldepth 10 multipv 1 score cp 0 nodes 5289 nps 881500 tbhits 0 time 6 pv c6b6 c3d3 b6a5 d3c2 c5c4 c2c3 a5b6 c3d2 b6a5 d2d1
bestmove c6b6 ponder c3d3

flip
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 9000 tbhits 0 time 1 pv c4c5
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 35 nps 35000 tbhits 0 time 1 pv c4c5 c6b5
info depth 3 seldepth 3 multipv 1 score cp 0 nodes 144 nps 144000 tbhits 0 time 1 pv c3b2 c6c5 b2a1
info depth 4 seldepth 4 multipv 1 score cp 0 nodes 345 nps 345000 tbhits 0 time 1 pv c3b2 c6c5 b2a1 c5d6
info depth 5 seldepth 5 multipv 1 score cp 0 nodes 621 nps 621000 tbhits 0 time 1 pv c3b2 c6c5 b2c3 c5d6 c3b2
info depth 6 seldepth 6 multipv 1 score cp 0 nodes 1364 nps 682000 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 7 seldepth 7 multipv 1 score cp 0 nodes 1936 nps 968000 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 8 seldepth 7 multipv 1 score cp 0 nodes 2654 nps 1327000 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 9 seldepth 7 multipv 1 score cp 0 nodes 3537 nps 1768500 tbhits 0 time 2 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
info depth 10 seldepth 7 multipv 1 score cp 0 nodes 5014 nps 1671333 tbhits 0 time 3 pv c3b2 c6c5 b2c3 c5d6 c3b2 d6c5
bestmove c3b2 ponder c6c5



md5-2e2cce9c1c3adde2028a63f01452f2eb



info depth 38 seldepth 42 multipv 1 score cp 0 nodes 109817745 nps 3660469 hashfull 999 tbhits 0 time 30001 pv f2f4 b7b5 d3d4 f6e6 g2g4 e6f7 d4c5 g7g5 c5b5 f5g4 h3g4 g5f4 b5c4 f7g6 c4d3 g6g5 d3e2 g5g4 e2f2 f4f3 f2f1 g4f5 f1g1 f5e5 g1f2 e5e4 f2f1 e4d5 f1f2 d5e4
bestmove f2f4 ponder b7b5

Even if Marco is going to close this one, comments are welcome.

[ddugovic]

Is this issue simply "the evaluation is not human-intuitive"?

In my experience (using 5-man Syzygybases during postmortem analysis) I have not experienced "human-unintuitive" evaluations.

[Stefano80]

Hi @joergoster , you correctly pointed to https://github.com/official-stockfish/Stockfish/pull/713

Since Marco rejected that pull request, it should consistently accept your fix to be tested as [-3, 1]. In my opinion, it was not sensible to reject that.

I did not understand your remark

So it seems I stand corrected and it is NOT necessary to skip shallow pruning in pawn endgames in general, but in KPK only. Next step is to confirm this theory.

Can you detail a bit?

[Stefano80]

Just for curiosity, I submitted http://tests.stockfishchess.org/tests/view/58485a190ebc5903140c585e

[jhellis3]

You can simplify: pos.count(WHITE) + pos.count(BLACK) == 3

to: popcount(pos.pieces()) == 3

[jhellis3]

You probably also want to only return instantly on draws...

[joergoster]

@jhellis3 Code was written very quickly and provided so that people are able to follow what exactly I was testing. There certainly is room for improvement.

@Stefano80 Submitted test on fishtest was skipping shallow depth pruning for any number of pawns. But the patch with probing KPK bitbase during the search proved to be already sufficient to avoid those eval artifacts. Which I then confirmed by skipping shallow pruning only in case of KPK endgame.

However, it should be understood that all tests were done on a few positions only. If the maintainers yet decide to allow this to be tested as a bugfix, more tests are needed first.

[Stefano80]

Ah now I see, thank you and good luck!

[Rocky640]

As suggested by @snicolet, I stepped through the code for the simplest reproducible case, added some traces, and learned a few things in the process.

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 2

This is currently outputting cp 4133 ( a win for black) but it should be a draw,

Stockfish 030117 64 POPCNT by T. Romstad, M. Costalba, J. Kiiski, G. Linscott
position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 2
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0 time 3 pv
c5c4
info depth 2 seldepth 2 multipv 1 score cp 4133 nodes 42 nps 8400 tbhits 0 time
5 pv c6d5 c3b3
bestmove c6d5 ponder c3b3

Engine will first examine the black moves
1 c5-c4
2 Kc6-b5
3 Kc6-d5
4 etc

Then will look for white replies
For 1 c5-c4, the first reply Kxc4 is draw

When it examines white replies to 2 Kc6-b5,
it looks at the following possible replies, in the following order
1 Kc3-b2 (white lose)
2 Kc3-c2 (white lose)
3 Kc3-d2 (white lose)
4 Kc3-b3 (the only drawing move !)
5 Kc3-d3 (white lose)
6 Kc3-e3 (white lose)
7 etc

The first one Kc3-b2 is evaluated as a loss (fine)
The second one Kc3-c2, the third and the fourth are currently pruned away because, at step 13, we have this

if ( lmrDepth < 3 && (!cmh || (*cmh )[moved_piece][to_sq(move)] < VALUE_ZERO) && (!fmh || (*fmh )[moved_piece][to_sq(move)] < VALUE_ZERO) && (!fmh2 || (*fmh2)[moved_piece][to_sq(move)] < VALUE_ZERO || (cmh && fmh))) continue;
lmrDepth is 0, we have some cmh, fmh and fmh2, but the tables had not been initialized to VALUE_ZERO (ah ah !). so all conditions are true and it will... continue.

So I tried a "fix".
Calling ucinewgame first will initialize our countermoves tables to VALUE_ZERO, as they should !

ucinewgame
position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 2

Great, now it does not skip the white replies no 2, 3 and 4, and 4 Kc3-d3 is seen, and score is draw,

But...there are other black moves in the initial position. The 3rd one which is examined is
Kc6-d5

White replies are not ordered exactly as before, and the theoretical outcomes are also different
1 Kc3-b3 (our "best countermove" which was found against Kc6-b5 ?, white lose)
2 Kc3-b2 (white lose)
3 Kc3-c2 (white lose)
4 Kc3-d2 (white lose)
5 Kc3-d3 (the only drawing move !)
6 etc

When it comes to look at Kc3-d3, the variable moveCountPruning is true, and that move and the remaining will be skipped, because of the following formula
moveCountPruning = depth < 16 * ONE_PLY && moveCount >= FutilityMoveCounts[improving][depth / ONE_PLY];
(depth = 0, moveCount is 5, improving is true, FutilityMoveCounts[improving] is {3, 5, 8, ...})

One possible fix could be to avoid step 13 when the side to move has only one king.
Let's give a chance to the brave fellow to try all possible escapes.

// Step 13. Pruning at shallow depth if ( !rootNode && bestValue > VALUE_MATED_IN_MAX_PLY) && pos.count<ALL_PIECES>(pos.side_to_move()) > 1)

Let me know if it make sense to test this with SPRT (-3, 1)

Also, when the engine exe starts, shouldn't we make sure our countermove tables are initialized?
For example, int main.cpp we could have this before the uci::loop.
Search::clear(); UCI::loop(argc, argv);

[mcostalba]

Init of countermoves at ucinewgame seems reasonable.

On Tuesday, January 3, 2017, Rocky640 [e-mail] wrote:

As suggested by @snicolet https://github.com/snicolet, I stepped
through the code for the simplest case, added some traces, and learned a
few things in the process.

position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 2

This is currently outputting cp 4133 ( a win for black) but it should be a
draw,

Stockfish 030117 64 POPCNT by T. Romstad, M. Costalba, J. Kiiski, G.
Linscott
position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 2
info depth 1 seldepth 1 multipv 1 score cp 0 nodes 9 nps 3000 tbhits 0
time 3 pv
c5c4
info depth 2 seldepth 2 multipv 1 score cp 4133 nodes 42 nps 8400 tbhits 0
time
5 pv c6d5 c3b3
bestmove c6d5 ponder c3b3

Engine will first examine the black moves
1 c5-c4
2 Kc6-b5
3 Kc6-d5
4 etc

Then will look for white replies
1 c5-c4 Kxc4 is draw

When it examines white replies to 2 Kc6-b5,
it looks at the following possible replies, in the following order
1 Kc3-b2 (white lose)
2 Kc3-c2 (white lose)
3 Kc3-d2 (white lose)
4 Kc3-b3 (the only drawing move !)
5 Kc3-d3 (white lose)
6 Kc3-e3 (white lose)
7 etc

The first one Kc3-b2 is evaluated as a loss (fine)
The second one Kc3-c2, the third and the fourth are currently pruned away
because, at step 13, we have this

if ( lmrDepth < 3 && (!cmh || (cmh )[moved_piece][to_sq(move)] <
VALUE_ZERO) && (!fmh || (fmh )[moved_piece][to_sq(move)] < VALUE_ZERO) &&
(!fmh2 || (*fmh2)[moved_piece][to_sq(move)] < VALUE_ZERO || (cmh &&
fmh))) continue;
lmrDepth is 0, we have some cmh, fmh and fmh2, but the tables had not been
initialized to VALUE_ZERO (ah ah !). so all conditions are true and it
will... continue.

So I tried a "fix".
Calling ucinewgame first will initialize our countermoves tables to
VALUE_ZERO, as they should !

ucinewgame
position fen 8/8/2k5/2p5/8/2K5/8/8 b - - 0 1
go depth 2

Great, now it does not skip the white replies no 2, 3 and 4, and 4 Kc3-d3
is seen, and score is draw,

But...there are other black moves in the initial position. The 3rd one
which is examined is
Kc6-d5

White replies are not ordered exactly as before, and the theoretical
outcomes are also different
1 Kc3-b3 (our "best countermove" which was found against Kc6-b5 ?, white
lose)
2 Kc3-b2 (white lose)
3 Kc3-c2 (white lose)
4 Kc3-d2 (white lose)
5 Kc3-d3 (the only drawing move !)
6 etc

When it comes to look at Kc3-d3, the variable moveCountPruning is true,
and that move and the remaining will be skipped, because of the following
formula
moveCountPruning = depth < 16 * ONE_PLY && moveCount >=
FutilityMoveCounts[improving][depth / ONE_PLY];

(depth = 0, moveCount is 5, improving is true,
FutilityMoveCounts[improving] is {3, 5, 8, ...})

One possible fix for this kpk ending could be to avoid step 13 when the
side to move has only one king.
Let's give a chance to the brave fellow.

// Step 13. Pruning at shallow depth if ( !rootNode && bestValue >
VALUE_MATED_IN_MAX_PLY) && pos.count(pos.side_to_move()) > 1)

Let me know if it make sense to test this with SPRT (-3, 1)

Also, when the engine exe starts, shouldn't we make sure our countermove
tables are initialized?
For example, int main.cpp we could have this before the uci::loop.
Search::clear(); UCI::loop(argc, argv);

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/official-stockfish/Stockfish/issues/760#issuecomment-270207632,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDGAV6A2NorgnCyBy3AZbfR9uG3PttXks5rOqdUgaJpZM4Jpb1g
.

[joergoster]

@Rocky640 Nice investigation! But are you sure this is sufficient?
I just tested with following condition

          && more_than_one(pos.pieces(pos.side_to_move()))

which is functionally the same as yours, and on Uri's position I still get this:
position fen 8/8/1k3K2/8/3p4/3P4/8/8 w - - 0 78
go depth 30
info depth 1 seldepth 1 multipv 1 score cp 12 nodes 8 nps 2666 tbhits 0 time 3 pv f6e5
info depth 2 seldepth 2 multipv 1 score cp 4133 nodes 27 nps 9000 tbhits 0 time 3 pv f6e5 b6a5 e5d4
info depth 3 seldepth 3 multipv 1 score cp 3 nodes 77 nps 19250 tbhits 0 time 4 pv f6e5 b6c5 e5e4

Could you confirm, please?

[Rocky640]

I agree, it does not fix all these pawn endings.

I tried

ucinewgame
position fen 8/8/1k3K2/8/3p4/3P4/8/8 w - - 0 78
go depth 2

After f6e5, it is still not a kpk !

black replies are b6a5 b6b5 b6c5 and since improving is false
movesCountPruning is 3 so b6c5 is pruned away at depth 2

improving is false: because ss->staticEval =-31,and (ss-2)->staticEval = 0 (VALUE_ZERO)
and (ss-2)->staticEval == VALUE_NONE is false.

improving = ss->staticEval >= (ss-2)->staticEval /* || ss->staticEval == VALUE_NONE Already implicit in the previous condition */ ||(ss-2)->staticEval == VALUE_NONE;

[Rocky640]

One thing that would work for all these samples is to skip step 13 whenever only the king can move

[joergoster]

Is there a cheap way to check? I must admit I'm not very familiar with the move generating and move picking code ...

Unless not, I would definitely vote for my solution with

          &&  pos.non_pawn_material(pos.side_to_move())

which is already in use in Futility Pruning (child node) and Null Move Pruning for exact the same reason.
Pawn endgames, especially those with only 1 or 2 pawns, are simply heavily influenced by zugzwang situations.

[VoyagerOne]

A quick cheap way I can come up with is this... though it may not be 100% accurate.

bool onlyKingMove=true;

while(move in movelist)
{
   if(!onlyKingMove) prune;

    if(moved_piece !=king)
       onlyKingMove=false;
make move;

}

[joergoster]

I just tried the following, which excludes ALL king moves from being pruned, of course.

          && type_of(pos.piece_on(from_sq(move))) != KING

But maybe this is helpful in other positions, too?

A combination of the two conditions seems to be really to the point of the issue, but is possibly too costly ...

[Rocky640]

I made some more experiments
I replaced, at step 13
bestValue > VALUE_MATED_IN_MAX_PLY
with
bestValue > -VALUE_KNOWN_WIN

and it "fixes" all these positions.

This would skip step 13 more often, and give the defender more chance to get a better move.

Should I test this with sprt 0,4 ?

[joergoster]

@Rocky640 Bravo!!! Seems like the 'real problem and the 'correct' fix was always right in front of our eyes.
I can confirm that with this fix all presented positions no longer show these wrong evals.

@mcostalba I really hope this can be treated as a 'bugfix', similar to cases in ProbCut and Singular extension search.

[mcostalba]

Yes, sprt (0,4) is the natural choice and I am also curious if this is just
a possible cosmetic bug fix or also aneed effective one.

On Tuesday, January 10, 2017, Rocky640 [e-mail] wrote:

I made some more experiments
I replaced, at step 13
bestValue > VALUE_MATED_IN_MAX_PLY
with
bestValue > -VALUE_KNOWN_WIN

and it "fixes" all these positions.

This would skip step 13 more often, and give the defender more chance to
get a better move.

Should I test this with sprt 0,4 ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/official-stockfish/Stockfish/issues/760#issuecomment-271481095,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDGAeHVlygohASnUYh5zF3GJCleLEvjks5rQwNFgaJpZM4Jpb1g
.

[joergoster]

@Rocky640 It seems we're back again to my solution, which unsurprisingly also failed the sprt(0, 5) test.
http://tests.stockfishchess.org/tests/view/5875f9460ebc5915193f73f4

Some more ideas? Anybody?

[Rocky640]

My bestValue > -VALUE_KNOWN_WIN test failed STC SPRT(0, 4)
http://tests.stockfishchess.org/tests/view/5874db510ebc5915193f7374

To summarize this issue:

There are 2 ideas so far that "fix" all those positions,
but would need a (-3, 1) to pass STC. (with near 50-50 results)
and both were not tested at LTC.

In both cases I'm supporting a (-3, 1) with best arguments summarized below.

A)
http://tests.stockfishchess.org/tests/view/5848c6250ebc5903140c58a2
which I find elegant and goes with the "perfect knowledge" idea:
if we know, using our bitbase or any other specialized eval,
that the position is a draw, use this information like we do with tablebases.

A draw is a draw is a draw, not a +40.

B)
http://tests.stockfishchess.org/tests/view/5846c4dc0ebc5903140c5780

&& pos.non_pawn_material(pos.side_to_move())
which is already in use in Futility Pruning (child node) and Null Move Pruning for exact the same reason.
Pawn endgames, especially those with only 1 or 2 pawns, are simply heavily influenced by zugzwang situations.

[ddugovic]

Regarding B) pos.non_pawn_material(pos.side_to_move()), does that perform more or less optimally than pos.count<ALL_PIECES>(pos.side_to_move())?

[snicolet]

@ddugovic Same speed: it is a single array dereferencing in both cases.

[snicolet]

I have pushed a test which terminates the branch by calling qsearch instead of move count pruning: http://tests.stockfishchess.org/tests/view/5879ea0d0ebc5915193f759d

[joergoster]

I have also pushed another test which excludes only king moves in pawn endgames.
http://tests.stockfishchess.org/tests/view/587a08f40ebc5915193f75b1
This one seems to be pretty neutral, too!

It also seems logical to skip early pruning when we skip shallow pruning.
http://tests.stockfishchess.org/tests/view/587a3a4c0ebc5915193f75c1

[joergoster]

@mcostalba I think it's time now to have a final decision if this will be accepted to be tested with sprt[-3, 1] bounds. Please find a good summary by @Rocky640 some comments further up.
STC test, almost finished positive, is here: http://tests.stockfishchess.org/tests/view/5846c4dc0ebc5903140c5780
Edit: One final argument. What is the point of having a KPK bitbase, and yet accepting wrong evals?