Help with debugging

[lauriet]

Hey All,

Towards the end game, my program searches (in this instance) about 12 ply but misses loosing a hanging pawn
How do I debug this ?

(In the endgame NullMove is off and LMR is off)

[lauriet]

I fixed this by bumping up the pawn value to 125 in the endgame, so i suppose my wild, untuned eval is to blame.
But how do i narrow it down with in the 20,000,000 nodes ?

[Dann Corbit]

Have you proven that your eval is fully symmetrical by reversing the colors and reversing the board to get the exact same eval each time?

If the problem is search, you might learn something from the examination of the pv. Analyze your pv with another engine and see if there is a sharp disagreement.

I guess that you have some kind of pruning more than pure alpha beta even in the endgame. You could try turning features off and on to see if a particular feature causes the defect.

In the late endgame, edge pawns are worth more than center pawns. Was it an edge pawn that showed the abnormality?

[lauriet]

yes, it was an edge pawn.
and no, i dont have any pruning once i decide its in the end game. What do you suggest ?
i did try some other PST values that also prevented the issue, i guess that
means the eval is not tuned/in hamony.

[hgm]

One way of debugging the search that never failed me is this:

Declare an array of moves path[], and a variable 'ply' that keeps track of distance to the root, and assign every move made in MakeMove to path[ply]. Then #define a condition PATH as (ply == 0 || path[0] == MOVE1 && (ply == 1 || path[1] == MOVE2 && (ply == 2 || path[2] == MOVE3 && (ply == 3 ... ))). Finally put a conditional printf statement if(PATH) printf(...) after UnMake(), printing ply, (remaining) depth, possibly iteration depth (in case of IID), the move just searched, its score and the best score so far.

Then search the position where the engine blundered. Initially (i.e. when MOVE1 etc. have not yet been set to valid moves) you will get an overview of all moves considered in the root, and their score. Then take the move that you think has the wrong score, make it MOVE1 in PATH, recompile and repeat the search. You now also get an overview of the moves in the node after MOVE1. You again pick out the move with the score you feel was wrong, and make it MOVE2. Repeat this procedure until you arrive in the node that generates the wrong score. Then you can put in more conditional print statement in other parts of the code to see how this score came to be that way (e.g. which evaluation term was in error). I have found bugs at ply==24 that way.