Author: José Carlos
Date: 03:01:31 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 >- 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. 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? Sometimes I want to do a swallow search from the opponent's point of view to get a better ponder move, and this is done _after_ sending my move to the GUI. So in UCI, I must lie the GUI, send a random move as ponder move, ponder what I want and the way I want, then if the GUI tells me the opponent move is ponder move I will check I told the GUI before. Big mess... >- 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 you and Bob can easily. I can't. I'd need to rewrite my program from scratch. >- Nobody even had THOUGHT about Winboard version 2/3. Until UCI entered the >scene... Suddenly Winboard needed new versions... That's correct. The best (IMO) UCI has provided are ideas to improve Winboard. >- Tim Mann is not interested in supporting WB anymore, he says. Who is going to >do/coordinate WB 2/3? > >Tim Mann could be freed of his heavy burden, by implementing UCI in >Winboard and >calling it Winboard 4. Everybody happy, To be called winboard 4 it must remain compatible to winboard 3,2,1. In that case, I wouldn't complain, as it would be similar to Arena. >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. > >>- UCI offers more information about the search Good. Let's see what information wb lacks, and suggest it to be added to the protocol. >> 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. Easy to add to wb. Add a new permanent window and post there every 'telluser' the engine sends. >>>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. Let me disagree. My wb code hash, AFAIK, no flaws. I don't know how many lines of code (I have many own commands), but rock solid. >>>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. My learning schemes are simply impossible under UCI. Same for other not so standard things I do in my program. >Best regards, >Bas. Regards, José C.
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.