bug?

[hgm]

Well, I dont know how you assign these labels. But I expected that when the search gets a hash hit in a node on ply 4, and the value of this is returned to a node on ply 3, and the move leading to that eventually turns out to be the best at that ply 3 node, that it would count as a move from 'search'. Normally the search could not know how the daughter node (or grand-daughter, etc.) obtained that score.

Why would the PV of a 9-ply search only be 3 moves long, if it wasn't for a hash hit on ply 4?

[flok]

Why would the PV of a 9-ply search only be 3 moves long, if it wasn't for a hash hit on ply 4?

Good point. Going to look into that.

[flok]

Code: Select all

go depth 9
 *** store-qs 0 "r3k2r/p1p2p2/2n5/1p1Pp1pp/4P3/1QP1NPPb/R2B3P/4K2R b Kkq - 0 19" for a1bd4ada44bfd5ea / k;k;: -10000/-887/128
info depth 1 seldepth 5 score cp 27 time 13 nodes 79 pv c6e7 15f0b8764a43cf81 "r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18" | c3d4 b2a4329ff01a2302 "r3k2r/p1p2p2/8/qp1Pp1pp/3nP3/1QP1NPPb/P2B3P/R3K2R w KQkq - 1 19"
...
info depth 9 seldepth 28 score cp -110 time 4054 nodes 287066 pv a5a2 15f0b8764a43cf81 "r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18" | a1a2 bb79778ed9e44fb4 "r3k2r/p1p2p2/2n5/1p1Pp1pp/4P3/1QP1NPPb/q2B3P/R3K2R w KQkq - 0 19" | b5b4 a1bd4ada44bfd5ea "r3k2r/p1p2p2/2n5/1p1Pp1pp/4P3/1QP1NPPb/R2B3P/4K2R b Kkq - 0 19"
info score cp -110
bestmove a5a2

So during the first iteration (max depth 1) in qs a tt update is performed (storing a depth 0) and no move is stored ('k;k;' is used internally for that) and the score stored is -887 (alphaOrig/bestVal/beta).

The search continues.

[hgm]

What does your engine do when you get a hash cutoff in a PV node? Does it return the hash move as PV? Or does it return an empty PV?

[flok]

What does your engine do when you get a hash cutoff in a PV node? Does it return the hash move as PV? Or does it return an empty PV?

If there's a move in the tt entry, then that is returned. Else, it indeed returns an empty pv.

[hgm]

So you cannot be sure that the score comes from a hash hit in the position before or after b5b4. It can be that b5b4 is the hash move, or you could have had a hit in the node after b5b4 that did not have a move.

[Henk]

Method that always works is go back to an old version where it did not have that bug. Then add the changes one by one and test them very thoroughly. Unfortunately this method is very slow.

Worst case go back to simple alpha beta or a variation where you are sure of it is correct.

[hgm]

That is not a good idea. Bugs like this are like dust. Any change you make just blows it elsewhere. So if you only look at one position, the blunder will be gone there, but it will just show up in other positions.

[Henk]

With testing thoroughly I did not mean test it in one position. I usually play and observe games until bugs appear. If they don't show up after a few days I assume they are gone. [So all bugs are hidden].

[flok]

The node with hash a1bd4ada44bfd5ea (r3k2r/p1p2p2/2n5/1p1Pp1pp/4P3/1QP1NPPb/R2B3P/4K2R b Kkq - 0 19) results in b5b4 with score -110.

Now that node has no a tt with no move information with score -887.
That node calls seach for the first move, e160896154ae1a29 (r3k2r/p1p2p2/2n5/3Pp1pp/1p2P3/1QP1NPPb/R2B3P/4K2R w Kkq - 0 20).

e160896154ae1a29 does a tt checkwith score 98 and move d5xc6 apparently not enough so it continous with a null move. The null move has hash 855974cabd799b3c and fen r3k2r/p1p2p2/2n5/3Pp1pp/1p2P3/1QP1NPPb/R2B3P/4K2R b Kkq - 0 20.
The null move results in b4xc3 with score -110 returned:

Code: Select all

b4xc3 33aae4f9c5e06aad returned with score -110 | d5c6/110/search 33aae4f9c5e06aad "r3k2r/p1p2p2/2n5/3Pp1pp/4P3/1Qp1NPPb/R2B3P/4K2R w Kkq - 0 21"
...
o-o a0df19aba732ae04 returned with score -110 | d5c6/110/search a0df19aba732ae04 "r4rk1/p1p2p2/2n5/3Pp1pp/1p2P3/1QP1NPPb/R2B3P/4K2R w K - 1 21"

This -110 (-10000/110/110) is for the move b5-b4.

Code: Select all

int search(int depth, int color, int alpha, int beta, PV *pv) {
// null move
        if (!rootOfTree && depth > 0 && !isCheck && !isNullMove)
        {
                zobrist_t newHash = tt -> calcZobrist(board, opponent, NULL);

                sd -> s -> validateMoves(opponent);

                PV nmTemp;
                int score = 0;
                if (!addToHistory(sd -> history, newHash.newHash))
                {
                        score = -search(depth - 2, opponent, -beta, -beta + 1, &nmTemp);
                        removeFromToHistory(sd -> history, newHash.newHash);
                }

                if (score >= beta)
                        return score;
        }


// go through list of moves
[...etc]

}