XBoard for Mac: draw non-recognition, feature or bug?

[matthewlai]

If my program makes a move which results in a fifty move draw, should it also send the 1/2-1/2 string immediately afterward? If my program gets a position which is already a fifty move draw, should it: A) move, B) send 1/2-1/2, C) do A then B, or D) do B then A? At present, it just sends a move although this is not a good solution.

Same question as above for threefold, insufficient, and stalemate.

Your program cannot make a move which results in a fifty move draw. A fifty move draw can be claimed by either player after fifty moves. The 50th move itself does not result in a draw.

If your program gets a position that already has fifty moves (but not drawn yet because no one claimed it), you can claim it by sending 1/2-1/2, without sending a move.

If your program gets a position that already has 49 moves, and wants to claim draw immediately after the program's move, it should make the move, then claim draw by sending 1/2-1/2.

However, there's a possible race condition if the opponent makes a very fast move between your move and the claim, and by the time xboard processes your claim, the claim is no longer valid (because the opponent made a capture or pawn move). That's why it's recommended to use "offer draw" instead, before sending the move. XBoard will then process the offer as a claim if the position after the move is claimable, and won't give the opponent a chance to inject a move in-between.

Insufficient and stalemates don't need to be claimed. They are always adjudicated since they are hard draws according to FIDE rules. You can always treat them just like checkmates and stop playing afterwards (assuming you use the FIDE rules for insufficient definition).

Basically, if you have to claim in over the board chess, you have to claim in xboard. If you don't have to claim in over the board chess, you don't have to claim in xboard. It's that simple.

[hgm]

The protocol supports 2 engine->GUI commands to claim a draw:

1/2-1/2 {REASON}

where REASON can be any text (and the whole {REASON} part is optional). This command informs the GUI that the engine considers the game terminated, and won't play on no matter what. It should e used for stalemates and 50-move/rep-draw claims during your own move, which cannot be refused.

Does XBoard check to see if a program's draw claim is valid?

I haven't seen any stalemates yet; I thought that XBoard handled these just like it handles checkmates (which appears to be correct).

If my program makes a move which results in a fifty move draw, should it also send the 1/2-1/2 string immediately afterward? If my program gets a position which is already a fifty move draw, should it: A) move, B) send 1/2-1/2, C) do A then B, or D) do B then A? At present, it just sends a move although this is not a good solution.

Same question as above for threefold, insufficient, and stalemate.

Perhaps I should support XBoard protocol version two in the re-write, just as it was supported before the re-write. I admit to not have done much interface coding in a few years, so my knowledge on the topic may be out of date.

----

I had thought about not providing XBoard interface support and use UCI instead. But with a somewhat native Mac OS/X version of XBoard working, I reconsidered. But I also intend to have UCI support, and until the past few days, there was more UCI support in the re-write than there was for XBoard.

In the long term, I think the best approach is to develop new protocols for command/status communication and also for the actual transfer mechanism -- and they should be separate.

For command/status communication, there is a need for atomic operators which bundle together disperse data items to avoid synchronization difficulties. Instead of a text line format, a more general representation like XML could be used and free open source tools would be provided to help authors.

The separate specification for data transfer would abandon the old fashioned I/O pipes, signals, and their associated idiosyncrasies -- replacing them with the more modern and portable TCP/IP.

A chess program using the new protocals might not even need a GUI mediator, or any mediator at all. The program could be written just like any other program driven by an event loop with the connected opponent (or GUI) being just another event source.

While a GUI could start the chess program, the program could also be invoked separately and perhaps could run as just another server/service.

If it is your turn, and according to you a draw is claimable without doing any move, (or the position is a stalemate, or there is no mating material) you should send

1/2-1/2

If it is checkmate you should similarly send 1-0 or 0-1, just for the enefit of interfaces that do not detect mate themselves.

If you want to claim a draw after your move, you will have to send

offer draw
move XXXX

If the move according to XBoard indeed leads to a repeated position or a ups the reversible-ply counter to 100 without checkmating, XBoard will treat it as a draw claim, and grants the draw in reply to your move. Otherwise it will treat it as a draw offer, or, when the opponnet already had such an offer pending, as acceptance of a draw offer.

[hgm]

Does XBoard check to see if a program's draw claim is valid?

Oh, and to answer this question: that depends on the setting of "Verify claims" in the Adjudications menu dialog.

[sje]

Alright, I think I've got it and the testing so far seems to verify this. I have turned off all XBoard adjudication and this simplifies the situation.

This is what I'm now using in Symbolic:

Code: Select all

void XbdCoPro::ReportResult(const PosTerm posterm) const
{
  // Report a result to XBoard for a terminated game

  if (IsPosTermCertain(posterm))
  {
    std::ostringstream oss;

    oss << GsrNameVec&#91;MyPosition&#40;).CalcGsr&#40;posterm&#41;&#93;;
    oss << " &#123;" << PosTermColorNameVec&#91;posterm&#93;&#91;MyPosition&#40;).GetGood&#40;)&#93; << "&#125;";
    WriteLn&#40;oss.str&#40;));
  &#125;;
&#125;

void XbdCoPro&#58;&#58;Respond&#40;void&#41;
&#123;
  // Respond to a possible need to make a move

  PosTerm posterm = MyPosition&#40;).CalcPosTerm&#40;);

  if &#40;IsPosTermCertain&#40;posterm&#41;)
    ReportResult&#40;posterm&#41;;
  else
  &#123;
    // Calculate and play a move

    ProgMove&#40;CalcMove&#40;));
    posterm = MyPosition&#40;).CalcPosTerm&#40;);
    if &#40;IsPosTermCertain&#40;posterm&#41;)
      ReportResult&#40;posterm&#41;;
  &#125;;
&#125;

[sje]

Well, that almost worked. But somehow tscp tried to send a move after a threefold repetition and was forfeited by XBoard for an illegal move. I have since modified Symbolic to use the offer draw directive, and that seems to be working okay so far.

Code: Select all

void XbdCoPro::Respond(void)
{
  PosTerm posterm = MyPosition().CalcPosTerm();

  if (IsPosTermCertain(posterm))
    ReportResult(posterm);
  else
  {
    const Move move = CalcMove();

    posterm = MyPosition().CalcPosTermAfterMove(move);
    if (IsPosTermDrawFIR(posterm))
      WriteLn("offer draw");
    ProgMove(move);
    if (IsPosTermMate(posterm))
      ReportResult(posterm);
  };
}

[bob]

Does XBoard check to see if a program's draw claim is valid?

Oh, and to answer this question: that depends on the setting of "Verify claims" in the Adjudications menu dialog.

Yes, solves a LOT of problems. I know more than one program that has gotten "result" WRONG when playing black. One of the first things I had to fix in my cluster testing referee, to the point it does not honor the result string, and draconianly forces 50 move and repetition draws without either program having to make a claim.

[sje]

Oh, and to answer this question: that depends on the setting of "Verify claims" in the Adjudications menu dialog.

Yes, solves a LOT of problems. I know more than one program that has gotten "result" WRONG when playing black. One of the first things I had to fix in my cluster testing referee, to the point it does not honor the result string, and draconianly forces 50 move and repetition draws without either program having to make a claim.

The problem here is that while XBoard tries to observe FIDE rules, there just isn't an easy way to test if a given position is a true draw by insufficient material. In a recent game with XBoard adjudication activated, Symbolic was forfeited after claiming a draw in KBKN -- and the draw was proven by the tablebases.

The USCF draw rules and those of other federations are similarly vague and are variant with respect to the nature of an event and the time control in use.

[sje]

After a 100 game 1min/+1sec match Symbolic vs tscp run by XBoard, there were no glitches and all the scores were assigned properly. However, there were no stalemates, so not all paths were tested.

Match score was 73-17-13 giving Symbolic an Elo 220 points higher than tscp. Note that at this stage of the re-write, Symbolic is single threaded, does not ponder, does not have transposition score storage, and has only a very simple evaluation function. Its book works well, posting works well, and it probes the tablebases (residing on an SSD) at every node where there are five or fewer men.

Chess Elo Rating Difference Calculator: http://www.3dkingdoms.com/chess/elo.htm

I've now started a 100 game match Symbolic vs FairyMax, mostly to confirm XBoard interoperation.

[kbhearn]

Oh, and to answer this question: that depends on the setting of "Verify claims" in the Adjudications menu dialog.

Yes, solves a LOT of problems. I know more than one program that has gotten "result" WRONG when playing black. :) One of the first things I had to fix in my cluster testing referee, to the point it does not honor the result string, and draconianly forces 50 move and repetition draws without either program having to make a claim.

The problem here is that while XBoard tries to observe FIDE rules, there just isn't an easy way to test if a given position is a true draw by insufficient material. In a recent game with XBoard adjudication activated, Symbolic was forfeited after claiming a draw in KBKN -- and the draw was proven by the tablebases.

The USCF draw rules and those of other federations are similarly vague and are variant with respect to the nature of an event and the time control in use.

In fact it is incredibly straightforward to test draw by insufficient material by FIDE's rules. If there's a helpmate, it's not insufficient material as there exists a sequence of legal moves to a checkmate position. and in KBvKN there is always a helpmate. The way around playing out said KBvKN position is to have the gui with tablebases act as adjudicator in any position that exists within the tablebase. Otherwise let them shuffle the 50 moves and you can claim the 50 move rule draw then.

There is a seperate rule that would apply that allows under sudden death time control an appeal to an arbiter that your opponent is just trying to flag you and not trying to win after which they have to demonstrate progress. But iirc this rule is even optional at the discretion of the TD and must be announced that it's in effect at the start of the tournament.

[hgm]

XBoard does not support tablebase adjudication, but it has an option to limit search depth for a specific engine if the current position is a tablebase draw. This can be used with engines known to use tablebases, to prevent they will continue to think very long in an attempt to swindle their opponent. (For won or lost positions such engines can play instantly, as there is a well-defined best move in such positions.)

The idea is that it is pointless to search very deep when the tablebase tells you there is nothing to find. So a shallow search based on the heuristic evaluation would be good enough to keep a non-tablebase-using opponnent under pressure.