Author: Dieter Buerssner
Date: 07:23:35 08/23/02
Go up one level in this thread
On August 22, 2002 at 10:10:57, Daniel Clausen wrote:
>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.
UCI never sends a formal 'newgame'. But for other things you are right -
UVI will only send them, when you are not in any search mode. By the
stateless design of UCI, it is probably meant, that you allways get the
whole s tate of a game from the GUI by the position command including the
moves of the game and by a go command including all the time
control/search depth/search nodes/mate depth info needed for the search.
So, I think it is sta teless in a sense, that the engine does not have to
keep track of (say) the time controls and the clocks. One might argue,
that for the go ponder, state is needed (the pondermove suggested from the
last search). So, for a
normal game or normal analysis it is basically receiving position set up
commands and go commands. In between, the engine is in "force mode", and
should be ready for say engine setup commands.
BTW. I don't argue, that this stateless design is preferable to the way WB
does things. What I like however is, that the engine is allways in force
mode. I think, this makes (say I single threaded program) easier to desig
n. It seems many WB engines at the start of their developement have
several bugs - for example, starting a search, when they should not, and
starting not a search, when they should. I think, such things could be
avoided, with the "allways in force mode" philosophy.
>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
>}
BTW. Will you send a move from the current search here?
I see, that here haveing a "wait for engine" has some elegantness. It is
even not too complicated with my untreaded approach. But at my first
tries, it seemed at least a bit complicated, until I had seen, that a one
line command buffer was enough. Something inside the check for input whil
searching writes the command to a buffer, if it is not immediately
processible, and stops the search. The out control loops, looks at the
buffer, and if
not empty, reads from there and empties the buffer, before continuing
with stdin.
Still, I have a somewhat ungood feeling, when I go over the list of
commands. Because I should be ready to receive almost anything at any
time, and much is not really processible at search time, I have to ask
myself what to do with every such command.
Say result during search. Also, assume, that this still may be WB I
(before the ping/pong stuff). Now, should I interrupt the search with
giving a move back, or without giving a move back? My naive thought were:
Well WB w ould know, that this interrupt the search. Does it expect a
move? Would be no prob. If it doesn't, no prob either. Now, I find out,
that sending a move still did work. But later, some doubts come. Before
seeing the move, WB already sent new to me, because it really didn't
expect the move. Now, can this "old" move be interpreted as my first
choice for the next game? Anyway, after result, do I have to switch the
mode to force mode? (the WB- doc doesn't seem to say so explicitely, but
it may very well be, that I did not read it carefully enough).
Similars thought came to my mind for other commands (say force, adn
certainly more but I forgot). Perhaps I have not understood some
underlying philosophy. Say, would under any WB-GUI the following work?
Unless clearly to ld otherwise in the protocol, any command that is
received during search and cannot processed immediately will interrupt the
search (with or without move?), and will be processed afterwords.
>I guess it's rather hard to compare number of lines here.
I agree, and it was probably worng of me, mentioning it. Sorry.
>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)
Yes. Actually my list of commands intermix UCI and WB and "private"
commands. My lines look like this:
COMMAND_STRUCT commands[] =
{
{"rem", remark_command, AWS|AWP|AWA|BWP},
{"st", set_time, 0},
{"time", time_command, AWP|BWP},
...
{"uci", uci_command, 0},
{"debug", debug_command, AWS|AWP|AWA|BWP},
{"isready", isready_command, AWS|AWP|AWA|BWP},
{"setoption", setoption_command, 0},
{"position", position_command, 0},
The later are UCI commands. AWS, AWP, AWA mean allowed while
search/ponder/analyze (BWP is not interesting). I already planned to put
in some help strings here a long time ago, but was too lazy until now ...
Looking also at Steffen's followup, we all have basically the same
approach here.
>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. ;)
I started about at the same time with Atari ST, SX-386 (MSDOS and win 3.0
- or was it 3.1 already?) and some VMS computers. Would you use a
multithreaded approach for this? I believe right now, the engine has only
2 syste m specific functions - one for timing (but with 1 second
resulution, time() can be used) and for checking for input.
Perhaps, you understood my message a bit. I don't say WB is bad at all. It
was not too much work to implement it for me and get it working rather
reliable under WB. It was much more work for example to adapt it to the
inf amous WB-adapter of Chessbase. I just wanted to point out few things,
that IMO can be done better. I did this for UCI, too. I think one point
would be, to get rid of easy text mode operation, as is the case now with
analy ze mode. For that example I could only see advantages for a GUI
operated engine. Any programmer would be free, to implement processing
setboard and moves in analyze mode anyway.
I had the feeling, that some of the discussion in this tread was in
parts driven by "religious" arguments. I hope, I did not make myself
guilty of the same.
Regards,
Dieter
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.