UCI vs Winboard question

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Michael Sherwin
Posts: 3196
Joined: Fri May 26, 2006 3:00 am
Location: WY, USA
Full name: Michael Sherwin

UCI vs Winboard question

Post by Michael Sherwin »

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
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: UCI vs Winboard question

Post by Evert »

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: 4363
Joined: Fri Mar 10, 2006 5:23 am
Location: http://www.arasanchess.org

Re: UCI vs Winboard question

Post by jdart »

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: 12534
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: UCI vs Winboard question

Post by Dann Corbit »

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: 2486
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: UCI vs Winboard question

Post by Ras »

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: 2486
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: UCI vs Winboard question

Post by Ras »

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: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: UCI vs Winboard question

Post by Evert »

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: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: UCI vs Winboard question

Post by Evert »

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: 2486
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: UCI vs Winboard question

Post by Ras »

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: 2486
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: UCI vs Winboard question

Post by Ras »

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