Tough bugs II

[Henk]

Spend almost a day or perhaps even more on finding a bug. Search was highly instable and I noticed it too late.

Cause: I decided to use only two killer moves at each depth. But I forgot that I had already removed all the killer moves from the remaining candidate moves
(for previously I used all killer moves found at each depth.)

[Sven]

Just store only two killer moves, not "all", then this won't happen again, and there will be no such difference between "stored" and "used" killer moves. Whenever your search finds a new best (non-capture) move that it wants to store as killer move, do like this:

Code: Select all

if (killer[ply][0] != NEW_KILLER) {
    killer[ply][1] = killer[ply][0];
    killer[ply][0] = NEW_KILLER;
}

so that you just store the two most recent different killer moves. No need to maintain a list of arbitrary length, no need to maintain a "current list size" (the two-entry list simply works without that, if you initialize it to contain just two null moves).

Sven

[hgm]

Early recording of the killers in IID can also be a nasty bug, in some designs. Spartacus skips killers (i.e. what is in the killer slots) in its move loop, assuming they were generated in the killers phase, and are thus somewhere early in the move list. But if an early iteration finds a new killer, and stores it, the final iteration will not search its best move...