Don wrote: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.
WinBoard does send ratings (and opponent names) to the engine (of course!):
WB protocol specs wrote:rating
In ICS mode, xboard obtains the ICS opponent's rating from the "Creating:" message that appears before each game. (This message may not appear on servers using outdated versions of the FICS code.) In Zippy mode, it sends these ratings on to the chess engine using the "rating" command. The chess engine's own rating comes first, and if either opponent is not rated, his rating is given as 0. In the future this command may also be used in other modes, if ratings are known.
Don wrote: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.
WinBoard does send ratings (and opponent names) to the engine (of course!):
I did not know that. It's a good feature to have.
WB protocol specs wrote:rating
In ICS mode, xboard obtains the ICS opponent's rating from the "Creating:" message that appears before each game. (This message may not appear on servers using outdated versions of the FICS code.) In Zippy mode, it sends these ratings on to the chess engine using the "rating" command. The chess engine's own rating comes first, and if either opponent is not rated, his rating is given as 0. In the future this command may also be used in other modes, if ratings are known.
OK, this sounds like a good proposal, and I like it much better than a command split up over multiple lines. Xlevel should be a boolean feature, so that people switch on this new format by feature xlevel=1 . (The default value will of course be 0, meaning only one sessionper level command.) The extended level commands should be sent just before the time command that goes with the opponent's last move of the previous session, or with the go command for the first move of the new session. (So that the time command can give a more precise value.)
One thing: would the TC parameter for the first session for such a 'reminder' contain the nominal duration of the session, or the time left on the clock? I am in favor of the nominal duration (because it might be a session that will repeat indefinitely, and the engine then has an unambiguous advance idea of how much time it will get for these future sessions). The actual time left will be sent immediately afterwards by the time command.
We have to add specs for how to handle undo, and I think we should put the burdon on the GUI to inform the engine of the TC change also when you pass it in the backward direction. The engine should just increment its internal 'movestogo' counter when it undoes one of its own moves, assuming it stys in the TC session it was in. If that is not the case, the GUI should send it a new level command (with MPS=1), to indiate that the following time command will be relative to another move than before. (Note that what the engine does is different from what xlevel=0 engines do: they would have to take the movestogo counter modulo MPS after increasing it!)
I will implement this similarly in WinBoard, and add it to the protocol specs.
This of course is completely independent from the hack to make existing engines (which obviously will not support the xlevel feature) work. Your research has shown that most WinBoard engines seem to work well with the relative use of intra-game level commands. We could adapt Polyglot to make sure it works with the hack, so all UCI engines would be able to handle it under WinBoard too. (GUIs that run UCI engines directly can of course implement it themselves by sending the proper movestogo and wtime/btime commands.) UCI does not allow the engines a preview of multi-session TCs, so I guess the UCI engines would be limited to what WB engines can do with the hack, so there is no need / advantage in implementing the xlevel feature in Polyglot. We should just make sure it properly understands the intra-game level commands.
For maximum backward compatibility, the kludge used on engines with xlevel=0 should NOT resend a level command when the session is indefinietly repeating, so that simple TCs will not ivolve any intra-game level commands.
I guess a good implementation would offer the user a per-engine choice to use the intra-level command or some alternative scheme, such as starting a new game with a level command which combines all elapsed sessions with the one to come, and feed it all the moves. This will certainly work for any engine, but might disadvantage it a little, because the new comamand might clear its hash table and disturb its pondering. (But it is always better than having it crash... And perhaps the GUI could compensate it by allowing it a little extra time.)
We could adapt Polyglot to make sure it works with the hack, so all UCI engines would be able to handle it under WinBoard too.
You are right that Polyglot currently does not handle relative level commands correctly. But it is easy to implement. I can do it.
PS. I find the term "hack" too derogatory for relative level commands. This is just
a natural tightening of the spec of the traditional level command. The naturality is reflected in the fact that most engines already implement it!
Perhaps 'kludge' would be a better word. It is not truly kosher to confront engines with a protocol extension that did not exist when they were built, no matter how natural they are. The proper way would be to define a feature for it, and only use it on engines that send this feature. Which, of course, would be defeating the purpose of having it work for existing engines.
Solving it by starting a new game at every new TC session would be a 100% clean way to solve it protocol-wise, but might in practice hurt the engine more by disturbing ponder and clearing hash.
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.
