My main gripe with the xboard protocol is that it is underspecified. One constantly has to worry about random things such what is the effect of a time command during force mode, or what is the effect of undo after a level command. Or what should the engine do if it receives a ping during analysis.
The xboard protocol works well because xboard sends its commands in a very disciplined manner and engines have adapted to that. But other GUI's might do it differently.
protocol specs
Moderator: Ras
-
Michel
- Posts: 2292
- Joined: Mon Sep 29, 2008 1:50 am
Re: protocol specs
Oops. This was not supposed to be a new topic. Sorry.
-
hgm
- Posts: 28387
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: protocol specs
I don't see the problem with the time command:
time sets the engines own clock. otim sets the opponent's clock. Clocks are stopped in force mode and only run when the engine is playing black or white (but not in the initial position). So if the engine changes color, or gets assigned a color after force mode, the time on its _internal_ clock is not supposed to be changed by that. If the engine was playing white, and white had 3 min left on the GUI clock, and its internal clock was in sync, and black is to move, and it now receives a 'go' command, the engine is supposed to assume that it still has 3 min on its clock. Even if black has 10 min on the GUI clock, and the engine knew that.
This is non-sensical, of course (i.e. you would not ever want that), which means that the GUI _must_ send new time and otim commands befre it sends 'go', to set the engines time to 10 min, and the opponent time to 3 min.
This might be cumbersome, or even ridiculous, but it is well-defined.
Level during a game might indeed be under-specified. This cold be taken to mean (and indeed originally was taken to mean) that it cannot be used during a game. Come to think of it, the effect of 'undo' on the clocks is completely unspecified. Should the engine assume it also gets the time back?
But it does not always have to be a problem to have the effect of a command not fully defined, or even explicitly undefined. Iw we would ad to the specs; "the effect of the undo command on the internal engine clocks could be anyything. They could remain unchanged, they could be reset to the stae of before the move, they could be reset to the time at the beginning of game, or they could get a random number of hours added to them". That just means the protocol puts the burdon on the GUI to reset the cocks after 'undo', before setting the engines playing again. If it wouldn't, it would be a broken implementation. (Though not incompliant.) The protocol simply leaves no roomto do it differently.
Ping during analysis seems illegal. The specs say which commands are allowed during analyze mode, and 'ping' is not amongs them.
I admit I am not happy with the definition of analyze mode as a game mode. It would be much more logical to consider it a third ponder mode, which allows the engine to ponder the position in force mode. (So in stead of ponder on/off you would have ponder never / during opponent think / always.) analyze would then simply be force mode, and you would not need a special set of commands for analyze mode.
I would be inclined to think that the protocol specs should be interpreted with the rule "effect that are not specified are non-existent". I.e. undo is not specified to have any effects on clock or TC, so it should have no effect on either of those. you will not get the time for the undone move back. Even worse, if you are set playing after undo, you will still be using the time you previously had for the other color. Thus the GUI _must_ send new time and otim commands to evoke sensible behavior.
Undo is not specified to have any effect on TC parameters. So they stay as they were. (It is specified to have an effect on the game state, though, which is supposed to contain move number. Undoing a move gives that side one extra move to go to the next TC, whatever that was.)
time sets the engines own clock. otim sets the opponent's clock. Clocks are stopped in force mode and only run when the engine is playing black or white (but not in the initial position). So if the engine changes color, or gets assigned a color after force mode, the time on its _internal_ clock is not supposed to be changed by that. If the engine was playing white, and white had 3 min left on the GUI clock, and its internal clock was in sync, and black is to move, and it now receives a 'go' command, the engine is supposed to assume that it still has 3 min on its clock. Even if black has 10 min on the GUI clock, and the engine knew that.
This is non-sensical, of course (i.e. you would not ever want that), which means that the GUI _must_ send new time and otim commands befre it sends 'go', to set the engines time to 10 min, and the opponent time to 3 min.
This might be cumbersome, or even ridiculous, but it is well-defined.
Level during a game might indeed be under-specified. This cold be taken to mean (and indeed originally was taken to mean) that it cannot be used during a game. Come to think of it, the effect of 'undo' on the clocks is completely unspecified. Should the engine assume it also gets the time back?
But it does not always have to be a problem to have the effect of a command not fully defined, or even explicitly undefined. Iw we would ad to the specs; "the effect of the undo command on the internal engine clocks could be anyything. They could remain unchanged, they could be reset to the stae of before the move, they could be reset to the time at the beginning of game, or they could get a random number of hours added to them". That just means the protocol puts the burdon on the GUI to reset the cocks after 'undo', before setting the engines playing again. If it wouldn't, it would be a broken implementation. (Though not incompliant.) The protocol simply leaves no roomto do it differently.
Ping during analysis seems illegal. The specs say which commands are allowed during analyze mode, and 'ping' is not amongs them.
I admit I am not happy with the definition of analyze mode as a game mode. It would be much more logical to consider it a third ponder mode, which allows the engine to ponder the position in force mode. (So in stead of ponder on/off you would have ponder never / during opponent think / always.) analyze would then simply be force mode, and you would not need a special set of commands for analyze mode.
I would be inclined to think that the protocol specs should be interpreted with the rule "effect that are not specified are non-existent". I.e. undo is not specified to have any effects on clock or TC, so it should have no effect on either of those. you will not get the time for the undone move back. Even worse, if you are set playing after undo, you will still be using the time you previously had for the other color. Thus the GUI _must_ send new time and otim commands to evoke sensible behavior.
Undo is not specified to have any effect on TC parameters. So they stay as they were. (It is specified to have an effect on the game state, though, which is supposed to contain move number. Undoing a move gives that side one extra move to go to the next TC, whatever that was.)
-
Michel
- Posts: 2292
- Joined: Mon Sep 29, 2008 1:50 am
Re: protocol specs
It makes sense the say that when something is not specified its effect is undefined. However it takes a lot of effort to see if corner cases (there are many) are specified or not. And even then it is not always very clear.
For example the description of analysis lists the commands the engine should accept. It does not say it should not accept any other commands. If fact
many engines accept post/nopost during analysis which are not listed.
Ideally a stateful protocol like the xboard protocol should be specified formally. Unfortunately that would be a huge job.
For example the description of analysis lists the commands the engine should accept. It does not say it should not accept any other commands. If fact
many engines accept post/nopost during analysis which are not listed.
Ideally a stateful protocol like the xboard protocol should be specified formally. Unfortunately that would be a huge job.
-
hgm
- Posts: 28387
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: protocol specs
Well, if the effect of post / nopost is undefined, the engines would be justified to take it as switching posting on or off. Not sure if it makes much sense to do analysis without posting though. I see no reason why any command that can be given in force mode should not be acceptable in analyze mode, with the same effect. But unfortunately, there will be engines around that cannot handle that. So although the specs do not forbid engine to understand more commands, it forbids GUIs to send them. Which amounts to the same thing.
I want to introduce a feature post=1, which would allow post to be sent with two parameters, specifying minimum maximum time intervals for reporting intra-iteration data (PV change, move change, node count). This could also be defined to imply post / nopost are allowed in analysis mode, and that the engine uses an extended Thinking-Output format to replace stat01 lines to send such data.
I want to introduce a feature post=1, which would allow post to be sent with two parameters, specifying minimum maximum time intervals for reporting intra-iteration data (PV change, move change, node count). This could also be defined to imply post / nopost are allowed in analysis mode, and that the engine uses an extended Thinking-Output format to replace stat01 lines to send such data.
-
Michel
- Posts: 2292
- Joined: Mon Sep 29, 2008 1:50 am
Re: protocol specs
Why do you interprete the specs in this way? The description of the post command saysWell, if the effect of post / nopost is undefined,
post
Turn on thinking/pondering output.
It does not say that it cannot be sent during analysis.
The description of the analysis command lists a minimal number of commands that the engine should support during analysis in order to be compiiant. It does NOT say that the GUI cannot send any other commands from the xboard protocol.
If that is the intention then it should be explicitly specified to remove ambiguity..
-
hgm
- Posts: 28387
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: protocol specs
I interpreted it that way because the list of commands was extended from protocol v1 to v2. If all commands in the are required, you could not do that, and still have v1 engines be compliant with the protocol. Furthermore, some of the added commands are already optional in themselves, even outside the context of analyze mode: the specs say 'hint' can be ignored when the engine has no move to suggest. (And since the engine apparently can decide when that is the case, it might decide it never has a move to suggest, i.e. not implement the command at all.) And 'bk' by nature is also optional, as an engine might not have a book. Asking for a hint during analyze mode seems totally useless, btw.
But I don't like the consequences of that interpretation very much, so I will be easy to convince.
Why is 'new' in the list, btw? Are there really GUIs that send 'new' during analyze? WinBoard does not seem to do this. At least, when I click 'New Game' in the menu it dutifully leaves analyze mode, and goes to 'machine black'. And I would not know how else to trigger sending of 'new'.
It seems the meaning of 'new' in analyze mode is defined different from the normal 'new'. In particular, that it should leave the engine in analyze mode, rather than let it play black. I guess some other tweeks to the definition are needed as well, to have it make sense in the context of variants? In particular, it makes no sense to have 'new' switch back the variant to 'normal' in that case.
I am not sure why 'exit' is needed; if unlisted commands would have their normal effect, it seems that 'force' would do the same as 'exit'.
But I don't like the consequences of that interpretation very much, so I will be easy to convince.
Why is 'new' in the list, btw? Are there really GUIs that send 'new' during analyze? WinBoard does not seem to do this. At least, when I click 'New Game' in the menu it dutifully leaves analyze mode, and goes to 'machine black'. And I would not know how else to trigger sending of 'new'.
It seems the meaning of 'new' in analyze mode is defined different from the normal 'new'. In particular, that it should leave the engine in analyze mode, rather than let it play black. I guess some other tweeks to the definition are needed as well, to have it make sense in the context of variants? In particular, it makes no sense to have 'new' switch back the variant to 'normal' in that case.
I am not sure why 'exit' is needed; if unlisted commands would have their normal effect, it seems that 'force' would do the same as 'exit'.