UCI vs Winboard question

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Michael Sherwin
Posts: 2822
Joined: Fri May 26, 2006 1:00 am
Location: OH, USA

UCI vs Winboard question

Post by Michael Sherwin » Mon Mar 05, 2018 5:40 am

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! :D
Regards,
Mike

User avatar
Evert
Posts: 2902
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: UCI vs Winboard question

Post by Evert » Mon Mar 05, 2018 6:32 am

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.

jdart
Posts: 3585
Joined: Fri Mar 10, 2006 4:23 am
Location: http://www.arasanchess.org

Re: UCI vs Winboard question

Post by jdart » Tue Mar 06, 2018 2:47 am

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

Dann Corbit
Posts: 8958
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: UCI vs Winboard question

Post by Dann Corbit » Tue Mar 06, 2018 8:08 am

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.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Ras
Posts: 1015
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI vs Winboard question

Post by Ras » Wed Mar 07, 2018 4:55 pm

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.

Ras
Posts: 1015
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI vs Winboard question

Post by Ras » Wed Mar 07, 2018 4:56 pm

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.

User avatar
Evert
Posts: 2902
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: UCI vs Winboard question

Post by Evert » Wed Mar 07, 2018 6:16 pm

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.

User avatar
Evert
Posts: 2902
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: UCI vs Winboard question

Post by Evert » Wed Mar 07, 2018 6:17 pm

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.

Ras
Posts: 1015
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI vs Winboard question

Post by Ras » Wed Mar 07, 2018 6:34 pm

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.

Ras
Posts: 1015
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI vs Winboard question

Post by Ras » Wed Mar 07, 2018 6:41 pm

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

Post Reply