WB time controls (Uri, HGMuller, Hyatt, etc) for ChessGUI

[Matthias Gemuh]

Hi WB experts,

What is WB syntax for these time controls ?
a/b + c/d + c/d + c/d + ...
a/b + c/d + e (e is for all remaing moves).

Does GUI send the command only at beginning of game ?

Which WB engines have these 2 time controls implemented ?

Regards,
Matthias.

P.S.: Note that my engines are flexible: they expect to receive any new time control in any time control interval. If no new time control is received, the engines assume the current time control should be repeated.

[hgm]

Tjere is no official syntax for secondary and tertiary time controls in WB protocol.

Unfortunately there has been a proposal to implement this by equiping the 'level' command with more arguments, as:

level MPS TC INC [MPS2 TC2 INC2 ...]

MPS=0 means "rest of game", if the last session does not have MPS=0 it will be repeated for as long as the game lasts. Some engines actually implement this, and Arena sends it at the users request without knowing if the engine will understand it.

This is a silly proposal, as MPS=0 means rest of game, so that no later sessions can follow. Thus only the last group of 3 can have MPS=0. But in WB time controls, MPS != 0 implies INC=0. So it means that this way of extending the level command only leads to the insertion of a number of redundant zeros.

The proper way to implement it would be to have the engine tell the GUI that it can handle it through the 'features' command, by sending level=N, with N the maximum number of sessions it will accept. The WB proposal included this, but most engines don't seem to do it. As a result, in a properly implemented protocol, the GUI should never send the extended level command.

As even most the engines that do implement the secondary time controls do it in a way that is broken, and will have to be fixed, I want to make a counter proposal:

Through "features xlevel=N" (default: N=1) engines can enable an extended level command of the form:

level MPS TC [MPS2 TC2 ...] INC

leaving out the redundent zeros. INC will apply to the last mentioned session, and can only be non-zero if the MPS for that session is zero (so that the session is the last session of the game).

[Matthias Gemuh]

Tjere is no official syntax for secondary and tertiary time controls in WB protocol.

Unfortunately there has been a proposal to implement this by equiping the 'level' command with more arguments, as:

level MPS TC INC [MPS2 TC2 INC2 ...]

MPS=0 means "rest of game", if the last session does not have MPS=0 it will be repeated for as long as the game lasts. Some engines actually implement this, and Arena sends it at the users request without knowing if the engine will understand it.

This is a silly proposal, as MPS=0 means rest of game, so that no later sessions can follow. Thus only the last group of 3 can have MPS=0. But in WB time controls, MPS != 0 implies INC=0. So it means that this way of extending the level command only leads to the insertion of a number of redundant zeros.

The proper way to implement it would be to have the engine tell the GUI that it can handle it through the 'features' command, by sending level=N, with N the maximum number of sessions it will accept. The WB proposal included this, but most engines don't seem to do it. As a result, in a properly implemented protocol, the GUI should never send the extended level command.

As even most the engines that do implement the secondary time controls do it in a way that is broken, and will have to be fixed, I want to make a counter proposal:

Through "features xlevel=N" (default: N=1) engines can enable an extended level command of the form:

level MPS TC [MPS2 TC2 ...] INC

leaving out the redundent zeros. INC will apply to the last mentioned session, and can only be non-zero if the MPS for that session is zero (so that the session is the last session of the game).

level MPS TC [MPS2 TC2 ...] INC looks good. The question is how to know whether we should implement it. Will engine authors do their part ?

Would level MPS TC [MPS2 TC2 ... MPSn TCn] mean use MPSn TCn for any session repeatedly after session n ?

Matthias.

[bob]

Tjere is no official syntax for secondary and tertiary time controls in WB protocol.

Unfortunately there has been a proposal to implement this by equiping the 'level' command with more arguments, as:

level MPS TC INC [MPS2 TC2 INC2 ...]

MPS=0 means "rest of game", if the last session does not have MPS=0 it will be repeated for as long as the game lasts. Some engines actually implement this, and Arena sends it at the users request without knowing if the engine will understand it.

This is a silly proposal, as MPS=0 means rest of game, so that no later sessions can follow. Thus only the last group of 3 can have MPS=0. But in WB time controls, MPS != 0 implies INC=0. So it means that this way of extending the level command only leads to the insertion of a number of redundant zeros.

The proper way to implement it would be to have the engine tell the GUI that it can handle it through the 'features' command, by sending level=N, with N the maximum number of sessions it will accept. The WB proposal included this, but most engines don't seem to do it. As a result, in a properly implemented protocol, the GUI should never send the extended level command.

As even most the engines that do implement the secondary time controls do it in a way that is broken, and will have to be fixed, I want to make a counter proposal:

Through "features xlevel=N" (default: N=1) engines can enable an extended level command of the form:

level MPS TC [MPS2 TC2 ...] INC

leaving out the redundent zeros. INC will apply to the last mentioned session, and can only be non-zero if the MPS for that session is zero (so that the session is the last session of the game).

I prefer the redundancy, because it is not so uncommon to play fischer clock events where the increment is applied game-long, not just at the sudden-death point...

If mps time inc mps2 time2 inc2 has a little redundancy, it would still probably be better to cover every possible base, rather than having to deal with the exceptions later...

[Matthias Gemuh]

I prefer the redundancy, because it is not so uncommon to play fischer clock events where the increment is applied game-long, not just at the sudden-death point...

If mps time inc mps2 time2 inc2 has a little redundancy, it would still probably be better to cover every possible base, rather than having to deal with the exceptions later...

Your proposal sounds also OK for me. We can even ignore the WB constraint that "MPS != 0 implies INC=0" for all sessions and set a new standard.
I doubt how old engines would react to that.

[bob]

I prefer the redundancy, because it is not so uncommon to play fischer clock events where the increment is applied game-long, not just at the sudden-death point...

If mps time inc mps2 time2 inc2 has a little redundancy, it would still probably be better to cover every possible base, rather than having to deal with the exceptions later...

Your proposal sounds also OK for me. We can even ignore the WB constraint that "MPS != 0 implies INC=0" for all sessions and set a new standard.
I doubt how old engines would react to that.

The good thing is that it probably doesn't matter how they react. Since winboard keeps the actual game clock, and continually informs both programs of the time remaining, the programs don't really even need to know about the time controls other than knowing the time left. That's actually how I handle xboard/winboard games, even though crafty supports time controls like

40/120 20/60 sd/30

(40 moves in 2 hours, 20 moves in one hour, then sudden death with 30 more minutes added... but I don't use any of that in winboard/xboard as I let the GUI keep up with the clock and just make a time allocation based on total time left...

[Uri Blass]

Tjere is no official syntax for secondary and tertiary time controls in WB protocol.

Unfortunately there has been a proposal to implement this by equiping the 'level' command with more arguments, as:

level MPS TC INC [MPS2 TC2 INC2 ...]

MPS=0 means "rest of game", if the last session does not have MPS=0 it will be repeated for as long as the game lasts. Some engines actually implement this, and Arena sends it at the users request without knowing if the engine will understand it.

This is a silly proposal, as MPS=0 means rest of game, so that no later sessions can follow. Thus only the last group of 3 can have MPS=0. But in WB time controls, MPS != 0 implies INC=0. So it means that this way of extending the level command only leads to the insertion of a number of redundant zeros.

The proper way to implement it would be to have the engine tell the GUI that it can handle it through the 'features' command, by sending level=N, with N the maximum number of sessions it will accept. The WB proposal included this, but most engines don't seem to do it. As a result, in a properly implemented protocol, the GUI should never send the extended level command.

As even most the engines that do implement the secondary time controls do it in a way that is broken, and will have to be fixed, I want to make a counter proposal:

Through "features xlevel=N" (default: N=1) engines can enable an extended level command of the form:

level MPS TC [MPS2 TC2 ...] INC

leaving out the redundent zeros. INC will apply to the last mentioned session, and can only be non-zero if the MPS for that session is zero (so that the session is the last session of the game).

I think that it is better to keep the redundent zeros because there are engines that support them.

You may also want to support testing with different INC in the first 40 moves and in the rest of the games and it is better to support more options for time control(I practically never used different increasement in testing but I see no reason not to support this option).

Uri

[Matthias Gemuh]

Hi Harm,
after reading the opinions of Uri and Dr.Hyatt, I suggest that we should agree on level MPS TC INC [MPS2 TC2 INC2 ...] , ignoring the MPS!=0 constraint.
Matthias.

[hgm]

Well, I tried to google for engines that do support this, and the only engines that I could find that advertized this feature turned out to violate WB protocol to such an extent that they wouldn't work anyway, even if we would implement it the way Uri suggests.

So to know what we are talking about:

Which engines exactly do support this feature, and which of those do it in an acceptable way (requesting it through a features command)?

What Bob says is only true to a limited extent: engines won't lose on time, but they might start distributing time in such a funny way over the game that it results in a certain loss due to being outsearched too much in an extended phase of the game (e.g. facing 10:1 time odds).

[Uri Blass]

Well, I tried to google for engines that do support this, and the only engines that I could find that advertized this feature turned out to violate WB protocol to such an extent that they wouldn't work anyway, even if we would implement it the way Uri suggests.

So to know what we are talking about:

Which engines exactly do support this feature, and which of those do it in an acceptable way (requesting it through a features command)?

What Bob says is only true to a limited extent: engines won't lose on time, but they might start distributing time in such a funny way over the game that it results in a certain loss due to being outsearched too much in an extended phase of the game (e.g. facing 10:1 time odds).

I believe that movei as a winboard engine support it.
It does not tell nothing to the interface about supporting it but if it gets extended level command then it is probably going to understand it.

I did not do much testing of it so I am not sure that I have no bugs but you can try it.

You can tell it even extreme time control like 40 minutes/10 moves+1 minute for the rest of the game and find if it is going to use less time for the first moves relative to 40 minutes/10 moves+1000 minutes/rest of the game(it is clearly supposed to do it).

Uri