CSVN Programmers' Tournaments May 2014

xmas79 · Post by **xmas79** » Sun May 04, 2014 10:18 am

Hi,
please point me to a documentation that specifies how setboard should be use (WRT color & engine mode). I found only
http://www.open-aurec.com/wbforum/WinBo ... ntf.html#8 and
http://www.gnu.org/software/xboard/engine-intf.html#8.

But apart from this, what's wrong with the output I gave if the behaviour of my engine is exactly what you (and me) described?

hgm · Post by **hgm** » Sun May 04, 2014 6:25 pm

Setboard does not set the engine to play, does it? I always assumed that it should leave the engine in force mode (when I was writing engines). I had a peek in the protocol specs, and I could not find anything about this. (But I might have missed it). Except that when you receive 'setboard' in analyze mode it should leave the engine in analyze mode. This kind of suggests that in general setboard should leave the engine in the mode it is in. But as XBoard only sends a setboard after putting the engine in force mode first, (and never in analyze mode, which has to be left anyway for Edit Position mode in order to generate the position), the difference becomes a moot point.

All my engines that implement setboard switch to force mode when receiving it, if they were not already there. This never caused any problems with WinBoard. This implies that setting the engine to play either color on setboard must cause problems, as apparently WinBoard sends a 'go' after it to set the engine playing. And an extra 'go' is not at all harmless, because on engines that already start playing by themselves after receiving the move, that 'go' would be interpreted after they moved, and then set it playing for the other side!

xmas79 · Post by **xmas79** » Sun May 04, 2014 7:31 pm

hgm wrote:... because on engines that already start playing by themselves after receiving the move...

I suppose these engines are in play mode after a setboard like mine, otherwise they would not start to play after receiving a move... It was my first "error" in implementing the protocol, I waited for a "go" after the "usermove", a "go" that never arrived (I don't recall the specific situation though).

The spec is far from being clear IMHO.

hgm · Post by **hgm** » Sun May 04, 2014 10:15 pm

True, it is high time the specs are rewritten. But it really doesn't suggest anywhere that setboard should set the engine to play a specific side. And the model protocol driver is clear enough (at least for those that read C):

Code: Select all

    // recognize the command, and execute it
    if&#40;!strcmp&#40;command, "quit"))    &#123; break; &#125; // breaks out of infinite loop
    if&#40;!strcmp&#40;command, "force"))   &#123; engineSide = NONE;    continue; &#125;
    if&#40;!strcmp&#40;command, "analyze")) &#123; engineSide = ANALYZE; continue; &#125;
    if&#40;!strcmp&#40;command, "exit"))    &#123; engineSide = NONE;    continue; &#125;
    if&#40;!strcmp&#40;command, "level"))   &#123;
      int min, sec=0;
      sscanf&#40;inBuf, "level %d %d %d", &mps, &min, &inc&#41; == 3 ||  // if this does not work, it must be min&#58;sec format
      sscanf&#40;inBuf, "level %d %d&#58;%d %d", &mps, &min, &sec, &inc&#41;;
      timeControl = 60*min + sec; timePerMove = -1;
      continue;
    &#125;
    if&#40;!strcmp&#40;command, "protover"))&#123;
      printf&#40;"feature ping=1 setboard=1 colors=0 usermove=1 memory=1 debug=1");
      printf&#40;"feature option=\"Resign -check 0\"");           // example of an engine-defined option
      printf&#40;"feature option=\"Contempt -spin 0 -200 200\""); // and another one
      printf&#40;"feature done=1");
      continue;
    &#125;
    if&#40;!strcmp&#40;command, "option")) &#123; // setting of engine-define option; find out which
      if&#40;sscanf&#40;inBuf+7, "Resign=%d",   &resign&#41;         == 1&#41; continue;
      if&#40;sscanf&#40;inBuf+7, "Contempt=%d", &contemptFactor&#41; == 1&#41; continue;
      continue;
    &#125;
    if&#40;!strcmp&#40;command, "sd"))      &#123; sscanf&#40;inBuf, "sd %d", &maxDepth&#41;;    continue; &#125;
    if&#40;!strcmp&#40;command, "st"))      &#123; sscanf&#40;inBuf, "st %d", &timePerMove&#41;; continue; &#125;
    if&#40;!strcmp&#40;command, "memory"))  &#123; SetMemorySize&#40;atoi&#40;inBuf+7&#41;); continue; &#125;
    if&#40;!strcmp&#40;command, "ping"))    &#123; printf&#40;"pong%s", inBuf+4&#41;; continue; &#125;
    if&#40;!strcmp&#40;command, "easy"))    &#123; ponder = OFF; continue; &#125;
    if&#40;!strcmp&#40;command, "hard"))    &#123; ponder = ON;  continue; &#125;
    if&#40;!strcmp&#40;command, "go"))      &#123; engineSide = stm;  continue; &#125;
    if&#40;!strcmp&#40;command, "post"))    &#123; postThinking = ON; continue; &#125;
    if&#40;!strcmp&#40;command, "nopost"))  &#123; postThinking = OFF;continue; &#125;
    if&#40;!strcmp&#40;command, "random"))  &#123; randomize = ON;    continue; &#125;
    if&#40;!strcmp&#40;command, "hint"))    &#123; if&#40;ponderMove != INVALID&#41; printf&#40;"Hint&#58; %s\n", MoveToText&#40;ponderMove&#41;); continue; &#125;
//  if&#40;!strcmp&#40;command, ""))        &#123; sscanf&#40;inBuf, " %d", &); continue; &#125;
    // ignored commands&#58;
    if&#40;!strcmp&#40;command, "book"))    &#123; continue; &#125;
    if&#40;!strcmp&#40;command, "xboard"))  &#123; continue; &#125;
    if&#40;!strcmp&#40;command, "computer"))&#123; continue; &#125;
    if&#40;!strcmp&#40;command, "name"))    &#123; continue; &#125;
    if&#40;!strcmp&#40;command, "ics"))     &#123; continue; &#125;
    if&#40;!strcmp&#40;command, "accepted"))&#123; continue; &#125;
    if&#40;!strcmp&#40;command, "rejected"))&#123; continue; &#125;
    if&#40;!strcmp&#40;command, "variant")) &#123; continue; &#125;
    if&#40;!strcmp&#40;command, ""))  &#123;  continue; &#125;
    // now process commands that do alter the position, and thus invalidate the ponder move
    ponderMove = INVALID;
    if&#40;!strcmp&#40;command, "new"))     &#123; engineSide = BLACK; stm = Setup&#40;DEFAULT_FEN&#41;; maxDepth = MAXPLY; randomize = OFF; continue; &#125;
    if&#40;!strcmp&#40;command, "setboard"))&#123; engineSide = NONE;  stm = Setup&#40;inBuf+9&#41;; continue; &#125;
    if&#40;!strcmp&#40;command, "undo"))    &#123; stm = TakeBack&#40;1&#41;; continue; &#125;
    if&#40;!strcmp&#40;command, "remove"))  &#123; stm = TakeBack&#40;2&#41;; continue; &#125;
    if&#40;!strcmp&#40;command, "usermove"))&#123;
      int move = ParseMove&#40;inBuf+9&#41;;
      if&#40;move == INVALID&#41; printf&#40;"Illegal move\n");
      else &#123;
        stm = MakeMove&#40;stm, move&#41;;
        gameMove&#91;moveNr++&#93; = move;  // remember game
      &#125;
      continue;
    &#125;
    printf&#40;"Error&#58; unknown command\n");

Sven · Post by **Sven** » Sun May 04, 2014 11:12 pm

xmas79 wrote:Hi,
please point me to a documentation that specifies how setboard should be use (WRT color & engine mode). I found only
http://www.open-aurec.com/wbforum/WinBo ... ntf.html#8 and
http://www.gnu.org/software/xboard/engine-intf.html#8.

But apart from this, what's wrong with the output I gave if the behaviour of my engine is exactly what you (and me) described?

The output you gave shows that xboard (or WinBoard) rejects the move that your engine sends in reply to the user move received after "setboard". This shows what HGM wrote, which also differs from my previous understanding of "setboard": xboard sends "force" immediately prior to "setboard", and it does not expect the engine to leave the force mode when reacting to "setboard".

So my initial comment was not perfect, it was more of "wishful thinking". I looked up the implementation of "setboard" in my engines and found that I do not leave the force mode in "setboard" as well, otherwise it would not work correctly with xboard/WinBoard. I am not sure, though, whether this has always been normal behaviour of xboard, maybe this is a change that HGM made some time ago?

As to the specs, it is right that the intended behaviour of engines after receiving "setboard" is not specified explicitly. I still believe that the original idea (a long time ago) should have been to have a consistent behaviour of "new" and "setboard" since both reset the game to a new starting position, either the standard initial position or one given by FEN. Here I am almost sure that HGM has a different view about it, maybe driven by his interest in other chess variants which poses additional requirements. I would be glad if xboard either sends an explicit "go" after both "new" and "setboard" commands when followed by a user move, or does not send it in both cases.

Sven

hgm · Post by **hgm** » Mon May 05, 2014 12:22 am

I did not alter anything in this area. I don't think anything could be altered without breaking the vast majority of existing engines and adapters, w.r.t. the possibility to play from setup positions.

I don't know why things are so inconsistent as they are. Originally, there did not exist a setboard command in WB protocol, and the position had to be defined through the 'edit' command, plus 'white' or 'black' commands for the side to move. The latter commands are indeed like 'new', in the sense that the set the engine to play the side not on move, so that you can set it thinking by just playing a move, and only need 'go' when you want it to start.

This altering of the engine side seemed to cause confusion amongst engine authors, with as a result that the 'black' command was deprecated, and replaced by the white command plus a dummy move in force mode to set the right side to move before issuing the edit command. Apparently the setboard command was designed to mimic that behavior in a single command.

In the GUI code it is now also a horrible problem to figure out when you have to send 'go' or not.

xmas79 · Post by **xmas79** » Mon May 05, 2014 4:26 pm

If only I had it when I wrote my driver...

xmas79 · Post by **xmas79** » Mon May 05, 2014 4:41 pm

I think the vast majority of engines and adapters are still "active", so a hardening (and/or update) on the behaviour of the protocol should be considered IMHO. I'm happy with what I already have, a protocol driver that works, even if sometimes some dynamics are not fully understood...

hgm · Post by **hgm** » Mon May 05, 2014 5:39 pm

xmas79 wrote:If only I had it when I wrote my driver...

Then you should have looked better!

It has been posted on WinBoard forum years ago...

hgm · Post by **hgm** » Mon May 05, 2014 5:42 pm

xmas79 wrote:I think the vast majority of engines and adapters are still "active", so a hardening (and/or update) on the behaviour of the protocol should be considered IMHO. I'm happy with what I already have, a protocol driver that works, even if sometimes some dynamics are not fully understood...

Where did you get that idea? If there are more than 30 of the existing engines still under active development, I would be very surprised. Plus that there are people that like to run old versions, which would not even be updated for engines that are still active.

The specs could be formulated more clearly to describe the actual behavior, but backward compatibility is sort of sacred.

CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014

Re: CSVN Programmers' Tournaments May 2014