FEN and 3rd repetition rule. No information?

[bob]

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.

So? They also chose windows. Is THAT the best operating system platform? Hardly.

[bob]

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?

No it wouldn't be the same engine. It would not be able to intelligently offer/accept draws, intelligently decide when to resign, intelligently modify its opening book as it plays games, intelligently use endgame tables at the root, etc. The original xboard could not do some of those. I worked with Tim Mann for quite a while to add useful features such as telling me the name of my opponent, telling me the rating of my opponent, the list goes on and on.

UCI takes over far too much of the game control. I could certainly have modified Crafty to use UCI. And xboard. I never saw a good reason to move to a crippled UI.

I am assuming you are not familiar with Crafty? You do realize it understands EPD test sets that use "bm" and "am"? It's "annotate" command (used to process a PGN file looking for mistakes by one side or the other (or both). And you can tell it to display the N best moves if you want.

As for "why UCI" one might ask why windows or why linux? Why C or Why C++? or Why PL/1? or Why ADA? or... Language is a choice. Operating system is a choice. Xboard came from Unix. Was eventually ported to windows. Even though windows sucks badly. Why? because so many use windows. Sometimes the "lemming effect" swings by.

If you like UCI, fine by me. I looked at it and made the conscious choice that I did not like the restricted functionality and usurping of things that should be up to the engine.

[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?

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.

In other words you have no argument to make, other than "just because..."

You just jump on a bandwagon blindfolded. Did you ever WRITE a UCI engine? Didn't think so. Until you do, you won't understand the issues it misses.

[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.

In other words you have no argument to make, other than "just because..."

You just jump on a bandwagon blindfolded. Did you ever WRITE a UCI engine?

Yes, as it happens.

Did you? No.

You’re right. I don’t have an argument to make. I have some helpful advice about UCI FEN moves <move1> <move2> being a de facto UCI standard to load position and game history to the OP that asked about it. That’s not an argument, that’s just some friendly help. Plus my OPINION that UCI is the way better protocol. I don’t care what you think, nor about your Crafty and what it does, or doesn’t do.

Didn't think so. Until you do, you won't understand the issues it misses.

Idiot.

[bob]

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?

I have to disagree with you here. If I had started UCI, I would not have added code to try to intelligently offer/accept draws. Offering without being obnoxious. Accepting when I don't think I can win. Resigning when I don't think I can even draw. I can try to swindle at the root in a complex endgame that starts off in the EGTBs which says "this is a draw". But if it is a "hard draw" can my opponent really draw it? The list goes on.

IE I'd like to know the name of my opponent. On ICC quite a few years ago, several GM players asked me for a "custom opening book" for them so that they could play some particular opening they were interested in studying. I was able to do this by knowing their name, relayed to me by xboard. I could then use their name to choose the opening book they wanted me to use. I want to know the rating of my opponent, since I don't really want to offer a draw to a player rated 300-400 points below me.

I guess UCI does work well for an odds game. IE give your opponent an extra knight. A simple program might resign being down a piece, but in UCI you can't resign. In my case, I can look at my opponent's rating and adjust the draw threshold automatically so that I won't resign a piece down.

There are simply too many such examples where the ENGINE needs to make the decision. For example, 50 move counter. I do NOT have to claim a draw. I can play on beyond it. Particularly in blitz/bullet type games. Don't want the GUI to stop the game when my opponent has no idea where we are regarding 50 move counter.

ALL of this should be handled within the engine. I am pretty sure that SMK didn't know the definition of "UI". U = user, I = interface. IE an interface with the user to let him play a game of chess. An "interface" should not be involved in the game, just in the relaying back and forth of game-critical information like remaining time on the real chess clock, moves played in the game, various offers (draw, resign, etc).

That is why we had things like an RS232 interface, or a parallel printer port interface. Those simply connected two things, passively.


noun
noun: interface; plural noun: interfaces
1.
a point where two systems, subjects, organizations, etc. meet and interact.
"the interface between accountancy and the law"
2.
COMPUTING
a device or program enabling a user to communicate with a computer.

[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?

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.

In other words you have no argument to make, other than "just because..."

You just jump on a bandwagon blindfolded. Did you ever WRITE a UCI engine?

Yes, as it happens.

Did you? No.

You’re right. I don’t have an argument to make. I have some helpful advice about UCI FEN moves <move1> <move2> being a de facto UCI standard to load position and game history to the OP that asked about it. That’s not an argument, that’s just some friendly help. Plus my OPINION that UCI is the way better protocol. I don’t care what you think, nor about your Crafty and what it does, or doesn’t do.

Didn't think so. Until you do, you won't understand the issues it misses.

Idiot.

There is no "defacto standard". There is a very precisely defined FEN specification. A somewhat less precise UCI specification. To add that move crap to a FEN string is not just ugly, it is wrong, since the FEN specification defines 6 fields, period. And MANY programs depend on that specification. Adding crap to the end is not a specification. It is a kludge.

Double idiot.

Here is the ORIGINAL question asked:

With my "stay at home" cause coronavirus, I´m starting a new code for Soberango. When I did the moves generator for my first version of Soberango, I did not planed it to be able to detect 3rd repetition rule so it seems I did not thought in this before.
As far as I understand, the FEN notation do not have information about previous positions.
So, the numbers that you need to found testing moves generators, do not involve 3rd repetition rule.
I´m right?

And the CORRECT answer is "no, it is not possible." He specifically mentioned the FEN notation not having this information. He was correct, it does not. Despite your rambling around the original question with an unrelated answer. FEN does NOT include that information, never has. Probably never will.

There are millions of FEN strings scattered around the internet. NONE of them have this nonsense appended since it is not a part of the standard.

[Ovyron]

The only "interface" I care about is the one on the G.U.I. The Graphical User Interface, and what I can do with it. If I want to run a tourney where games are adjudicated as draws or the games are resigned when both engines agree continuing is a waste of time, I do that in the GUI. And it works.

This idea where every engine should decide when to resign or when to offer draw (really? draw offering between engines) is convoluted, and I can only see problems caused by engines agreeing to draws too early or resigning games they could have saved.

These decisions should be made by the person running the tournament, in a way where all engines are treated equally instead of relying on whatever the engine's developer thought was best when deciding when to offer/accept draws or resign. The engines should focus on playing chess and their programmers should focus on making them play better chess (under whatever metric) so that's not a good argument for preferring the XBoard protocol.

[Fulvio]

noun
noun: interface; plural noun: interfaces
1.
a point where two systems, subjects, organizations, etc. meet and interact.
"the interface between accountancy and the law"
2.
COMPUTING
a device or program enabling a user to communicate with a computer.

I suspect that this definition has been misinterpreted, the first meaning is the most common even in computer science, because honestly it contradicts everything that was written before.
In the post 3 components were indicated: choose the opening, choose the best move, choose whether to offer/accept a draw. The sensible and common behavior is to keep them separated, connected by an interface or protocol, so it is possible to combine the components freely.
For example stockfish or lc0 are components that choose the best move. If I have a component that decides when to offer or accept a draw and an interface to connect the components, I can combine it with both, without replicating the code in stockfish and lc0.
I think this llvm chart explains the concept very well:
https://aosabook.org/en/llvm.html

[bob]

My problem with that is as follows: When you play a game, do you decide when to offer/accept a draw or when to resign, or do you ask someone else (who is not even familiar with the current game)? I personally like to make my own decisions. I know what is going on in the game, regardless of the current material situation.

I want my chess program to do exactly the same. It is playing the game. It ought to get to make EVERY decision about how the game goes.

Now, for the definition. How is the first different from the second. It says NOTHING about the "interface" meddling with the communication. A "point" is not a very big thing. UCI makes this a three-way circus. It is making game decisions, the engine is making game decisions, and UCI decides what is passed to the opponent. That's not an "interface". It is more a "meddler".

Under what definition does an interface take over for one end of the connection and ignore the input from that end, supplying its own instead? Can't think of one.

[hgm]

The only "interface" I care about is the one on the G.U.I. The Graphical User Interface, and what I can do with it. If I want to run a tourney where games are adjudicated as draws or the games are resigned when both engines agree continuing is a waste of time, I do that in the GUI. And it works.

This idea where every engine should decide when to resign or when to offer draw (really? draw offering between engines) is convoluted, and I can only see problems caused by engines agreeing to draws too early or resigning games they could have saved.

These decisions should be made by the person running the tournament, in a way where all engines are treated equally instead of relying on whatever the engine's developer thought was best when deciding when to offer/accept draws or resign. The engines should focus on playing chess and their programmers should focus on making them play better chess (under whatever metric) so that's not a good argument for preferring the XBoard protocol.

Yeah. I also dislike leaving it to the programmer to decide through some convoluted algorithm what the best move is. Better to have the GUI decide which move to play, e.g. by integrating the Stockfish code into it. Or better yet, the Fairy-Max code, to make it more compact. That way you can be sure that all engines are treated equally.

Point is that it doesn't matter what you or I like or dislike. So you want the GUI to degrade engine play by making game-playing decisions for them in a crappy way through a simplistic algorithm, and don't mind the loss of performance because all engines suffer equally... Suit yourself and configure your GUI that way. But a protocol should not just cater to your personal interests, and there are people that want to do things that are different from your narrow-minded interests. And UCI is just not capable of doing what they want.