FEN and 3rd repetition rule. No information?

[hgm]

I might as well quote from the book of Leviticus to discredit UCI...

What the heck has this to do with CECP ('XBoard protocol')? It is just advice for how to do I/O in a chess engine. An elaborate description of how you can implement non-blocking input from pipes, which would be exactly the same whether you implement CECP, UCI or any other protocol.

The UCI protocol specs do not tutor prospective engine developers about tis at all, but leave them completely in the dark about it.

I would argue actually, its practically impossible to work with and get functional in any reasonable space of time.

Well, last months soemone sent me the source code of a stand-alone chess program with an ascii interface, and because I wanted to test it against other engines, I hacked the input loop for parsing some CECP commands. Took me about 5 minutes to make it play under XBoard. (With the aid of the 'new', 'force' and 'go' command.)

Problem is that arguing is no substitute for fact... There are people that argue the Earth is flat.

Code: Select all

  int cecp = 0, myColor = 0, stm = 1;  

    if(cecp) {
      if(!strcmp(line, "quit\n"))  return;
      else if(!strcmp(line, "protover 2\n")) prf("\nfeature sigint=0 reuse=0 done=1\n");
      else if(!strcmp(line, "force\n")) myColor = 0;
      else if(!strcmp(line, "go\n"))    myColor = stm;
      else if(!strcmp(line, "new\n"))   myColor = 2, stm = 1;
      else if(line[1] < '1' || line[1] > '8') continue; // ignore all other commands that are not moves
      else { // input move
        cecp = 2; if(line[4] != '\n') line[4] &= ~32; // convert promo suffix to upper case
      }
      if(myColor == stm) goto GO2; // original interface jumped here when it had to think
      if(cecp != 2) continue;
      cecp = 1;
    }

(I added the 'quit' and 'protover' commands later, to speed up the matches a bit.)

[chrisw]

I might as well quote from the book of Leviticus to discredit UCI...

What the heck has this to do with CECP ('XBoard protocol')? It is just advice for how to do I/O in a chess engine. An elaborate description of how you can implement non-blocking input from pipes, which would be exactly the same whether you implement CECP, UCI or any other protocol.

The UCI protocol specs do not tutor prospective engine developers about tis at all, but leave them completely in the dark about it.

I would argue actually, its practically impossible to work with and get functional in any reasonable space of time.

Well, last months soemone sent me the source code of a stand-alone chess program with an ascii interface, and because I wanted to test it against other engines, I hacked the input loop for parsing some CECP commands. Took me about 5 minutes to make it play under XBoard. (With the aid of the 'new', 'force' and 'go' command.)

Problem is that arguing is no substitute for fact... There are people that argue the Earth is flat.

Code: Select all

  int cecp = 0, myColor = 0, stm = 1;  

    if(cecp) {
      if(!strcmp(line, "quit\n"))  return;
      else if(!strcmp(line, "protover 2\n")) prf("\nfeature sigint=0 reuse=0 done=1\n");
      else if(!strcmp(line, "force\n")) myColor = 0;
      else if(!strcmp(line, "go\n"))    myColor = stm;
      else if(!strcmp(line, "new\n"))   myColor = 2, stm = 1;
      else if(line[1] < '1' || line[1] > '8') continue; // ignore all other commands that are not moves
      else { // input move
        cecp = 2; if(line[4] != '\n') line[4] &= ~32; // convert promo suffix to upper case
      }
      if(myColor == stm) goto GO2; // original interface jumped here when it had to think
      if(cecp != 2) continue;
      cecp = 1;
    }

(I added the 'quit' and 'protover' commands later, to speed up the matches a bit.)

Well, it's a fruitless exercise arguing the merits of UCI/XBoard protocols. The proof is usually in the pudding, and where chess engine authors have made a kind of "democratic" choice of which protocol to use, we can see that both of the two leading open-source engines, Stockfish and Leela Chess chose UCI protocol.

Plus, in reference to the OP, UCI implies built in FEN moves handling, so that handling is a de facto protocol and means of getting brief but enough EPD plus history information between UI (or user) and the engine, and commonly is use. Might simply to best to formally encode it into FEN/EPD documentation, but that would probably be too useful and upset too many people, so no doubt will never happen.

[hgm]

Well, the OP democratically chose to use XBoard protocol. You are the one trying to undemocratically force the wrong pudding through his throat.

FEN move handling isn't really different in UCI and in CECP. In both cases you send the FEN and the moves, preceded by a keyword. In UCI the keywords are 'position fen' and 'moves', in CECP they are 'setboard' and 'force'. Both would be a bad idea to have in the EPD standard, as they are redundant there, and only needed in a communication protocol, because that also needs other commands (such as 'go'). This is why it will never happen.

If there would be any need for indicating a full game state the obvious way to do it would just be a fen where the (now redundant) reversible-move counter is replaced by the moves. No need to include any keywords; the other FEN fields are not indicated by keywords either.

[Ovyron]

What is the top Winboard engine anyway, and how does it compare to top UCI engines? Because that's a historical example of how far you're expected to go with that protocol, and about the protocol that was chosen by the most successful developers.

If you're going to build a car, and you want the fastest in the world, you might want to check out what the fastest cars in the world are already doing, because if a different design choice didn't let most people get very far, do you really expect to be the first to reach the top with that design?

Does anybody have any hope of having a #1 XBoard engine?

[bob]

What does the protocol have to do with this? I looked at UCI extensively. I have used xboard since 1994. I still find myself preferring xboard. UCI interfaces usurp too much engine control. A GUI is a "user interface". Not an intrinsic part of the chess playing engine. I don't want the GUI choosing book moves, handling draw offers and acceptance (I use search results to accept, for example, not just some random behavior). I don't want the GUI playing endgame positions that are in a table base. Ever heard of "swindle mode" as used in Crafty (and then in a few others later on.) Bottom line, I much prefer xboard. _I_ want to control the entire game and let the GUI interface between my program and my opponent, and absolutely nothing more. It fits right in perfectly with Crafty's normal "text window console mode". I don't have to be told when to search, when to stop, when to ponder, what to ponder, etc.

So the protocol has zero to do with engine strength. This has been argued for years. To date, nothing has come of it other than arguing...

[bob]

Thanks Chrisw!

I think I´ll use xboard protocol but sounds very nice that.
My concern is that when I´ll use perft results this will be take in account.
It seems not.... at least not for the moment.

I would not use Xboard, UCI is so much better and the documentation way more concise, most 'sensible' people use it, and it's the standard for GUIs and Python Chess. Some old engines still use XBoard and getting some of them to work with Python-Chess for example is a nightmare. I haven't found one UCI chess engine that doesn't run straight out of the box from Python-Chess UI code. UCI documentation download from

https://www.shredderchess.com/chess-inf ... rface.html

Relevant bits of documentation:

position [fen <fenstring> | startpos ] moves <move1> .... <movei>
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.

Move format:
----------------
The move format is in long algebraic notation.
A nullmove from the Engine to the GUI should be sent as 0000.
Examples: e2e4, e7e5, e1g1 (white short castling), e7e8q (for promotion)

So, for example, in a game the position information string would be (assuming startpos, but could be any FEN)
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 moves e2e4
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 moves e2e4 g8f6
etc etc.

That way, your engine doesn't have to keep track of a game history, all that can be handled in the GUI, the engine acting as a "FEN + moves" solver for each position. Externally to the engine, either use a standard GUI, or write your own simple "game player" with Python-Chess, all very straightforward, tried and tested.

All engines that use UCI format will already be parsing these position strings as standard, btw. As engine programmer, you need do no more than ReadFEN(), leave the FEN pointer looking at the end of FEN string, and if you find " moves ", then parse the moves one by one, adjusting your game board, side to move, history, move number and 50 moverule counter accordingly.

This seems inefficient. What's the point of the original FEN string since the moves contain ALL of the information. Xboard approach is much better. When you want to export a FEN, you have to back up to the last non-reversible move, emit the FEN, then all the moves that follow. Why not just input the entire game, which is what PGN is supposed to do. And, BTW, PGN allows you to provide a starting position using FEN. Which makes this redundant. If your program can parse PGN, you already have this FEN problem solved. Why solve it AGAIN within the protocol interface code?

[Ovyron]

But Crafty topped as a best 50 engine, and from the other 49 that are above it, less than 4% are Winboard/Xboard.

This is a trend that shows how being UCI is a treat that most top engines have in common, and that there have been several engines that have passed Crafty over the years, written from scratch, and most of them have been UCI.

From the user perspective I despise having to deal with Winboard engines, if a UCI engine is well designed I can switch to MultiPV and have the engine show several of its favorite lines instead of just one, or use searchmoves to make the engine focus on specific moves, or exclude moves from analysis that I had already analyzed when I only care about the rest. It just works. I don't ever recall managing to use a Winboard engine to analyze positions interactively.

So yes, if people have democratically chosen an inferior protocol, and there's a chance to persuade them to go in a different way, the arguments against Xboard should be spoken.

[hgm]

Does anybody have any hope of having a #1 XBoard engine?

Fairy-Stockfish supports XBoard protocol, right? It should not be far from #1.

I can make a #1 XBoard engine for you in 15 minutes or so. It would be exactly as strong as Stockfish.

You probably also think that Windows must be a lot better than Linux? Because most commercial software is released for Windows...

From the user perspective I despise having to deal with Winboard engines, if a UCI engine is well designed I can switch to MultiPV and have the engine show several of its favorite lines instead of just one, or use searchmoves to make the engine focus on specific moves, or exclude moves from analysis that I had already analyzed when I only care about the rest. It just works. I don't ever recall managing to use a Winboard engine to analyze positions interactively.

Oh man, don't you know anything? All that can be done in CECP too. E.g. Fairy-Max supports both multiPV and move exclusion. It seems that you try to sell us your own incompetence and ignorance as a defect in a protocol.

[bob]

But Crafty topped as a best 50 engine, and from the other 49 that are above it, less than 4% are Winboard/Xboard.

This is a trend that shows how being UCI is a treat that most top engines have in common, and that there have been several engines that have passed Crafty over the years, written from scratch, and most of them have been UCI.

From the user perspective I despise having to deal with Winboard engines, if a UCI engine is well designed I can switch to MultiPV and have the engine show several of its favorite lines instead of just one, or use searchmoves to make the engine focus on specific moves, or exclude moves from analysis that I had already analyzed when I only care about the rest. It just works. I don't ever recall managing to use a Winboard engine to analyze positions interactively.

So yes, if people have democratically chosen an inferior protocol, and there's a chance to persuade them to go in a different way, the arguments against Xboard should be spoken.

??

So you REALLY think the interface chosen affects the engine strength? In fact, the winboard engine is potentially slightly stronger than the UCI engine, because the winboard engine gets to handle every single aspect of the game. When to accept or decline a draw. Which book move to play. Use book learning or not. Chose what to do when the starting position is already in an EGTB. Etc.

BTW, ever heard of "polyglot"?? I use it in all of my testing so that I can include UCI engines in the mix. Requires no effort at all. As far as multi-PV and searching a specific move, that is an engine process that is easy to do in winboard as well. I've always had the facility. And there's even a simple work-around. Just play the move you want to search and let the engine loose, You get EXACTLY the same result, if that is important.

All the reasons to dislike winboard are simply a lack of understanding. All the reasons I dislike UCI are concrete and easy to understand.

It is an author choice. And ONLY an author choice. Choose your interface and stick with it. And accept the warts along with the beauty.

[bob]

Does anybody have any hope of having a #1 XBoard engine?

Fairy-Stockfish supports XBoard protocol, right? It should not be far from #1.

I can make a #1 XBoard engine for you in 15 minutes or so.

You probably also think that Windows must be a lot better than Linux? Because most commercial software is released for Windows...

From the user perspective I despise having to deal with Winboard engines, if a UCI engine is well designed I can switch to MultiPV and have the engine show several of its favorite lines instead of just one, or use searchmoves to make the engine focus on specific moves, or exclude moves from analysis that I had already analyzed when I only care about the rest. It just works. I don't ever recall managing to use a Winboard engine to analyze positions interactively.

Oh man, don't you know anything? All that can be done in CECP too. E.g. Fairy-Max supports both multiPV and move exclusion. It seems that you try to sell us your own incompetence and ignorance as a defect in a protocol.

Please don't go to the windows lovers.

"Windows is not the answer. Windows is the question. NO is the answer."
---- Linus Torvalds..