Blunder related to aspiration window?

[tomitank]

Sometimes my engine makes a huge blunder and I was wondering if this is related to the aspiration window. Suppose I have no time left and MUST perform a move, what should I do in the following situations? Perform the best move of the previous iteration or perform the 'best move' of the current iteration?
1) root score <= alpha
2) root score >= beta

My problem was similar:
http://talkchess.com/forum/viewtopic.php?t=67279

I agree with John Merlino, this is partly time management question.
You need to extend time when the score drops. (eg -30 cp)

With fix time / 1 move this solution is more interesting.

[syzygy]

This is not a time management problem because the OP specified that there is no time left and that therefore a move must be made. Good time management is important, but it can never prevent the situation that time runs out and that some move has to be played. The question is now how to decide whether the "new best move" is safe enough or whether the best move from the last completed iteration is a better choice.

The full answer will probably be different for different engines, but in general I think one can say that a move that failed high after a null-window verification search is not yet safe but that it should suffice if that move also did better than the old best move in an open-window PV search (even if it failed high again in that search). But of course this can be highly dependent on the specifics of the search implementation. If a search does almost no pruning, then any fail high can be trusted.

[sandermvdb]

This is not a time management problem because the OP specified that there is no time left and that therefore a move must be made. Good time management is important, but it can never prevent the situation that time runs out and that some move has to be played. The question is now how to decide whether the "new best move" is safe enough or whether the best move from the last completed iteration is a better choice.

Indeed, I understand the importance of time management, but what if I MUST perform a move and have no time left? Perform failed low/high move of the current iteration or perform the best move of the previous iteration?
If the latter cannot result in serious blunders, I need to look further what's causing this.

[Sven]

Sometimes my engine makes a huge blunder and I was wondering if this is related to the aspiration window. Suppose I have no time left and MUST perform a move, what should I do in the following situations? Perform the best move of the previous iteration or perform the 'best move' of the current iteration?
1) root score <= alpha
2) root score >= beta

In my engine Jumbo this question never arises, for the following reasons:

a) Changing the "best move" requires a true score within the alpha/beta window.

b) The best move from the previous iteration remains the move candidate that the engine will play in the game, unless a different "best move" appears in the current iteration.

c) If the best move from the previous iteration fails low and a timeout occurs before finishing the search of the second root move then Jumbo plays that previous best move simply because there is no new information about a better one. The same applies if the second and possibly more root moves fail low and no re-search with a different window is possible before timeout occurs. No other decision can be made if time is exhausted, so any disadvantages of that kind of decision could only be addressed by a clever time management (which Jumbo does not have yet).

In my opinion not following these guidelines, especially a), has some potential to produce blunders.

So to answer your questions, I would:
1) (root score <= alpha) play the best move of the previous iteration (since the current iteration does not have one yet),
2) (root score >= beta) play the best move of the current iteration if there is one already (one that is within the window).

Playing a move that has just failed high in the current iteration might be an option but I'd consider it as unreliable.