Author: Michael Yee
Date: 21:55:24 03/10/05
Go up one level in this thread
On March 10, 2005 at 18:38:39, Dieter Buerssner wrote:
>On March 10, 2005 at 08:46:29, Michael Yee wrote:
>
>>From reading the responses in this thread, it seems like it's possible to do
>>nearly everything you want in both protocols, although some things are more easy
>>in one than the other (for the programmer or for the user).
>
>Yes. Therefore, I think, a 3rd protocol is not really needed.
>
>>But since there seem to be only a few quirks of WB2 that people would like to
>>change/enhance, maybe we should just bite the bullet and do it?!
>
>If, you really need to go ahead, and implement it, in a GUI that runs under many
>OS. Perhaps Windows, Linux, Mac, PocketPC, phones.
>
>>Some of the desired features are:
>>
>>- standardized PV
>
>Of course. But don't forget even more basic things: Standardized sign of score
>(in WB we now have the unfortunate situation, that some engines show score from
>white side, some from side to move). Don't forget about standarizing mate
>scores, too. And bounds. Uci handles this much better than WB.
>
>>- multiple PV
>
>And similar, what UCI does with searchmoves. It can be more efficient in
>principle, while able to give similar answers ("What is the second best move?").
>
>>- refutations
>
>I think, you are referring to the refutations in UCI. Nice, yes, but perhaps
>only important for debugging. I have read more wrong interpretations about what
>refutation lines mean, than correct ones. Seems more a hacker's tool, than an
>enduser's tool. I like it.
>
>>- FRC support
>
>And perhaps much more (you want to have something better than what exists
>already). 10x8 variants, for example,
>
>Don't call it WB3 - which would mean backwards compability to WB, probably.
>Enhancements to WB might be nice. But to be really nice, something not back
>compatible would be needed. Get rid of all modes (they are horrible and prone to
>errors. With modes I mean force, analyse, ...). Restrict the allowable commands
>during search to a minimum. Default to force mode. An engine will not be allowed
>to start a search automatically (unless explicetly allowed). Get rid of
>black/white. Things like result should only be allowed after exit/stop.
>
>As you can see from Steffen Jakob's excellent suggestions: the good ideas are
>not enough. Steffen's ideas were a while before UCI. Nobody implemented them.
>SMK went along and did it (very similar in concept, at least).
>
>Some thoughts about the (rather predictable) discussion. Bob: UCI does not take
>over any time management at all - please read the UCI standard. GCP: I think you
>are rather wrong, in assuming that author's are just too stupid to understand
>UCI (in the context of learning). Think of takebacks, GUI driven analysis of
>games (with variations inside), engines that try hard to learn reliably during
>one analysis (in RAM, but learning for every ever analysed game will be too
>much). I wonder, what the many things are, that made UCI worse (besides
>ucinewgame). My first implementation of ucinewgame was 1 line:
>
> {"ucinewgame", noop},
>
>more or less (noop is a function ...). Indeed, I think much of the elegance of
>UCI is gone when one tries to implement learning. Instead of "elegant stateless
>design" one has to try hard to reconstruct state.
>
>Ponder in UCI can still be an issue. There were some words added to the
>Standard, but practically, they will not help much in case of "not ponderhit".
>UCI does not have "not ponderhit" and will send stop instead. Bob: the UCI
>ponder model is exactly the Crafty ponder model (besides one thing: you need to
>have the puzzle move available in advance - but this is in average once each
>game?). You should be able to implement UCI in less than one day.
>
>
>Regards,
>Dieter
Thanks for the feedback, Dieter! In fact, you inspired me to attempt to create a
new protocol "from scratch" (well, it heavily resembles wb and uci of course). I
never even considered *not* being backwards compatible with wb until you
mentioned it. (Talk about not thinking outside the box :)
I was planning on making a gui in java at some point anyway since I wanted to
have more control over tournament options (than arena), wanted something that
worked in linux, and wanted to provide some "human-like error" filters to
existing engines to make some more fun/realistic strength-limited levels for
humans to play. So at least one gui and one engine (I plan on including at least
a really really simple reference engine) will support it eventually.
Hopefully I can post the proposal in a day or two. Here's a quick preview,
though:
design goals:
- standardized information from engine
- easy for user to change engine options (and send commands like clearhash to
engine)
- this will include getting possible input from user (like a filename)
- easy for gui to stay synchronized with engine (e.g., no need for ping/pong)
- good division of labor between gui and engine
states (*not* modes):
- ready
- think
- ponder
- analyze
sample commands from gui to engine:
scp (simple chess protocol)
new <optional fen>
showbook
move <e2e4>
undo
level 40/300 60/300 100+5
setoption <option> <value>
think owntime 100 opptime 200 drawoffer (means engine can acceptdraw here...)
ponder
analyze
result 1-0 {White mates}
stop
quit
sample commands from engine to gui:
bestmove e2e4
book move e2e4 percent 64 annotation !! freq 45 move d2d4 freq 24
thinking move e2e4 rank 2 nodes 10000 time 102 score ... (rank 2 means 2nd best)
offerdraw
acceptdraw
resign
ready
Misc Notes:
(1) An important thing for synchronization is that no matter what command engine
recieves from gui, the engine must eventually output some indication that it's
finished, e.g., "ready," "bestmove," etc. depending on the current state.
(2) Engine never starts thinking on its own (and doesn't automatically make own
move).
(3) Will support FRC fens, CRC fens, etc...
Michael
This page took 0.01 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.