New Time Controls for WB

[Don]

I think the UCI protocol got it wrong in that regard too. The unit of time is milliseconds and it's an integer. But if you just use floating point there is no fuss.

I also believe that nodes per second could be in floating point as it is "future proof."

A few more things to consider:

1) Now that harware is ever getting faster, people play faster games, and the precision of the TC parameters becomes an issue. This is the most pressing for the INC parameter,as the TC parameter already allows specification of seconds, and typically is for 40 moves, so that it translates toan accuracy of 25 ms/move. For the INC it has tobe rounded to seconds, though, which is evolving towards the unacceptable.

So I propose to allow the specification of seconds to be floating-point numbers,in INC as well as TC parameters of the new level command. (I.e. engines should read them as "level %d %d:%f %f" or "level %d %d %f" format rather than "level %d %d:%d %d" or "level %d %d %d".)

2) Existing WB protocol has the st M command as an alternative to level N M T. If we are deciding upon an extended level command, we might as well integrate this into the extended level. One reason isto facilitate implementation of byoyomi-type time control (as alternative to classical and incremental). This TC is as many moves as you want in a first session of specified duration (e.g. one hour), followed by a maximum time per move. (Admittedly a weird system, but common place in official Shogi games.)

This could be implemented as a multisession TC, with a first session of a novel type ("any number of moves in M minutes"), after which you would switch to st-type time control. I think the (MPS, TC, INC) system of specifying sessions still has enough currently invalid combinations which could be requisitioned for this in a not-too-illogical way:

level -1 M 0
could be taken to mean a session of 1 hour and an arbitrary number of moves. (Essentially just play M minutes without clock.) So the next session would start after a certain time has elapsed, rather than after a certain number of moves.

level -1 0 T
could be defined as equivalent to st T, which is subtly different from the already defined level 0 0 T, where you would carry any leftover time with you to the next move.

The usual byoyomi TC would then be specified as

level -1 M 0; -1 0 T

[Michel]

I think it should be specified when level commands can be sent by the GUI. Can they be sent at arbitrary times (e.g. when black is to move) or only at period boundaries?

[Matthias Gemuh]

I think it should be specified when level commands can be sent by the GUI. Can they be sent at arbitrary times (e.g. when black is to move) or only at period boundaries?

Your engine receives a level command from ChessGUI when it is to move, making its first move in session.

[Michel]

Your engine receives a level command from ChessGUI when it is to move, making its first move in session.

But I assume a session starts when white is to move? This is important because of "playother". This implies that the engine may suddenly have to play with a different color. So it also has to keep track of the session of the other player.

[hgm]

We want engines to get by by being as dumb as possible. It shouldnot be necessary for them to keeptrackof anything, except movesToGo to the next TC for the color it is playing.

So if the GUI changes the engine's idea of whose side it is playing, it should set up this information in the engine, just like it would have to set up the own and opponent time again (namely swap them). When go would be used to set the engine playing (whether it was playing the opponent before, or in force mode), it should always be preceded by level, time, otim.

When playother is used to switch the engine from force mode to playing the opponent, the engine will remain inactive, or in any case would not need to make any time management decisions until the opponent moves (even if it would start to ponder). So in principle the level (and time) command could come at any time, before or after playother. Of course we know that time (and otim) in current implementations come just before the move, so it would be logical tosend the level just before time.

This is a bit unfriendly to UCI engines (playing through adapters), though, as they would need the time and movestogo before setting them pondering. The adapter can make a good guess at the time, by running its own clock, but it cannot predict session changes. So perhaps it would be easier if we decided to send it together with playother, or even just before it? This is a non-standard application of the protocol, however, so I would not be overly worried if it had to be implemented by aborting the ponder search, and starting it anew after correcting the movestogo and time parameters. It is after all the fault of UCI that this needs to be done, so it is only fair that engines using this protocol are penalized for it...

[Matthias Gemuh]

Your engine receives a level command from ChessGUI when it is to move, making its first move in session.

But I assume a session starts when white is to move? This is important because of "playother". This implies that the engine may suddenly have to play with a different color. So it also has to keep track of the session of the other player.

If you use an epd testsuite, black may have to start the sessions first.

[Michel]

When playother is used to switch the engine from force mode to playing the opponent, the engine will remain inactive, or in any case would not need to make any time management decisions until the opponent moves (even if it would start to ponder). So in principle the level (and time) command could come at any time, before or after playother. Of course we know that time (and otim) in current implementations come just before the move, so it would be logical tosend the level just before time.

So will you put in the specification that whenever there is a command that affects time management in some way the GUI will send a level command?

Also I assume this level command will be relative? If a session is 40 moves
and playother happens after 15 moves then the GUI will send a level command with an MPS of 25?

[Michel]

If you use an epd testsuite, black may have to start the sessions first.

Well this is not how it is currently implemented in xboard I think. If the move counter is 1 and black is to move then I believe white gets mps-1 plys till
the next session. Not mps.

[hgm]

So will you put in the specification that whenever there is a command that affects time management in some way the GUI will send a level command?

I am not sure such a thing should go into the specs. Just like it is not in the specs that the GUI must send new time and otim commands before it sets the GUI playing the other side. It is implied by the specs of the time and the otim commands, and what you would want the engine to do: it makes no sense to leave the engine under the impression it has 10 min on its clock (because you sent it 11 min before the last move, on which it has been thinking 1 min), when if fact you set it playing for the other side, which has 2 sec on its clock. A correct implementation would inform the engine of its altered time, and the only available means is a new time command. Similarly, it would have to alter the remaining number of moves in the session, and the intra-game level command is the only available means.

It is perfectly allowed, however, to leave the engine with 10 min on its clock, or with the same number of moves in the session (hence not sending time or level), as long as you update the GUIs clocks and TC that way (so swap the white and black time on the GUI clock). That might not be the way users typically want the 'Machine White' or 'Machine Black' commands to work, but it is not forbidden.

Also I assume this level command will be relative? If a session is 40 moves
and playother happens after 15 moves then the GUI will send a level command with an MPS of 25?

Exactly. And with the extended level command, if the real TC was 40 MPS repeating, it would now have to send a second session of 40 mps repeating, to fully inform the engine. With the kludge it would have no choice as to leave the engine under the impression that a session with 25 moves, and 62.5% of the duration will also follow. This should not be very detrimental. And even if it was, we could not expect the kludge to work under any condition; the aim there should be to make it work in plain games.

About the black-moves-first problem:

Are you sure about XBoard behavior? The behavior you describe seems very illogical. Internally, XBoard counts plies in such a game exactly as normal; with the first ply never played (i.e. backwardMostMove starts as 1, rather than 0). I don't see how that could result in behavior like this; all clock updates are based on the absolute move number, and don't refer to backwardMostMove.

[Michel]

About the black-moves-first problem:

Are you sure about XBoard behavior

If I understand correctly this is what you said here:

http://www.open-aurec.com/wbforum/viewt ... el#p191825