FEN and 3rd repetition rule. No information?

[Ovyron]

Supporting the protocol is not the same as being the protocol. Hacking Stockfish so it becomes Xboard doesn't mean that now the top 1 engine is Winboard.

And can you even do that while keeping its UCI functionality like MultiPV or searchmoves? If not, XBoard Stockfish would be an inferior than UCI Stockfish, proving my point.

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.

And the most successful authors chose UCI.

[hgm]

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.

That would indeed be a work-around for when you want to search a specific move, but not when you want to avoid a certain move, and have no idea which move is second-best. You could of course figure this out by running a multi-PV search, but that would make it expensive to reach a given depth, because a lot of time would be spent on searching the #1 move that you wanted to avoid. And you would have to go to high depth, becasue the #2 move might change at that depth.

So it is better to support the 'include <MOVE>' and 'exclude <MOVE>' commands in analysis mode. (And print 'feature exclude=1' at startup to announce you can handle these commands; this is one of the annoyances in UCI, you never know whether an engine supports searchmoves or not, because support is supposed to be mandatory, but in fact most UCI engines don't have it.)

So I hope you will support these commands in Crafty.

[chrisw]

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?

Oh man. Go argue your pointless dinosaur nonsense with somebody else. The OP asked about EPD/FEN providing history data. I pointed the OP at UCI: "FEN | startpos moves <move1> <move2>" a de facto standard which is followed by all UCI compatible engines, which is mostly all modern engines inc. Stockfish and Leela. I couldn't care less what you or Crafty do. Not interesting. My opinion is that XBoard is past its sell by date. Disagree as much as you like, I could not care less to get drawn into a purposeless CCC war on how many angels can you get on the head of a pin.

[hgm]

Supporting the protocol is not the same as being the protocol. Hacking Stockfish so it becomes Xboard doesn't mean that now the top 1 engine is Winboard.

Is that what you think? Amusing...

And can you even do that while keeping its UCI functionality like MultiPV or searchmoves?

Of course. Polyglot + Stockfish is a CECP engine that thinks and moves identically the same as Stockfish, right? No problem at all to use MultiPV and move exclusion when you run that under WinBoard.

If not, XBoard Stockfish would be an inferior than UCI Stockfish, proving my point.

Yeah. And if Norway was Japan, Stockfish would be a Shogi engine. You have no point.

[Ovyron]

Of course. Polyglot + Stockfish is a CECP engine that thinks and moves identically the same as Stockfish, right?

That's like arguing that all top engines are Winboard because they can be made to support the protocol with an adapter

This has always been about the design decisions that developers have to make when programming their engines, how they're different depending on the protocol, and how those that chose UCI had more success than those that didn't. Not about how the inner workings of the engines are identical and the protocol just helps them communicate with the user and GUIs.

We've been talking past each other, I hope aspiring engine developers read these discussions and get the point. Established Winboard engines would not benefit whatsoever by switching to the UCI protocol, because the damage has already been done.

[hgm]

That's like arguing that all top engines are Winboard because they can be made to support the protocol with an adapter

No, it is constructive proof that CECP is upward-compatible with UCI. CECP must be able to do anything that UCI can, or it would not be possible to run UCI engines under WinBoard without loss of function. OTOH, it is not possible to run every CECP engine without loss of function in a UCI interface. Because UCI does not support draw offering and acceptance, resigning, learning...

This has always been about the design decisions that developers have to make when programming their engines, how they're different depending on the protocol, and how this that chose UCI had more success than those that didn't. Not about how the inner workings of the engines are identical and the protocol just helps them communicate with the user and GUIs.

Where did you get this silly idea? It is totally detached from reality. The protocol engines use to communicate have no reflection on their internal workings whatsoever. You seem to have no clue at all what you are talking about. How many UCI engines have you written? How many CECP engines?

Switching protocol has absolutely zero effect on the workings of an engine. Other than that it cannot do the things anymore that the protocol doesn't support. (Which could be a problem if you switch to UCI.)

[Ovyron]

The protocol engines use to communicate have no reflection on their internal workings whatsoever.

This is easy to disprove:

Suppose that UCI existed back when Crafty was created and bob chose to fully implement UCI for Crafty instead of going for XBoard. Are you claiming that the engine today would be exactly the same but with a different protocol? But he'd have implemented features like MultiPV and searchmoves, so the engine wouldn't have been the same.

By the butterfly effect alone the engine would have been different. Imagine one day there's a thunderstorm and bob wakes up because of the noise and has an idea that he implements in Crafty. Without the storm he wouldn't have had the idea and the internal workings would have been different. If something like this has an effect, imagine the choice of protocol!

Now you have to request him to implement 'include <MOVE>' and 'exclude <MOVE>' into Crafty, something you wouldn't have needed to do if it was a UCI engine that supported searchmoves, so the internal workings would have been different.

I'm aware that if there's a fixed set of steps that you're going to carry out to produce an engine, then what protocol you choose doesn't matter. The concept here is that the steps carried out by the best chess engine developers included "choose UCI as the engine's protocol."

Fruit has been put as an example of ultimate elegant programming and cleanliness, showing how things should be done. And UCI was chosen for it. Why?

[hgm]

Total bullshit.

That an engine is UCI does not mean it implements MultiPV or searchmoves. Most UCI engines in fact don't. And some CECP engines do. In Dutch we would say: "Je lult uit je nek!".

Random changes because of the butterfly effect do not count as an effect of the protocol. Especially if they only exist in you dreams. They would count as an effect of randomness. If I I throw a 6 at dice, I cannot blame it on Julius Caesar, even though most likely it would have had another outcome if he would have said something different when crossing the Rubicon!

It baffles me that someone can even think the choice of protocol would affect the design of the rest of the engine. As both protocols do precisely the same: load the engine with a position and / or game history, tell it when, and how long or deep it can think, and how many resources it can use, whether they should consult their own book, where to find EGT files. They just do it in a slightly different format. Do you have no clue either as to how the protocols work?

[Pio]

Total bullshit.

That an engine is UCI does not mean it implements MultiPV or searchmoves. Most UCI engines in fact don't. And some CECP engines do. In Dutch we would say: "Je lult uit je nek!".

Random changes because of the butterfly effect do not count as an effect of the protocol. Especially if they only exist in you dreams. They would count as an effect of randomness. If I I throw a 6 at dice, I cannot blame it on Julius Caesar, even though most likely it would have had another outcome if he would have said something different when crossing the Rubicon!

It baffles me that someone can even think the choice of protocol would affect the design of the rest of the engine. As both protocols do precisely the same: load the engine with a position and / or game history, tell it when, and how long or deep it can think, and how many resources it can use, whether they should consult their own book, where to find EGT files. They just do it in a slightly different format. Do you have no clue either as to how the protocols work?

With a good protocol, the protocol should of course not affect the design of the rest of the engine. In UCI I do not think you can easily handle learning, decide how to implement your pondering ... . For me the answer was Xboard but of course my engine is very bad and not a Stockfish clone. If it was I would certainly have chosen UCI and my engine would have been very good like most of the other UCI engines

[Ras]

In UCI I do not think you can easily handle learning

If you absolutely want to track a game, of course that's possible with UCI as well with a few lines of code. Most GUIs should transfer "ucinewgame" for starting a new game, and the engine surely can tell whether it has a big advantage or disadvantage, i.e. whether the game was won or lost.

decide how to implement your pondering

UCI doesn't even specifiy that. You can do what you want during pondering - it's just that if you decide to ponder on something other than your announced pondermove, you don't tell that to the GUI.