Author: Robert Hyatt
Date: 16:29:28 12/10/03
Go up one level in this thread
On December 09, 2003 at 17:54:52, martin fierz wrote: >On December 09, 2003 at 16:03:18, Omid David Tabibi wrote: > >>On December 09, 2003 at 15:11:14, martin fierz wrote: >> >>>On December 09, 2003 at 14:54:42, Omid David Tabibi wrote: >>> >>>>On December 09, 2003 at 14:43:18, Gian-Carlo Pascutto wrote: >>>> >>>>>On December 09, 2003 at 14:41:39, Matthew Hull wrote: >>>>> >>>>> >>>>>>If the GUI can play half the game (opening moves), then it is part of the >>>>>>chess-playing software. The engine/GUI are one chess-playing entitiy. >>>>>>Therefore, you point is egregiously in error. >>>>> >>>>>Who says the GUI must play the opening moves?! >>>> >>>>Nobody says that the GUI "must" do one thing or another. It is the seperation of >>>>tasks. For example, you can let the interface play the opening moves, and do the >>>>draw claim; let it only do the draw claim; do nothing; etc. There is no strict >>>>border between the engine and the interface (read the WinBoard and UCI >>>>protocols). I don't see how you can make the seperation... >>> >>>i suggest: the engine has to deal with any position that is not in a database >>>(opening/endgame). the GUI can deal with all "mindless" tasks, meaning all >>>database lookups. >>> >>>point being, that whether you let the GUI execute the moves in your book or >>>whether you let the engine execute the moves in your book doesn't matter, both >>>will choose the same moves if you give them the same book. same once you're in >>>the tablebase. in this sense, it doesn't matter whether you let the GUI or >>>engine do this. >>> >>>but choosing whether to claim a draw or not is a conscious decision by the >>>chess-playing entity (be it human or computer). you are not forced to claim it, >>>and therefore you must make a decision whether you want to claim it or not. >>>since this is not a mindless database lookup, i believe the engine should decide >>>whether it claims the draw or not. >>> >> >>If the programmer is so concerned about when *not* to claim a draw, he can write >>his own interface, or run under winboard which leaves the decision to the >>engine. But the mere fact that the programmer has decided to run his engine >>using UCI indicates that he wants every draw to be claimed. > >...or perhaps that he decided to use UCI because it has some other advantages >compared to winboard?? my engine runs under both UCI and winboard. i didn't make >it UCI compatible because UCI interfaces claim a draw! that is just a "side >effect". i would run my engine under arena because i like that GUI. i certainly >wouldn't have thought of using UCI because i want every draw claimed! > >>It is absolutely >>irrelevant whether the claiming is done by the engine or by the interface. >not at all. gerd has just made another very valid point: let's say i sacced a >piece and started giving a perpetual. my opponent plays his 3rd repetition and >does *not* claim the draw for whatever reasons. now, my engine should realize >that it can either claim the draw, or use the entire rest of it's time looking >for a win, instead of the normal few minutes. this may happen sometimes, that >you have a perpetual but you can also bring in some reserves, slowly, and that >the engine needs a long time to see that. >if you were using the interface to claim the draw, it would simply claim the >draw after the opponent has repeated the position 3 times. which *could* be a >mistake... There is nothing wrong with that. However, what is wrong is trying to suggest that because you have an unusual case you want to handle, that all GUIs should therefore not claim draws when appropriate. You have a special case. It simply requires your own special GUI and there you can do whatever you want. For me, my UI/GUI is responsible for claiming OTB draws, my engine is responsible for searching and telling the UI/GUI which move to play. I don't ever want to force you to use my UI/GUI. I also don't want you to dictate what my UI/GUI can and can't do. That is the main point here. That is a software design issue that is best left up to the person designing the software. IE my engine actually does the book stuff. In thinking about it, it could better be done in the UI/GUI code maybe. But since there are two places to look for book moves (for a pondering search and a normal search) I have just one place to call the book code. And it isn't from the UI/GUI. But that was my choice in the design. And when I moved to xboard for the GUI, it also doesn't do books. So my UI talks to the xboard GUI and tells it what to do... And my engine doesn't give a rat's behind, except that the UI/GUI plays the move it says play and accepts the consequences of doing that. IE I don't like the chessbase GUI handling root TB positions. Because I have some special case code to handle both draws, and positions with missing tables. So my UI/GUI doesn't handle those, my engine does. Apparently the chessbase programmers didn't think about missing tables and difficult draws, and chose to keep it simple. I chose otherwise and my UI/GUI operates as I want, _not_ as they want... > >>And the question I have asked here several times without anyone answering: How >>did you expect the Jonny engine to claim the draw, if not via the interface? >with an info string perhaps? the engine can still send messages to the operator, >even if it's not a pop-up box. It is a horrible design to have an engine that talks to a UI, but it can bypass the UI for certain conditions. The term UI precludes that in a logical design... > >cheers > martin
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.