Greg Strong wrote:Yes - the "Easy move" idea. Stockfish and others have this. If one move looks significantly better than the others, allocate more time.
I've tried it, but I haven't been able to get it to work.
More time? In Stockfish detecting an "easy move" leads to stopping the search early. Other engines do probably something very similar. This is obviously the idea of calling a move "easy", you don't need to think too deep about it (e.g. forced recapture, or check escape).
Sven Schüle wrote:More time? In Stockfish detecting an "easy move" leads to stopping the search early. Other engines do probably something very similar. This is obviously the idea of calling a move "easy", you don't need to think too deep about it (e.g. forced recapture, or check escape)
All strong engines have easy move, and time allocated for it is from 1/5 to 1/3 of the original allocated time.
However, there are some engines (ZCT ) that if the result is too good allocate more time, no matter how ridiculous that might be .
The annoying thing about experimenting with time management ideas is that their effectiveness depends a lot on the time control you're using. For example I recently implemented easy moves in Daydreamer, but at the fast time controls I normally test at, it has virtually no effect. I tried changing all the parameters of my implementation with no effect before I realized that the feature would only give an improvement with longer time control.
This makes it unusually hard to do experimental design for time management schemes, and also tougher to tune your time management parameters. I have some new ideas for time management in the next version of Daydreamer, but I held off implementing them because I'm not sure how I want to do testing yet.
Greg Strong wrote:Yes - the "Easy move" idea. Stockfish and others have this. If one move looks significantly better than the others, allocate more time.
I've tried it, but I haven't been able to get it to work.
More time? In Stockfish detecting an "easy move" leads to stopping the search early. Other engines do probably something very similar. This is obviously the idea of calling a move "easy", you don't need to think too deep about it (e.g. forced recapture, or check escape).
BrandonSi wrote:Once the engine is aware of the speed of the hardware it could adjust values appropriately.
I never heard of anyone using hardware speed - much simpler to use time. You can get 1/100's or 1/1000's of a second from the system clock.
I think most people probably calculate a target time per move based on the time control and adjust that based on circumstances. As HGM noted a fail low says you have problems - you likely want to add more time to try and resolve that. Some engines try to define an "easy move", ie a recapture, and reduce their search time in that case.
Off the topic, your hardware speed comment reminded me of an anecdote. In the early days of the PC there was only one clock speed - 4.77 MHz. I bought a submarine simulator to run on my PC clone. Then, with the IBM AT, Tandy 2000 and such higher sppeds became available. I upgraded and loaded my submarine simulator on my new hardware. The first torpedo I fired left me dumbstruck - the thing went through the water like a rocket.
) that if the result is too good allocate more time, no matter how ridiculous that might be 
.
