Time managment ?

[MahmoudUthman]

Currently I have a horrible primitive time management scheme which I intend to replace but I need to understand somethings:
1-Easy moves how and when should I return quickly ?
2-If I was in a node that has only 1 move could I immediately return Eval after making it to confirm it isn't a check/stale mate ?
3-Should I separate game phases "for time management" by number of moves played or by actual game phase based on remaining pieces "as the one used in evaluation" ?

[Ed Trice]

Currently I have a horrible primitive time management scheme which I intend to replace but I need to understand somethings:
1-Easy moves how and when should I return quickly ?
2-If I was in a node that has only 1 move could I immediately return Eval after making it to confirm it isn't a check/stale mate ?
3-Should I separate game phases "for time management" by number of moves played or by actual game phase based on remaining pieces "as the one used in evaluation" ?

1. Replay a few games of your own where you had a big material advantage and moved quickly yourself. Have your leaf node evaluator list the scores of all of the moves for each of those positions. Compute the average value of the positive scores separately from the negative scores (otherwise your average gets skewed). Come up with an Alg such as:

If(current_material >( avg_positive + some_value)) MoveQuick();

2. Make 1-move immediately, always. Waste no time when there is no choice.

3. That idea will spawn endless testing and tweaks. I suggest basing it on the move countdown to make the immediate time control, adjusting it after every move. I'm sure there's much better ways to do it.

[Dann Corbit]

Currently I have a horrible primitive time management scheme which I intend to replace but I need to understand somethings:
1-Easy moves how and when should I return quickly ?

This is how Stockfish does it:

Code: Select all

        // Do we have time for the next iteration? Can we stop searching now?
        if (Limits.use_time_management())
        {
            if (!Signals.stop && !Signals.stopOnPonderhit)
            {
                // Stop the search if only one legal move is available, or if all
                // of the available time has been used, or if we matched an easyMove
                // from the previous search and just did a fast verification.
                const int F[] = { mainThread->failedLow,
                                  bestValue - mainThread->previousScore
                                };

                int improvingFactor = std::max(229, std::min(715, 357 + 119 * F[0] - 6 * F[1]));
                double unstablePvFactor = 1 + mainThread->bestMoveChanges;

                bool doEasyMove =   rootMoves[0].pv[0] == easyMove
                                    && mainThread->bestMoveChanges < 0.03
                                    && Time.elapsed&#40;) > Time.optimum&#40;) * 5 / 44;

                if (   rootMoves.size&#40;) == 1
                        || Time.elapsed&#40;) > Time.optimum&#40;) * unstablePvFactor * improvingFactor / 628
                        || &#40;mainThread->easyMovePlayed = doEasyMove, doEasyMove&#41;)
                &#123;
                    // If we are allowed to ponder do not stop the search now but
                    // keep pondering until the GUI sends "ponderhit" or "stop".
                    if &#40;Limits.ponder&#41;
                        Signals.stopOnPonderhit = true;
                    else
                        Signals.stop = true;
                &#125;
            &#125;

            if &#40;rootMoves&#91;0&#93;.pv.size&#40;) >= 3&#41;
                EasyMove.update&#40;rootPos, rootMoves&#91;0&#93;.pv&#41;;
            else
                EasyMove.clear&#40;);
        &#125;

2-If I was in a node that has only 1 move could I immediately return Eval after making it to confirm it isn't a check/stale mate ?

This is often handled by single reply extensions. If you return eval on a 30 ply search, you might get some nasty surprises. That is a 30 ply reduction. Probably would not matter on the current root position, but other places in the tree near the root of the current position should still be searched to the appropriate depth. SF does appear to ponder (if ponder is on) or stop searching if the current node is singular. It seems very strange to me, but maybe it works.

3-Should I separate game phases "for time management" by number of moves played or by actual game phase based on remaining pieces "as the one used in evaluation" ?

Wood count is the most popular.

[cdani]

1-Easy moves how and when should I return quickly ?

No easy moves in Andscacs, and I don't like them. I have seen bad easy moves in any engine that uses them. You will have time to decide if you really want them.

[hgm]

In Shokidoki I reduce the thinking time by a factor 10 from what it would otherwise take when there is a score gap larger than a Pawn between the best move and the second-best move. To know that I shift down the PVS null window by about half a Pawn in the root, and keep doing that for as long as I get no fail highs above it. As soon as I get a fail high, I stop shifting the window for the remaining iterations.

Single legal replies I just do instantly. I have no ponder move then, but my ponder scheme starts with a 7-ply search for the opponent to pick a ponder move. (Which then usually picks up a move from a much deeper search from the hash table.

I estimate remaining moves from the score (if it gets far from zero the game is approaching the end), and base time per move on that. But this is mainly because it is a engine for a drop game, where material is no indication, as all material will always be there.

[Ras]

1-Easy moves how and when should I return quickly ?

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

[JVMerlino]

1-Easy moves how and when should I return quickly ?

No easy moves in Andscacs, and I don't like them. I have seen bad easy moves in any engine that uses them. You will have time to decide if you really want them.

+1

Easy moves are an unnecessary complication (and headache), IMO. I'd be very curious to see how much ELO (if any) they give to SF et al, and I'd be surprised if it was more than 2 or 3.

[JVMerlino]

Currently I have a horrible primitive time management scheme which I intend to replace but I need to understand somethings:
1-Easy moves how and when should I return quickly ?
2-If I was in a node that has only 1 move could I immediately return Eval after making it to confirm it isn't a check/stale mate ?
3-Should I separate game phases "for time management" by number of moves played or by actual game phase based on remaining pieces "as the one used in evaluation" ?

I replied about #1 in a different post.

Regarding #2, I do respond "quickly", but if pondering is on I still search up to depth 5 (this was an arbitrary choice) to have a reasonable move to ponder on. When pondering is off, I return after a depth 1 search.

[Ferdy]

Currently I have a horrible primitive time management scheme which I intend to replace but I need to understand somethings:
1-Easy moves how and when should I return quickly ?

There are 4 that I tried that works for me.
1. Recapture at the root
max_search_time = allocated_time/4
saved_time = allocated_time * 3/4

2. Stable search at the root
Save the score and move while iterating at root node. Record the move changes and score changes. If there are no move changes and the score does not go down as iteration depths increases, just use half of the allocated time.

3. High score difference between bestmove1 and bestmove2 at the root
Best for long games where you have more time to search for bestmove, if the gap between the score of bestmove1 and bestmove2 is of say above 2 pawns, then this can be a candidate for easy moves. Just spent of say allocated_time/16 to run at multipv 2 or exlusion search then return back to normal search. If it passes on this criteria, observe the move and/or score stability from normal search. If it also passes the stability test, then this can be an easy move, just spent half of the allocated time so you can have a time saving of one-half.

4. Single legal move at the root

[Stan Arts]

Nemeton cuts target time in half when it tries to guess easy recaptures as following.:
Search score is much better than static score at the root. (By >2.20 pawn.) Current preferred move is a capture and the position is still rather balanced. (> -2.50 pawn and < 2.50 pawn.)
Slightly risky but simple and in practise does what it's supposed to do.

I also cut time in half when moving out of check. It's simply annoying from a human standpoint when an engine spends full time there.