Losing on time

[bob]

Thanks, everyone! With some detailed logging I was able to track it down. No wonder I couldn't find it - I was looking in totally the wrong place.

Turns out it was related to the switch from Arena to CuteChess. CuteChess doesn't send the "white" and "black" commands to xboard engines and I was relying on that (which isn't correct for protocol version 2 engines like Quadrox.) So, sometimes it thought the time remaining was actually the opponent's time remaining.

So now I'm not losing on time anymore. I'm still getting way fewer wins than I was under Arena, though, so I wonder what else is wrong... I'll look at the debug outputs of the programs and see if they send other commands differently...

Cheers,
Greg

Surely you mean "time" and "otim" which are the commands it sends to tell you how much time you (time) and opponent (otim) have left on clock???

The "white" and "black" commands tell the engine what side it is playing so that when it receives the "time" and "otim" commands it knows which side is which. Those are obsolete now, so I guess whenever the engine is asked to think it should use "time" for that side...

'time' is ALWAYS your time. "otim" is ALWAYS opponent's time. Doesn't matter which color you are playing. Xboard is communicating directly with your program via a socket, so it knows which side you are playing and how much time you have left...

[JVMerlino]

The 'white' and 'black' commands primarily tell the engine which side currently has the move. They should be considered as part of the 'edit' command for setting up position (which just alters the board state, but leaves the side to move unchanged).

The "white" and "black" commands are indeed declared obsolete. However, the link I have shows this for the "white" command:

"Set White on move. Set the engine to play Black. Stop clocks."

So Greg using the command to tell the engine which side to play seems valid. Unless I'm missing something....? But, indeed, it is the much clearer "go" command which is really the one that tells the engine which side it should play.

jm

[hgm]

The 'go' command can only tell the engine to play the side to move. 'new', 'white' and 'black' tell the engine to play the side that does not have the move, and can affect which side actually has the move. For the latter they are essential. But of course you would almost never want to change the side to move.

I guess the protocol specs are not complete: they do not define what happens when you try to backup past a 'white' or 'black' command with an 'undo' command. You could send a number of moves to the engine in force mode, then send (say) 'white' to change the side to move (i.e. effectively play a null move), then 'force' to get back to force mode, and then some more moves. Now when you 'undo', could you undo that null move, and the moves before it?

[JVMerlino]

I guess the protocol specs are not complete: they do not define what happens when you try to backup past a 'white' or 'black' command with an 'undo' command. You could send a number of moves to the engine in force mode, then send (say) 'white' to change the side to move (i.e. effectively play a null move), then 'force' to get back to force mode, and then some more moves. Now when you 'undo', could you undo that null move, and the moves before it?

My brain hurts....

I tried this in Myrddin in console mode and it behaved as expected, once my brain stopped hurting. Your "null move" isn't really a move in the move list, of course. It's just a changing of the side to move. So I did the following commands:

new
force
a2a3
a7a6
h2h3
white
force
e2e3
h7h6

and then confirmed that white had moved three pawns, black had moved two and it was white to move.

I then did five "undo" commands in a row and returned to the starting position, but with black to move.

jm

[hgm]

It depends on the implementation, I guess. Most of my engines (e.g. Fairy-Max) implement 'undo' by resetting the game, and replaying the move list up to the desired point. Then any undo that would not bring you to before the 'white' would cause trouble: Fairy-Max would reject the moves after it during replay, as they were made by the wrong side. In HaQiKi D, which doesn't do legality checking of any kind, you would be able to play to the fore-last move (for one undo), but then you would end up with the wrong side to move, and only backing up to before the 'white' would work properly.

There could also be implementations that clear the move list, and consider the position with the opposite side to move as a starting position of a new game. Of course the specs also do not define what should happen when you try to 'undo' past a 'new' or 'setboard' command.

[Sven]

It depends on the implementation, I guess. Most of my engines (e.g. Fairy-Max) implement 'undo' by resetting the game, and replaying the move list up to the desired point. Then any undo that would not bring you to before the 'white' would cause trouble: Fairy-Max would reject the moves after it during replay, as they were made by the wrong side. In HaQiKi D, which doesn't do legality checking of any kind, you would be able to play to the fore-last move (for one undo), but then you would end up with the wrong side to move, and only backing up to before the 'white' would work properly.

There could also be implementations that clear the move list, and consider the position with the opposite side to move as a starting position of a new game. Of course the specs also do not define what should happen when you try to 'undo' past a 'new' or 'setboard' command.

"white" and "black" were never meant as anything that can be "undone" like a move. So I suggest that we should not create such an artificial interpretation for obsolete protocol elements. Let them rest in peace, please ... They were part of "idioms" that were only useful for GNUchess (and possibly few other older engines) in the past. Nobody should rely on them today in his engine, and everyone should send "feature colors=0" to let the GUI avoid sending "white" and "black" at all. A proper implementation of the "time", "otim", "force", "go" and possibly also "playother" commands will be sufficient to ensure that "white" and "black" are never needed.

If you would insist on adding a consistent specification of the behaviour of "white" and "black" in the context of "undo" as you described above then I would come back to your earlier remark: if "white" has been sent in a position with black to move (which would be the case in the "white - time N - otim N - black - go" idiom only) then consider it as part of an "edit" command (even if it isn't actually the case), so it changes the current position, so the whole previous game history should be lost. Undoing past a "white" (or "black") should have no effect. But I do not suggest to add any king of clarification regarding "white" or "black" to the specs, I simply suggest to follow the current specs as written above.

Sven

[hgm]

I agree that it would be best to treat it as an 'edit'. But strangely enough the specs also do not mention what would happen if you backup past an 'edit'/'setboard', or even a 'new'. I guess I should at least remark this will result in undefined behavior of the 'undo' and 'remove' commands.

'black' still seems needed to set up positions with black to move, however, after an 'edit'. It would horribly complicate the life of a GUI developer if he had to use the move kludge to change the side to move after a 'new', when a2 was empty in that case.

[Sven]

I agree that it would be best to treat it as an 'edit'. But strangely enough the specs also do not mention what would happen if you backup past an 'edit'/'setboard', or even a 'new'. I guess I should at least remark this will result in undefined behavior of the 'undo' and 'remove' commands.

Why "undefined behavior"? "edit" and "setboard" change the current position, so why keep the previous game history? What do you think should happen to the move history on "setboard"? I clear it, of course, since I *can't* go back to the situation prior to a "setboard", so there is nothing that the moves that happened prior to "setboard" could be used for. They simply disappear by setting the ply to 0, so "undo" and "remove" have nothing to take back any longer at that point.

'black' still seems needed to set up positions with black to move, however, after an 'edit'. It would horribly complicate the life of a GUI developer if he had to use the move kludge to change the side to move after a 'new', when a2 was empty in that case.

You are talking about chess variants that do not have a2a3 as a legal move in their initial position. That is right. But then there is "setboard". Actually I am not too familiar with chess variants, so may I ask you: is there any chess variant that requires to use "edit" instead of "setboard" *and* has no a2a3 in the initial position? Only in such a case I think that there would still be a need for the "black" command.

Definitely not for standard chess, of course.

Sven

[bob]

It depends on the implementation, I guess. Most of my engines (e.g. Fairy-Max) implement 'undo' by resetting the game, and replaying the move list up to the desired point. Then any undo that would not bring you to before the 'white' would cause trouble: Fairy-Max would reject the moves after it during replay, as they were made by the wrong side. In HaQiKi D, which doesn't do legality checking of any kind, you would be able to play to the fore-last move (for one undo), but then you would end up with the wrong side to move, and only backing up to before the 'white' would work properly.

There could also be implementations that clear the move list, and consider the position with the opposite side to move as a starting position of a new game. Of course the specs also do not define what should happen when you try to 'undo' past a 'new' or 'setboard' command.

"white" and "black" were never meant as anything that can be "undone" like a move. So I suggest that we should not create such an artificial interpretation for obsolete protocol elements. Let them rest in peace, please ... They were part of "idioms" that were only useful for GNUchess (and possibly few other older engines) in the past. Nobody should rely on them today in his engine, and everyone should send "feature colors=0" to let the GUI avoid sending "white" and "black" at all. A proper implementation of the "time", "otim", "force", "go" and possibly also "playother" commands will be sufficient to ensure that "white" and "black" are never needed.

If you would insist on adding a consistent specification of the behaviour of "white" and "black" in the context of "undo" as you described above then I would come back to your earlier remark: if "white" has been sent in a position with black to move (which would be the case in the "white - time N - otim N - black - go" idiom only) then consider it as part of an "edit" command (even if it isn't actually the case), so it changes the current position, so the whole previous game history should be lost. Undoing past a "white" (or "black") should have no effect. But I do not suggest to add any king of clarification regarding "white" or "black" to the specs, I simply suggest to follow the current specs as written above.

Sven

You really need SOME way to tell the engine which color to play. After "edit position" and setting white to move, there has to be some way to tell the engine to start a search for the XXX side. The engine might use "seaboard" which tells it, or it might use the old (and really something to get rid of) "edit" command.

My choice would be just allowing a FEN string to set a position, followed by the (obviously) side to move which is a part of the FEN description. The other way to set a position is through "edit game" which stuffs moves into the program as was added to support Crafty on ICC many years ago. (Gnuchessx only used "edit" which let humans create unwanted (by me) drawing changes by disconnecting in a position with lots of checks, then re-starting, which lost the move/repetition list and allowed Crafty to stumble into draws because it had no idea the position had previously occurred.)

[bob]

I agree that it would be best to treat it as an 'edit'. But strangely enough the specs also do not mention what would happen if you backup past an 'edit'/'setboard', or even a 'new'. I guess I should at least remark this will result in undefined behavior of the 'undo' and 'remove' commands.

'black' still seems needed to set up positions with black to move, however, after an 'edit'. It would horribly complicate the life of a GUI developer if he had to use the move kludge to change the side to move after a 'new', when a2 was empty in that case.

I would say declare it "undefined" and then do something ugly when it happens. Ought to make all the "undefined behavior" fans quite happy.