Author: Robert Hyatt
Date: 08:31:06 08/21/02
Go up one level in this thread
On August 21, 2002 at 05:03:29, Bas Hamstra wrote: >I forgot I posted a message some time ago about this topic. Here is a late >response: > >>>UCI is superior IMO (Not surprising, since they were able to learn from >>>Winboard) > >>I completely disagree. Just because they "looked at winboard" doesn't mean >>they "learned from winboard". > >>>- It's very straightforward and only processes commands in force mode >>>- Easier to implement >>>- It publishes it's own options which are then supported by the gui, this is >>>very very nice >>>- Much easier to install new engines, no dozens of ini files necessary >>>- You can change engine settings while the engine is loaded >>>- The situation with pondering in Winboard is asking for trouble. While >>>pondering (=busy searching) the engine must be able to process commands which >>> is messy. Each engine comes up with it's own messy solution for this. > >>And you think the UCI version is _better_??? The GUI tells the engine what >>it can do, and when it can do it? The engine can't decide how / when to >>ponder? What to ponder? If it should ponder at all? The GUI is _supposed_ to >>be the interface between the human and the chess engine. It is not supposed >>to get in the way of either. UCI does get in the way, and it requires a >>re-design of how the basic engine operates. Why would I want to do that when >>the shredder GUI is _not_ free? When the Shredder GUI does _not_ support >>unix? When winboard does everything that UCI does (and then some in protocol >>version 2 and more in version 3 when it is finalized). We don't need _another_ >>protocol. Particularly one developed by a commercial entity. We _already_ >>had the chessbase protocol. We need _fewer_ not _more_ to make it easier to >>standardize everyone and eventually hold tournaments where humans are not >>allowed to intervene whatsoever. This is coming at ICCA events before long. > >Ok, some comments: > >- First of all UCI is not the same as "Shredder gui" but merely a protocol >- There actually IS a free UCI gui, called Arena That may or may not work, based on some posts here recently... >- From a software design point of view I don't understand your suspicion to the >"gui taking control". I say handle some basic stuff right once, so 50 engines >don't have to invent the wheel. I don't consider "pondering" to be "basic stuff". There are dozens of ways to do it, and that should be left to the engine completely... Ditto for opening book, endgame tables, etc... > It leads to more stability IMO. Actually the >"control" is no big deal at all. If the engine has provided a pondermove, the >gui WILL instruct it to ponder that move. _Always_. What's the problem with >that? Just think about it for a minute. We already have problems with auto232 matches and strange things going on. I'm not about to let some foreign piece of software control what/when my engine does things. That is for my engine to decide, on its own. >- You say that Crafty would need a re-design for UCI, actually it's no big deal >at all, I bet you can write your UCI stuff a lot faster than you did Winboard >and no re-design of the engine itsself is necessary. My UCI code is less than >half of Winboard's, yet a lot cleaner Maybe so. However, adding winboard to crafty was trivial, because I already had a normal console mode of doing I/O and talking to the operator while pondering. I only had to add the commands needed to get stuff from winboard, such as time/otim/level/etc... Tearing that out to support UCI would be a significant change to the way I do pondering, which is 100% automatic at the moment. I won't say "UCI is no good"... I do say that I am not willing to support another unneeded protocol when we already have a good one that is working for way over a hundred engines. >- Nobody even had THOUGHT about Winboard version 2/3. Until UCI entered the >scene... Suddenly Winboard needed new versions... Sorry, but we were talking about changes _long_ before there was a UCI. You might not have been in the discussions, I don't know. I've been adding things to the winboard protocol since Crafty first used it. Things like rating, name of opponent, computer/gm/etc, better way to set up resumed game positions, and so forth... UCI didn't play a role that I am aware of... >- Tim Mann is not interested in supporting WB anymore, he says. Who is going to >do/coordinate WB 2/3? Who is going to handle UCI? Same problem... > >Tim Mann could be freed of his heavy burden, by implementing UCI in Winboard and >calling it Winboard 4. Everybody happy, you have your free Unix code, the users >have ease of use and stability, the engine programmers get great gui's with a >lot of extra options, the gui builders finally have a robust protocol. You say that like winboard is not robust. Which I don't understand. It has been robust enough for me to play nearly a million games on ICC/FICS/chess.net with no problems of any kind. Not to mention playing matches for testing on my local machine. > >>- UCI offers more information about the search > >> How? The engine can tell the operator _anything_ it wants. You can't provide >> more information than that. > >Yes, but I want it "live" on-screen in a windows environment, not in a >debug-file. Check out "telluser"... > >>>I would not be surprised if > 95% of the programmers who actually implemented >>>both WB and UCI, preferred the UCI protocol. > >>I would... > >You say so now. But my UCI code is 400 lines, clean, and rock-solid. That is >simply impossible with Winboard. That says something about the protocols. Note that simple != better... > >>>Maybe Winboard can support UCI as well? This would give the WB protocol the >>>chance to die slowly (but peaceful) because eventually everyone will chose for >>>UCI. > >>Don't hold your breath. The "concepts" used in winboard have been around >>for 30 years. They _work_. Giving the GUI total control over the engine is >>_not_ the way I want to see my engine work. I don't want another person's GUI >>to have control over _my_ engine. For obvious reasons. We've already seen >>this once with the broken winboard adapter Chessbase first released... > >You make this sound so dramatic "gui takes total control". It just takes a tiny >bit more control than Winboard. It just tells the engine when to ponder. In >practice there is no difference. The _engine_ provides the pondermove, the gui >_will_ tell it to ponder ASAP, and the _engine_ decides how long it will think. > > >Best regards, >Bas.
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.