right handling of "allocated time (over)" during s

[hgm]

That would be once in about 1000 games for this example. Too much for my taste.

Well, as they say, there is no accounting for tatste. But it escapes me why it would be offending if discarding a valid result would happen every game, or even every move. Even at the ultra-fast TC you mention that would only be one (or a few) out of 50,000 results.

Have you ever thought about how much it would hurt if you randomly discard 1% of the valid results during a search (i.e. suppress the hash store for no other reason than that 'its number came up')?

[Sven]

That would be once in about 1000 games for this example. Too much for my taste.

Well, as they say, there is no accounting for tatste. But it escapes me why it would be offending if discarding a valid result would happen every game, or even every move. Even at the ultra-fast TC you mention that would only be one (or a few) out of 50,000 results.

Wrong. You discard a whole tree (subtree of a root move), not just one node.

Have you ever thought about how much it would hurt if you randomly discard 1% of the valid results during a search (i.e. suppress the hash store for no other reason than that 'its number came up')?

We are not talking about not storing information in the hash table. We are talking about unnecessarily discarding the result of searching a root move, which can simply hurt by playing move 1 even though move 2 has been found as new best move right now (but discarded through this unusual timeout handling).

[bob]

That would be once in about 1000 games for this example. Too much for my taste.

Well, as they say, there is no accounting for tatste. But it escapes me why it would be offending if discarding a valid result would happen every game, or even every move. Even at the ultra-fast TC you mention that would only be one (or a few) out of 50,000 results.

Wrong. You discard a whole tree (subtree of a root move), not just one node.

Have you ever thought about how much it would hurt if you randomly discard 1% of the valid results during a search (i.e. suppress the hash store for no other reason than that 'its number came up')?

We are not talking about not storing information in the hash table. We are talking about unnecessarily discarding the result of searching a root move, which can simply hurt by playing move 1 even though move 2 has been found as new best move right now (but discarded through this unusual timeout handling).

I handle this from two directions.

(1) when I complete a root move, without the abort_search flag being set, I update the best move and PV that will be played. Inside the tree, when abort_search is not set, I do the normal things such as back up scores/PVs, update hash table, etc.

(2) whenever abort_search is set, all search calls unwind changing nothing beyond this point. NO PV/Score updates, no HT updates, etc. Just get out as quickly as possible.

I pull this off by checking the abort_search flag after EVERY recursive call to search() and quiesce(). If the flag is set, I simply return 0 which gets me out of search almost instantly, all the way back to the root. This lets me use partial root searches (I have searched the first 3 moves and found that the 3rd was best and actually play this move, without using the partial results from move 4 or beyond for anything at all.

Simple and doesn't require a lot of thinking... Simple is always good for me.

[hgm]

Wrong. You discard a whole tree (subtree of a root move), not just one node.

No, you won't. Almost all nodes of that tree will have already been stored in the hash table. The only nodes of which you suppress storage are the nodes through which you pass during the unwinding of the search. If the average branch length is 10 ply, that means you lose only 10 nodes.

We are not talking about not storing information in the hash table. We are talking about unnecessarily discarding the result of searching a root move, which can simply hurt by playing move 1 even though move 2 has been found as new best move right now (but discarded through this unusual timeout handling).

If you are talking about that you would have toweight your statistics with the probability that the aborted root move was indeed the best move. Normally you would not abort moves anyway, if you have good time management. You won't start an iteration that you won't expect to finish, and only in the rare case that you have a disastrous fail low in the last iteration you might get in trouble. Normally you give extra time for that in the root until you find an acceptable alternative, and stop there. That you have to use the 'cold-turkey deadline' is really very rare. And it would almost ever be on the best move.