Author: Dieter Buerssner
Date: 15:38:39 03/10/05
Go up one level in this thread
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
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.