Author: Daniel Clausen
Date: 07:10:57 08/22/02
Go up one level in this thread
On August 21, 2002 at 18:47:40, Dieter Buerssner wrote:
[snip]
>Other commands, that can be received in various search modes: force, easy, new
>(under some CA version also while pondering), and probably many more.
>
>I asked Tim, which commands are allowed in which modes. Well - I should be
>prepared for any command. Under UCI, I know, for which commands, I need to
>prepared, and the action is very well defined.
I'm a bit confused here. In other postings people mention that one of the bad
things of the xboard/winboard protocol is the fact that you always have to know
in which mode etc you are. To me, it more looks like the opposite way.
Let's take 'newgame' as an example. In xboard/winboard protocol you basically
can get this command at every time. In UCI, you probably only can get it under
specific conditions. (for example, the engine is not in analyse mode now, or is
pondering, or is actively calculating a move) Sounds to me like UCI is the
protocol with state in it.
Also, the fact that you can receive the 'newgame' command at _any_ time doesn't
_have_ to be that bad. Of course if I look at Crafty (Matthew Hull will consider
this as anti-Americanism no doubt ;) I get a headache when I try to find out
that Crafty does while it gets this command during an active search. But it
doesn't have to be that complicated at all.
My engine approx does this when receiving the 'newgame' command: (approx, since
I don't have the sources right now)
Engine::newGame(void)
{
engineThread->stop(); // the engine thread ignores this when it's
// not doing anything (pondering, calculating,...)
waitForEngineThread();
board.init(); // initialize board for new game
}
And that's it.
It's very simple code and is robust. (that is, it works, whether the engine
thread was doing something or not)
>My main "outer playing loop" for Winboard is 350 lines long, the same for UCI
>is 60 lines long (including over 10 lines inside #if DEBUG_UCI #endif), and
>some complication of code because of learning, which is not so easy under UCI.
I guess it's rather hard to compare number of lines here.
Basically, my engine-interface looks like this:
Engine.h
ENG_init();
ENG_quit();
ENG_setTime(...);
ENG_go();
etc...
This part is not protocol-dependant at all.
For each Winboard-command I have a line somewhere in my main. (in fact it's
hidden in a class :p)
registerCommand("quit", ENG_quit(), "Quits the program"); // WB-cmd
registerCommand("new", ENG_init(), "Initializes a new game"); // WB-cmd
registerCommand("go", ENG_go(), "Starts the search"); // WB-cmd
registerCommand("fen", ENG_fen(), "Displays the FEN of the current pos");
So when I want to be mean, the number of codes for the three xboard/winboard
commands "quit", "new" and "go" is 3 lines. I could do exactly the same in
UCI-commands though. (as far as I know)
I also don't think that the xboard/winboard protocol is the best that one could
create, but how many lines it needs to implement it heavily depends on your
chosen implementation.
I spent a bit of time in a (in my opinion) useful framework, and therefore
implementing the xboard/winboard interface was _very_ trivial. (the decision
that the engine itself runs in a separate thread was a very important decision
in this design I think) If your framework is not that flexible, don't blame the
protocol (only) but also your framework. ;)
Sargon
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.