Author: Tony Werten
Date: 02:02:37 02/24/05
Go up one level in this thread
On February 24, 2005 at 03:53:55, Uri Blass wrote:
>On February 24, 2005 at 01:42:18, Tony Werten wrote:
>
>>On February 23, 2005 at 07:29:28, Robert Hyatt wrote:
>>
>>>On February 23, 2005 at 00:19:49, Uri Blass wrote:
>>>
>>>>On February 22, 2005 at 23:19:35, Robert Hyatt wrote:
>>>>
>>>>>On February 22, 2005 at 22:12:40, Norm Pollock wrote:
>>>>>
>>>>>>On February 22, 2005 at 19:07:22, Peter Skinner wrote:
>>>>>>
>>>>>>>On February 22, 2005 at 17:53:46, Robert Hyatt wrote:
>>>>>>>
>>>>>>>>On February 22, 2005 at 14:22:25, Matthias Gemuh wrote:
>>>>>>>>
>>>>>>>>>On February 22, 2005 at 13:52:41, Brian Kostick wrote:
>>>>>>>>>
>>>>>>>>>>On February 22, 2005 at 13:33:24, Dann Corbit wrote:
>>>>>>>>>>
>>>>>>>>>>>On February 22, 2005 at 13:29:39, M Soszynski wrote:
>>>>>>>>>>>
>>>>>>>>>>>>Where can I download the latest Crafty UCI engine?
>>>>>>>>>>>
>>>>>>>>>>>Crafty has a Winboard interface. But you can play it as a UCI engine with an
>>>>>>>>>>>adapter.
>>>>>>>>>>>
>>>>>>>>>>>Or you could bolt Pepito's nifty UCI interface onto crafty in about 5 minutes.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Dann,
>>>>>>>>>>
>>>>>>>>>> I would like to see this become common, UCI Crafty. Will all permissions of
>>>>>>>>>>course correctly. I wish so many compiler operators quit fooling around and do
>>>>>>>>>>something real like this. :)
>>>>>>>>>>
>>>>>>>>>>Regards,
>>>>>>>>>>Brian
>>>>>>>>
>>>>>>>>
>>>>>>>>I don't "hate" it, I just don't like it a whole lot. :)
>>>>>>>>
>>>>>>>>It takes too much control away from the engine and empowers the UI with more
>>>>>>>>than I personally think is reasonable. In today's software world, the right
>>>>>>>>approach is to take the minimum functionality possible away from the engine, and
>>>>>>>>for the set of all programs, this "minimum functionality" has to be a common
>>>>>>>>subset that is taken from all engines. I don't believe it reasonable for the UI
>>>>>>>>to handle the opening book, book learning, endgame tables, tell me what to
>>>>>>>>ponder, when to ponder, how long to ponder, and so forth. I already have the
>>>>>>>>code to handle all of that built in, and I see no reason to take it out as then
>>>>>>>>I lose winboard functionality, or else I have spaghetti code that does this for
>>>>>>>>that UI, this for those UIs, and so forth.
>>>>>>>>
>>>>>>>>I want the UI to be the "user interface" only. Not play chess. Not make time
>>>>>>>>allocation decisions. Not tell me how long to think and when to stop searching
>>>>>>>>or start pondering, I want my program to make _all_ playing decisions and just
>>>>>>>>use the UI to tell the opponent what it played...
>>>>>>>>
>>>>>>>>That is why I don't like UCI.
>>>>>>>
>>>>>>>
>>>>>>>GO BOB!!!
>>>>>>>
>>>>>>>I totally agree. Even the engines that I have that support both protocals, I use
>>>>>>>the Winboard one.
>>>>>>>
>>>>>>>It is easier, allows the engine to make all the decisions.
>>>>>>>
>>>>>>>UCI is like Kramnik letting me make the moves for him. While it might be fun, he
>>>>>>>wouldn't be in the top 100 after long :)
>>>>>>>Peter
>>>>>>
>>>>>>If an engine is to make all the decisions, then should the engine use an opening
>>>>>>book and end-game tablebases? It seems to me that once you take away the opening
>>>>>>and the ending from the engine, you can take other things too.
>>>>>
>>>>>
>>>>>You can take whatever you want I suppose. But winboard/xboard does not do
>>>>>anything but "GUI" functions. The engine is responsible for _everything_ as it
>>>>>should be. A GUI that handles the book is (IMHO) NFG for tournament play, as
>>>>>book selection code is one of those "same input many output" functions that can
>>>>>not be copied from one program to another.
>>>>>
>>>>>Hint: Commercial Chess Programmers - this is simply a poor idea...
>>>>
>>>>Bob,
>>>>engines can be responsible for everything also under the UCI protocol
>>>>The GUI does not control something that the engine does not want.
>>>>
>>>>This is from engine-interface.txt (if you have not it then you can download it
>>>>in http://www.shredderchess.com/download.html(look at the bottom of that page)
>>>>
>>>>* by default all the opening book handling is done by the GUI,
>>>> but there is an option for the engine to use its own book ("OwnBook" option,
>>>>see below)
>>>>
>>>>* <id> = OwnBook, type check
>>>> this means that the engine has its own book which is accessed by the engine
>>>>itself.
>>>> if this is set, the engine takes care of the opening book and the GUI will
>>>>never
>>>> execute a move out of its book for the engine. If this is set to false by the
>>>>GUI,
>>>> the engine should not access its own book.
>>>>
>>>>
>>>
>>>The problem is that the engine _can_ let the GUI handle the book. If that is
>>>considered acceptable, then we should totally stop discussing the "clone" issue
>>>and tell everyone "copy and enter what you want". Because according to the
>>>definition that I believe makes some sense, "copy things that are fixed output
>>>for fixed input" the opening book move selection code is not "fixed output for
>>>fixed input" at all...
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>Note also that the engine has full freedom what to do about pondering:
>>>>
>>>>It is from the same text:
>>>>* ponder
>>>> start searching in pondering mode.
>>>> Do not exit the search in ponder mode, even if it's mate!
>>>> This means that the last move sent in in the position string is the ponder
>>>>move.
>>>> The engine can do what it wants to do, but after a "ponderhit" command
>>>> it should execute the suggested move to ponder on. This means that the ponder
>>>>move sent by
>>>> the GUI can be interpreted as a recommendation about which move to ponder.
>>>>However, if the
>>>> engine decides to ponder on a different move, it should not display any
>>>>mainlines as they are
>>>> likely to be misinterpreted by the GUI because the GUI expects the engine to
>>>>ponder
>>>> on the suggested move.
>>>
>>>
>>>
>>>Seems like pretty clear garbage to me... "can do what it wants"... "should not
>>>display". Etc. Too many shoulda/coulda/woulda's.
>>>
>>>Particularly for tournaments or events where the programs compete with each
>>>other rather than competing against humans only.
>>
>>I think this is all just secondary problems (though valid ones).
>>
>>I'm just not going to tell my pv and pondermove to a commercial interface sold
>>by the same company that sells chessengines connected to that interface.
>>
>>There is no way of checking wether the other engine has a special command for
>>the interface like "give me the opponent pondermove, so I can do an extension on
>>it" or something the like.
>>
>>Tony
>
>I think that it will be a waste of time to do something like that only for
>better result under the UCI interface.
>
>It is not something that people cannot discover and the programmer does not need
>to be called "a cheater" only for better results under the commercial
>interface.
It's not cheating. If I play I game of chess, and I'm going to tell everyone
(including a collegue/team member of my opponent) what my next move is most
likely going to be after my opponent plays a certain move, is it cheating if my
opponent finds out somehow (overheard ?) and investigated my reply more
thoroughly ?
It's not cheating if a commercial interface has an undocumented feature.
It's not cheating if an engine uses all features an interface can provide.
If I don't want to consider that possibility, then I shouldn't have gone around
telling my move.
>
>I can also add that by the same logic you should not support winboard because it
>is easy to convert WB engine to UCI engine by WB2UCI
The fact that it's easy to do something I don't like people to do is beside the
point.
>and people who test your
>engine under Fritz may find that Fritz performs better because Fritz's interface
>has a special command to give the pv of the opponent to Fritz.
The winboard protocol doesn't tell me to give my pondermove and wait for the gui
to send me a "go" before I start to ponder.
It neither tells me to send a pv.
>
>I see no logical reason that it is better for winboard engine not to support
>UCI.
I see no logical reason why an interface needs to know the move I'm going to
ponder on. It's none of its bussiness. What does it need it for ?
Tony
>
>Uri
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.