Don't blunder under extreme time pressure

mcostalba · mcostalba · commit 82f6779c2e54 · 2013-09-15T07:59:09.000+02:00
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.
diff --git a/src/timeman.cpp b/src/timeman.cpp
@@ -17,8 +17,8 @@
   along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
 
-#include <cmath>
 #include <algorithm>
+#include <cmath>
 
 #include "search.h"
 #include "timeman.h"
@@ -110,7 +110,12 @@ void TimeManager::init(const Search::LimitsType& limits, int currentPly, Color u
 
   // 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.
