OpenChess

In my iterative deepening loop, I need to fetch the PV after each new depth is completely searched in order to print it to the screen and, after the last level, to fetch the best move and make it.

I have been having loads of trouble with my engine after trying to rewrite it, and I think I have finally cornered the last (major) bug. I am not sure what is wrong with my strategy, but I assume that I am losing the PV or not fetching the PV correctly, causing my engine to make very bad moves occasionally.

Here is the algorithm for fetching:
1. Get the hash entry for the current position hash (called result)
2. IF result.move has a value,
AND result.flag is exact (not alpha or beta cutoff)
AND the current position has the same hash key as result:
THEN make the move.
ELSE, return from the function
3. Add the move to the pv list
4. repeat 1-3 (until step #2 goes to ELSE)

Here is my hash table replacement strategy:
Store the NEW value over the OLD value IF
(the NEW value has greater depth below it or OLD is too old)
OR
(the NEW value has equal depth AND (has an exact flag OR OLD is too old))

I have been trying to think of whether the PV is guaranteed to be there at the end of the search, but I haven't been able to figure it out.

The problem my engine has been experiencing is that occasionally it just does not "see" a move and the score evaluation and everything will be totally okay, but the engine will make an illogical move. Immediately afterwards the score evaluation shows the mistake.

This fits the diagnosis that the engine is returning the correct score, but the wrong PV. The evaluation function says that the engine is okay if it plays this line, but it plays another.

Thanks for any help.

There is really no solution that will work 100% of the time. The transposition table, in normal usage, gets overwritten many times during a search. Expecting to search the best move of the PV at ply=15 first, and then storing that entry, and then find that entry alive and present in the TT after the iteration has finished is really a "shot in the dark".

I do, and always have, thought that the "backed up PV" (where you back up the PV at exactly the same point where you back up the best score) is the best plan here. For debugging, it is important that you can actually find the position that produced the score that was backed up to the root. With the TT approach, this is anything but likely. You can get a longer (or shorter) PV, which makes debugging not so easy at times...

Try keeping a special table for moves with exact score. And it's more reliable to have the search function return the best move either directly or using some global structure.