FEN and 3rd repetition rule. No information?

[Fulvio]

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 am a little surprised that the examples given tend to refute the thesis rather than support it. It is known that the brain is made up of different parts that interface with each other through "white matter".

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.

Of course, but that doesn't mean it has to be a single program. Back to the LLVM example which is divided into several components. It does not lose functionality and instead gains flexibility and scalability. In the same way, instead of a chess program, you can create an entity that plays chess, composed of different programs, without losing any functionality.

[hgm]

If I understand you correctly, you propose to let chess engines consist of a separate 'move-evaluating program' and 'draw-agreeing program', (and perhaps book program and end-game program). For a simple thing as the opening book this is perhaps possible, and indeed 'book engines' have been discussed in the past as a possible enhancement of XBoard. (But even there the original concept of just having the GUI replace the book engine with the real engine when the former exited during the game because it was out of book would not work satisfactorily for transpositions back into book.) But there is no way to make sensible decisions about a draw without having move evaluations, so it seems a bad idea to separate those functions.

Point is that this is purely science fiction, and has no bearing at all on the quality of existing protocols. No existing GUI I know of allows loading of a separate 'draw engine', no protocol exists for communicating which such a hypothetical draw engine... The whole idea solves nothing, because in the end you will still need a protocol that is able to relay draw offers and acceptance. So you might as well use a protocol that already supports those, and leave it to the engine designer whether he wants to spawn separate processes for the various tasks his engine has to perform, rather than force a design on him that he will consider silly and cumbersome.

[Ovyron]

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.

I also choose my own moves when playing chess on the opening, yet we know how dumb chess programs are when it comes to opening play, so for those instances, opening books, or pre-set openings, are preferable to letting the engine make "EVERY decision."

I'm not alone, in these discussions I'm pretty much representing everyone that prefers to test with books or by giving the engines opening positions to play where the engine didn't have a choice but playing from them. And I'm not going to name who are those people, because it's mostly EVERYONE. You tell me who tests engines without books and lets them play the opening by themselves, it'd save time.

I've seen so many instances of games where both engines say the position is 0.00, for a very long stretch of moves, and they're shuffling their pieces around. Then, suddenly, one of them blunders, and the evals fall to one side, and the other wins. Under what concept would I have allowed one engine to offer draw and the other to accept it to have a wrong game result? These are instances where stronger engines shouldn't be dumb and offer or accept draws from a weaker one.

This isn't about ME, these lines of arguments represent all the testers that only adjudicate draws in certain positions where draws are a certain result, and where having engines agreeing to early draws would be undesirable. An again, tell me from a tester that allows Winboard engines to agree to draws against each other to save time.

Most people don't allow engines to agree to draws by themselves, most people don't allow the engines to play the openings unassisted, and most people, at least from the top of engines developers, don't choose Winboard as their protocol.

I can't even be wrong about these, because they're facts.

[hgm]

Easy to say that most people don't allow engines to agree a draw, when most engines they test cannot even do that. And when the engines that can are used under GUIs that do not support it.

Your argument for the 'wrong game result' is falacious. By the same reasoning you could forbid 3-fold repetitions, because when the engines would be forced to not continue to repeat, after a long time one of them might blunder. And 50-move draws should be forbidden too, just force them to play on no matter how many moves it takes. These 3-fold repetitions and 50-move draws only lead to 'wrong game results'.

[bob]

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.

Sort of like giving the tournament director the ability to declare games won, lost or drawn?

Why should engines NOT offer a draw? In my case, my program will not offer or accept early draws, other than by repetition (if justified). It also have several other constraints. IE a user-settable "draw count" says the score must be right around the draw score for "draw count" consecutive moves. In very fast games, draws offers are ignored and none are offered. If the program sees itself getting mated with a very deep mate score, it won't resign immediately. It will continue to play until it becomes obvious the opponent has seen the mate as well.

There are lots of things one can do here. NONE of 'em belong in the hands of the GUI. NONE. For a tournament manager (A GUI that is not serving as an interface with a human) that could trigger somewhat altered behavior. I have my own tournament manager I use to test Crafty against a gauntlet of opponents. the xboard protocol has a "result" command that can end the game. My manager ignores these except from Crafty. Because I know it handles this correctly and I have encountered a number of programs that blow this and screw up the game results. But no user would ever use this program to actually play a game vs crafty, it is different from the concept of "GUI".

So note that YOU are not talking about a GUI, you are talking about a tournament manager, which is a different topic altogether.

[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 am a little surprised that the examples given tend to refute the thesis rather than support it. It is known that the brain is made up of different parts that interface with each other through "white matter".

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.

Of course, but that doesn't mean it has to be a single program. Back to the LLVM example which is divided into several components. It does not lose functionality and instead gains flexibility and scalability. In the same way, instead of a chess program, you can create an entity that plays chess, composed of different programs, without losing any functionality.

I won't disagree with the idea of several pieces of code contributing to the game for my side. What I DO disagree with is that one or more of those game-affecting pieces of code should be written by someone other thant me.

Chess and compilers are completely unrelated. The game of chess is a two-player zero-sum game. Adding a third player into the mix to choose book moves, or how to play EGTB positions, draw decisions, etc. is just wrong. Two players. Doesn't matter whether I include all of my decision-making logic in one program or several. Just so I write 'em all myself.

That is getting overlooked here. You are effectively inserting someone else's code into the middle of mine when you let that "other code" make game-influencing decisions and take game-influencing actions as a result.

[JohnWoe]

About the UCI vs XBoard protocol. I think bith get the job done.

Obviously there's problems. UCI is supposed to be stateless.
As a lazy prorammer I expected UCI ponder to be simply: "go ponder -> stop". Job done.
But right now it's really cumbersome with lots of logic: "bestmove e2e4 ponder e7e6 / ponderhit / ...". So I'm not supporting uci ponder. Not that it makes difference in my engine