New Time Controls for WB

[hgm]

Or better yet, use the level command for deprecated backward compatibility, but encourage the use of the modern and more flexible alternative (giving it a new name.)

Well, that definitely is a possibility. We could send

session 1 MPS1 TC1 INC1
session 2 MPS2 TC2 INC2
session 3 MPS3 TC3 INC3
...

where session 1 by definition starts with the move to be done next.

Although sending all sessions at the beginning of the game, I still would like to put in the specs that the GUI would have to send a new set of session commands at the start of every new session, if this set would be different from the previously sent set. I.e., it could refrain from resending the last session again, when it repeats, which means that simple time controls would behave exctly the same way as the level command behaves now.

This makes the implementation of engines that feel no need to guard against maliciously designed time controls, such as 40/60min + 1sec/game: they could just use the first session command, and ignore the rest. Or, if they are slightly more paranoic, only use the first two.

On the other hand, there might actually be applications for maliciously designed time controls. So I can imagine that a GUI could be set to intentionally withold the later sessions from the engines, letting them play as if they would be at a classical TC (#moves/#min, repeating), and then suddenly switching to a very fast sudden-death control to force a game decision (possibly taking away any leftover time).

[Don]

Presumably, if a session is not specified it is the same as the previous session, right?

Or better yet, use the level command for deprecated backward compatibility, but encourage the use of the modern and more flexible alternative (giving it a new name.)

Well, that definitely is a possibility. We could send

session 1 MPS1 TC1 INC1
session 2 MPS2 TC2 INC2
session 3 MPS3 TC3 INC3
...

where session 1 by definition starts with the move to be done next.

Although sending all sessions at the beginning of the game, I still would like to put in the specs that the GUI would have to send a new set of session commands at the start of every new session, if this set would be different from the previously sent set. I.e., it could refrain from resending the last session again, when it repeats, which means that simple time controls would behave exctly the same way as the level command behaves now.

This makes the implementation of engines that feel no need to guard against maliciously designed time controls, such as 40/60min + 1sec/game: they could just use the first session command, and ignore the rest. Or, if they are slightly more paranoic, only use the first two.

On the other hand, there might actually be applications for maliciously designed time controls. So I can imagine that a GUI could be set to intentionally withold the later sessions from the engines, letting them play as if they would be at a classical TC (#moves/#min, repeating), and then suddenly switching to a very fast sudden-death control to force a game decision (possibly taking away any leftover time).

[Michel]

This whole extended session/level command thing seems to me a solution in search of a problem. I have seen no arguments why a redesign is needed or even desirable.

[bob]

Presumably, if a session is not specified it is the same as the previous session, right?

Or better yet, use the level command for deprecated backward compatibility, but encourage the use of the modern and more flexible alternative (giving it a new name.)

Well, that definitely is a possibility. We could send

session 1 MPS1 TC1 INC1
session 2 MPS2 TC2 INC2
session 3 MPS3 TC3 INC3
...

where session 1 by definition starts with the move to be done next.

Although sending all sessions at the beginning of the game, I still would like to put in the specs that the GUI would have to send a new set of session commands at the start of every new session, if this set would be different from the previously sent set. I.e., it could refrain from resending the last session again, when it repeats, which means that simple time controls would behave exctly the same way as the level command behaves now.

This makes the implementation of engines that feel no need to guard against maliciously designed time controls, such as 40/60min + 1sec/game: they could just use the first session command, and ignore the rest. Or, if they are slightly more paranoic, only use the first two.

On the other hand, there might actually be applications for maliciously designed time controls. So I can imagine that a GUI could be set to intentionally withold the later sessions from the engines, letting them play as if they would be at a classical TC (#moves/#min, repeating), and then suddenly switching to a very fast sudden-death control to force a game decision (possibly taking away any leftover time).

I'm not sure how I would use the "session number"

I don't currently do this, but in Cray Blitz all I needed was

(1) remaining move until next time control (session in this terminology I suppose) and how much time is left on the clock.

(2) how many moves in the next time control period (session) and how much time will I gain?

I used (2) to help me during (1). If I build up some extra time during (1) due to ponder hits or instant moves I might want to use it (or part of it) during the current session, or I might want to save it for the next session, particularly if the next session is "sudden death".

There is a subtle race condition in sending this stuff that can cause some grief, as when we cross a time-control boundary, and a new "level" command comes in, in Crafty I have already updated the clocks for the new time control, set a target time, and started a new search. A new search sets up some things based on the time control, and if a new level command comes in after this point, it is not easy to re-adjust everything.

I'm thinking that my old time code probably needs to go away, and I simply ignore time control boundary adjustments and let the level (or new command) handle this completely. I suppose it is workable to not know the next time control's values until it actually arrives.

Given that, I think the current "level" command works just fine, so long as the GUI sends the information right after the appropriate move is made. In that case, I'd modify the way I do things and remove the code that keeps up with time controls completely, which would be significantly simpler than what I currently am doing. After move 40 (assuming a level 40 N inc) level was used first, the current new level command can set everything needed, and Crafty won't be worrying about reaching move 40 and updating the clock itself, the next level command will do that...

[hgm]

I agree that normally you would not be interested in looking further than the next session, if that session had a reasonable number of moves. (I guess that when in a 40 moves / 60 min, knowing that the session to follow is 1 move in 1 min, would make you curious about what to expect after that.)

It occurred to me that UCI engines might also have problems whit 'treacherous' time controls, where the GUI first lies about the future session, and then alters the parameters when the session starts. Due to the design flaw in UCI, engines will have to know the parameters for the current session before they start pondering about it...

Treacherous time controls are not of major importance, though; in practice they would hardly ever be used. So it is not that bad if things work slightly suboptimally in that case. I.e., if we want to redefine the TC settings of an engine while it was already pondering with wrong TC parameters, it would be OK to tell it it had a ponder miss, give it the proper TC settings + move (which in reality was a ponder hit), and start a normal search.

[hgm]

This whole extended session/level command thing seems to me a solution in search of a problem. I have seen no arguments why a redesign is needed or even desirable.

Well, engines could prefer to leave some time on their clock at move 40 if they know a 40/60min session will be followed by 5min sudden death, rather than using it all up. Wouldn't that be a good argument?

[Volker Annuss]

Hi Harm Geert,

the level command has already been discussed long time ago. Some GUIs including arena already support an extended level command.

Greetings
Volker


Edit: Sorry, URLs with brackets don't work inside URL tags with a different text here.
http://www.horizonchess.com/FAQ/Winboard/Winboard6.html#[F.6]

[Don]

This whole extended session/level command thing seems to me a solution in search of a problem. I have seen no arguments why a redesign is needed or even desirable.

Well, engines could prefer to leave some time on their clock at move 40 if they know a 40/60min session will be followed by 5min sudden death, rather than using it all up. Wouldn't that be a good argument?

In theory a program should have all information available to it that could be useful in making any kind of decision. None of the existing protocols provide this information, so this is a step in the right direction.

One example that is rarely considered is the rating of the opponent, or even who the opponent is. Human players almost always have this information available and we make use of it. But computers are rarely given this information.

Having said that, the human operators of program often provide that information in an implicit way - by setting the contempt factor based on who the opponent is, or by changing books based on who the opponent is.

[hgm]

Yes, I know about this proposal, and I originaly proposed to use this format for engines that explicitly mention to support multi-session TC through an appropriate feature. (With the added spec that the GUI would have to resend a level command at the start of each session.)

But I met a lot of resistance from engine programmers, which did not like commands of unspecified length, and preferred the command to be broken up over several lines. I guess they have a point that the proposed format is not so easy to parse, though. Especially when the TC arguments are strings that can contain ':' so you cannot simply use sscanf with 6 integers and leave it at that. So I am sympathetic to the idea that there should be some delimiter between the groups; that would increase readablilty as well. I would prefer it on a single line, though, like

level MPS1 TC1 INC1; MPS2 TC2 INC2; ...

That would make the parsing again quite trivial:

Code: Select all

char *p = inBuf + 5;
do {
  // do what you normally do
  int sec = 0;
  sscanf(++p, "%d %d:%d %d", &mps, &tc, &sec, &inc) == 4 ||
  sscanf(p, "%d %d %d", &mps, &tc, &inc);
  tc = tc*60 + sec;
  ...
} while(p = strchr(p, ';')); // but repeat it as long as there follows ';'

[Don]

Yes, I know about this proposal, and I originaly proposed to use this format for engines that explicitly mention to support multi-session TC through an appropriate feature. (With the added spec that the GUI would have to resend a level command at the start of each session.)

But I met a lot of resistance from engine programmers, which did not like commands of unspecified length, and preferred the command to be broken up over several lines. I guess they have a point that the proposed format is not so easy to parse, though. Especially when the TC arguments are strings that can contain ':' so you cannot simply use sscanf with 6 integers and leave it at that. So I am sympathetic to the idea that there should be some delimiter between the groups; that would increase readablilty as well. I would prefer it on a single line, though, like

level MPS1 TC1 INC1; MPS2 TC2 INC2; ...

That woould make the parsing again quite trivial:

Code: Select all

char *p = inBuf + 5;
do {
  // do what you normally do
  sscanf(++p, "%d %d:%d %d", &mps, &tc, &sec, &inc) == 4 ||
  sscanf(p, "%d %d %d", &mps, &tc, &inc);
  ...
} while(p = strchr(p, ';')); // but repeat it as long as there follows ';'

I really prefer the single line format too. To me this is SIMPLER, but to each his own. I don't like tracking extra state between parsing periods when it can just be done all at once.