TalkChess.com

There is the option of writing one version of my new engine with both protocols or writing two versions. The second question concerns a game history stack. In winboard the engine handles the history stack but in the UCI engine source that I have looked at it seems that there is not a history stack. How should this situation be handled? Or do I misunderstand the situation? Thanks!

Maintaining two versions is, in my experience, a maintenance nightmare. Keep it in one place.
UCI sends the game history along with every move, so that gives you the history stack.

You know at startup what protocol the UI is using, so after initializing you can maintain what are basically two state machines for the different protocols.

You can look at:

https://github.com/jdart1/arasan-chess/ ... rasanx.cpp

where I have both protocols implemented (although I don't think this module is a model of good coding and I'd probably do it differently if I were starting from scratch). There is some common code, for example, ucinewgame calls the command processor for "new", which is the Winboard equivalent. But there is not much commonality.

--Jon

UCI is stateless, so it is very problematic for things like learning.

Don't try to implement them the same. Use the full capability of whichever protocol is given you.

Evert wrote:UCI sends the game history along with every move

Not necessarily. It is also possible to transfer the position after the last irreversible move via FEN and then the move list only from that point on. Droidfish does it this way. The consequence is that from time to time, you end up with a position of the same game, but without any history.

If you need the information whether it is the same game or not, e.g. for checking whether you have a PV hit, you'll have to code around this odd, but legal behaviour.

Dann Corbit wrote:UCI is stateless, so it is very problematic for things like learning.

It isn't because if you want to, you can remember the state inside the engine. It's just not mandatory to do it.

Ras wrote:

Evert wrote:UCI sends the game history along with every move

Not necessarily. It is also possible to transfer the position after the last irreversible move via FEN and then the move list only from that point on. Droidfish does it this way. The consequence is that from time to time, you end up with a position of the same game, but without any history.

If you need the information whether it is the same game or not, e.g. for checking whether you have a PV hit, you'll have to code around this odd, but legal behaviour.

Sure, UCCI does that as well (UCI dialect for Xiangqi).
In terms of game state, you know the moves since the last reversible position, and you know when you score a ponder hit, which is what you most care about.
How do you propose to code "around" such behaviour? UCI doesn't tell you if positions/moves it feeds you belong to the same game or not. It treats every position as independent. Sure, there's ucinewgame, but that isn't mandatory so can't be relied on.

Ras wrote:

Dann Corbit wrote:UCI is stateless, so it is very problematic for things like learning.

It isn't because if you want to, you can remember the state inside the engine. It's just not mandatory to do it.

UCI doesn't tell you the outcome of a game. Sure, if the game ends in checkmate, you know. If the game is adjudicated in some way, you never find out.

Evert wrote:If the game is adjudicated in some way, you never find out.

If it is adjudicated in any even remotely reasonable way, the engine can learn. From around 0.1 or so in the initial position to +5 or so looks like a win, isn't it? Even if it isn't adjudicated at this point.

Evert wrote:How do you propose to code "around" such behaviour?

After every "bestmove" I transmit, I execute the "bestmove", then I generate a full legal move list, execute every move and record the position hash. Along with an index which of these positions continues my PV. This way, I know when the next "go" is the next move of a game even when it is transferred as FEN.

Afterwards, I take back the "bestmove" so that I have the same internal position as before the search. This increases the compatibility with some GUIs that use "searchmoves".