New idea for "easy move detection"

[Ras]

I've implemented an "easy move detection" to the CT800.

The algorithm goes as follows:

- In the root position, do the normal alpha-beta-minimax move sorting at depth 3 plus QS.
- Check whether the drop from the best to the second best move is at least 240 centipawns (cps).

- If none of the following conditions a) and b) holds true, reduce the score drop to 0 (preventing the "easy move" shortcut):
a) the opponent's move was in the PV, and the "easy move" was calculated as answer.
b) the position evaluation for the "easy move" from the move sorting above is within a window of +/- 50cps from the previous move turn. I maintain a "last valid eval" variable anyway for lazy middlegame static evaluation.

If the score drop is still above 240, then perform a regular NegaScout search including check extensions and QS until depth 4. If the "easy move" is still at the top of the PV, stop the calculation.

The ideas here:

- the "easy move" could as well be a trap. While the opponent might just hang a piece, it is also possible that there is something to it. So if the move fails on the high side of the +/- 50cps window, then don't take the bait. As always in life - when something is too good to be true, then probably it isn't.

- the "easy move" might in fact be bad because the CT800 has already detected e.g. a deeper mate in the previous search (fails on the low side of the +/- 50cps window). That is especially important if the mating combination has already cost some material.

Note: the situations when there is only one legal move or only one move that avoids being mated in the next move are handled separately from this logic.

[Michael Sherwin]

Does not seem (to me) that it would be sound. However, if it works at the root it would also work higher up in the tree giving tremendous savings. Maybe use it higher up in the tree let's say at ply 5 for example if at ply 3 there are numerous good moves that can be played instead in case the the next search shows it to be bad.

[hgm]

Rather then relying on a single low-depth search to determine it, I just start normally iterating with a score gap between the best and second-best move in the root (setting alpha to pvScore - MARGIN in PVS). If a second move gets above alpha, MARGIN is reset to 0 for the remainder of the iterations. But as long as the gap is non-zero, it keeps using it, no matter how large the depth already is. When testing if it is time to move, it uses a reduced target time when the margin is non-zero.

This makes it less likely you overlook alternatives that need some depth to appreciate.

Like Michael says, if it works in the root, it might be a good idea to apply it in every PV node.

[Ras]

Does not seem (to me) that it would be sound.

It's just how I would play myself, and test games show it works fine. For the actual ID search, there is already pruning in place - however, doing that in the PV usually is too risky without special care.