I think I may have a new idea for time management (well it is new to me at least ).
When you play a game via UCI, then it'll tell you how much time you have left but also for your opponent (you can track that yourself too of course).
My idea is (for weak(er) engines) that when you allocate time, you check how much your opponent has left. Then if that's less than what you yourself have, add half of that difference to how much time you would allocate otherwise. The idea is that the opponent decided to use a certain amount of time for a reason, so if you have more time left, then that's a theoretical waste. It gave Dog a +17elo (when compared against Dorpsgek and Embla).
In Joker I also adapt the time usage towards what the opponent uses. As it is rather dangerous to create a time difference where you would be greatly outsearched.
Hmm. I guess it comes down to whether thinking for a long time early in the game (because your opponent did), in hope of spotting some deep tactic, provides more benefit than defeating your opponent in the endgame (because they burned too much time early on and blunder a drawn game). Like many design decisions in chess engines, it's not obvious a priori which is the better approach. Has to be tested empirically.
You say you measured a 17 Elo strength improvement. In how many games? Meaning, what are the Elo error bars? At what time control?
I trust Elo strength measurements more when derived from a gauntlet tournament against ten other engines within 100 or so Elo of my engine. I wouldn't test against only two engines. Don't want to measure some exploit they have over my engine (or vice-versa) that other strength-comparable engines do not.
The optimum time usage will no doubt allocate more time to earlier moves. But the point is that the optimum will depend on what your opponent does. So you can optimize a fixed, unresponsive time management against a group of opponents. But this might still be worse as when you would optimize against any oponent separately. The latter would not help if you would not know what opponent you play against. But the oponent reveils that by his time usage.
It is a bit like insisting that you always make the same sequence of 10 moves in the opening, irespective of what the opponent plays. I am sure there would be a best sequence for that. But it would probably be a lot worse than when you adapt your moves to those of the opponent.
emadsen wrote: ↑Tue Oct 18, 2022 1:54 am
Hmm. I guess it comes down to whether thinking for a long time early in the game (because your opponent did), in hope of spotting some deep tactic, provides more benefit than defeating your opponent in the endgame (because they burned too much time early on and blunder a drawn game). Like many design decisions in chess engines, it's not obvious a priori which is the better approach. Has to be tested empirically.
You say you measured a 17 Elo strength improvement. In how many games? Meaning, what are the Elo error bars? At what time control?
I trust Elo strength measurements more when derived from a gauntlet tournament against ten other engines within 100 or so Elo of my engine. I wouldn't test against only two engines. Don't want to measure some exploit they have over my engine (or vice-versa) that other strength-comparable engines do not.
3281 games, 10/10 error bars, tc=40/12+0.2
Thanks for the > 2 engine suggestion, I'll do that. Makes sense.
hgm wrote: ↑Tue Oct 18, 2022 7:27 am
The optimum time usage will no doubt allocate more time to earlier moves.
As as aside, and assuming the UCI protocol, can I just check that an engine would typically do this by just effectively splitting the remaining time up unevenly in favour of the next moves? I'm assuming a "sudden death" time control. e.g. so if I estimate the game to be an average of 60 moves and I have 60 mins, I allocate more than 1 minute for the next move while knowing much later moves will drop below the average of 1 minute.
I presume that the ply count from the position FEN isn't used in anyway, e.g. as an indicator of how early in the game we are? Doesn't sound right.
).
