We always attempt to keep at least this emergencyBaseTime
at clock. But if available time is very low it means that
we will force ourself to play immediately to satisfy the
emergencyBaseTime constrain and so leading to blunders.
Patch is good at short and very short TC (15secs and 5secs respectively)
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26590 W: 5426 L: 5245 D: 15919
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 5767 W: 1397 L: 1268 D: 3102
Instead seems has no influence at longer TC (60 secs)
LLR: -2.96 (-2.94,2.94) [0.00,6.00]
Total: 79862 W: 13623 L: 13339 D: 52900
So it is committed to have a broader testing but is
to be consider still EXPERIMENTAL and can be reverted
easily.
No functional change.
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "search.h"
#include "timeman.h"
#include "search.h"
#include "timeman.h"
// Initialize to maximum values but unstablePVExtraTime that is reset
unstablePVExtraTime = 0;
// Initialize to maximum values but unstablePVExtraTime that is reset
unstablePVExtraTime = 0;
- optimumSearchTime = maximumSearchTime = limits.time[us];
+ optimumSearchTime = maximumSearchTime = limits.time[us]; // In msec
+
+ // Scale down emergencyBaseTime if we are under very high time pressure to
+ // avoid moving immediately and so blundering.
+ if (maximumSearchTime)
+ emergencyBaseTime /= std::max(emergencyBaseTime * 100 / maximumSearchTime, 1);
// We calculate optimum time usage for different hypothetic "moves to go"-values and choose the
// minimum of calculated search time values. Usually the greatest hypMTG gives the minimum values.
// We calculate optimum time usage for different hypothetic "moves to go"-values and choose the
// minimum of calculated search time values. Usually the greatest hypMTG gives the minimum values.