Sven Schüle wrote:Updating the best move should only happen if the new score is inside the window, i.e. alpha < Score < beta. When failing low or high there is no best move.
That doesn't seem right. If a move produces a beta cut, I would say it's a good move, and I think it would be reasonable to try it first next time we look at this position.
Indeed, any move scoring above alpha should become bestMove / hash move.
This might just be an issue of naming things, though: 'bestMove' is not really the best move of the position, it is just the best move so far. It would only be the best move after all moves are searched, which would never happen during a beta cutoff. But a cut move is a cut move, and even if you cannot guarantee it is the best move, you would want to try it first next time, as it is likely to cut again. So you would store it as hash move, and you would sort it to front of the move list for a next IID pass.
BTW, there is an interesting issue here, which is usually ignored: if we get a hash move from a hash hit on a position with a lower bound that is grossly inadequate for the current value of beta, it is in fact not so likely that this move will be able to cut again. It could be better to find a new hash move that can at low depth first (i.e. start IID) rather than searching that hash move at full depth (likely wasting the time, and being committed to find an alternative at high depth as well).
