UCI vs Winboard question
Moderators: hgm, Rebel, chrisw
-
- Posts: 3196
- Joined: Fri May 26, 2006 3:00 am
- Location: WY, USA
- Full name: Michael Sherwin
UCI vs Winboard question
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!
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
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
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: UCI vs Winboard question
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.
UCI sends the game history along with every move, so that gives you the history stack.
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: UCI vs Winboard question
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
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
-
- Posts: 12542
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: UCI vs Winboard question
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.
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.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: UCI vs Winboard question
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.Evert wrote:UCI sends the game history along with every move
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.
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: UCI vs Winboard question
It isn't because if you want to, you can remember the state inside the engine. It's just not mandatory to do it.Dann Corbit wrote:UCI is stateless, so it is very problematic for things like learning.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: UCI vs Winboard question
Sure, UCCI does that as well (UCI dialect for Xiangqi).Ras wrote: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.Evert wrote:UCI sends the game history along with every move
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.
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.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: UCI vs Winboard question
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 wrote:It isn't because if you want to, you can remember the state inside the engine. It's just not mandatory to do it.Dann Corbit wrote:UCI is stateless, so it is very problematic for things like learning.
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: UCI vs Winboard question
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:If the game is adjudicated in some way, you never find out.
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: UCI vs Winboard question
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.Evert wrote:How do you propose to code "around" such behaviour?
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".