multiple iterations giving same first move of PV

[smcracraft]

I recall a time-savings technique (Hyatt/Crafty/Cray Blitz?) involving
terminating the search early due to a number of iterations of iterative
deepening giving the same first move (or something vaguely similar.)

Anyone recall the greater specifics?

[bob]

I recall a time-savings technique (Hyatt/Crafty/Cray Blitz?) involving
terminating the search early due to a number of iterations of iterative
deepening giving the same first move (or something vaguely similar.)

Anyone recall the greater specifics?

I do something like this, as did Don (Komodo). We experimented with various ideas and we ended up with something fairly close to each other. We were not only interested in trying to recognize "easy" type moves and move quicker, saving time, but also recognizing "difficult" positions that deserved more time.

You can always look at the comments in Crafty, but the basic idea is that every time the best more remains the same, the target time for the search gets reduced. If there is a switch in best move, we go back to the original time and then for every switch we actually increase the time for the search in Crafty.

A side effect is making it more human-like in time usage as Crafty does not use the same time for successive moves. It varies all over the place depending on how frequently/infrequently the best move changes.

[Ferdy]

I recall a time-savings technique (Hyatt/Crafty/Cray Blitz?) involving
terminating the search early due to a number of iterations of iterative
deepening giving the same first move (or something vaguely similar.)

Anyone recall the greater specifics?

Don't know about Crafty specific, but probably can be one of the easy move techniques. Example break the search if all conditions below are satisfied.
* You still have more thinking time say 30s for this move, the target is to save half of that move time allocation.
* Start evaluating easy move at iter say 10
* If same pv move from iter 10 to say iter 14 (depending further on the phase of the game)
* The score of pv move does not go down, from iter 10
* The score is good say 30cp and above at iter 10
* The score of your previous move in move history is say 30cp and above

[Ras]

Anyone recall the greater specifics?

I'm doing it like this in case that the score drop from the best to the second best move is high enough:

http://www.talkchess.com/forum/viewtopic.php?t=61976

(I have reduced the easy-threshold to 200 cps in the meanwhile.)

[hgm]

I am doing something similar in Shokidoki: every search starts with a variable margin = 300, and in the root the PVS null window is not set at the score of the first move, but to score - margin. As soon as there is a fail high against the null window, margin is reset to 0. As long as margin is non-zero, the test for establishing if it is time to move divides the target time by 10.

This assumes there will be a hash move available in the root even at d=1, from the previous search.