Author: Robert Hyatt
Date: 07:03:56 12/10/03
Go up one level in this thread
On December 10, 2003 at 09:14:56, Daniel Clausen wrote: >On December 09, 2003 at 11:48:14, Robert Hyatt wrote: > >>On December 09, 2003 at 11:00:34, martin fierz wrote: >> >>>On December 09, 2003 at 10:24:12, Omid David Tabibi wrote: >>> >>>[snip] >>> >>>>I don't understand all this engine/interfacedifferentiation. It is one chess >>>>playing unit, and does not matter whether it is built of only an engine, engine >>>>+ interface, or an interface with a built-in engine... >>>> >>>>There is no border line between an engine and an interface. For example, in >>>>WinBoard the engine is solely responsible for the draw claim, but in the UCI >>>>protocol the interface is mainly responsible for claiming the draw. And even >>>>though I believe that most UCI users will start printing draw claim info strings >>>>from the next WCCC (I have already added this), I don't think anyone did that in >>>>Graz. >>>> >>>>So, the discussion should be focused on whether the operator can overrule his >>>>program. The engine/interface discussion doesn't make much sense here. >>> >>>the engine/interface discussion makes a lot of sense! the interface should >>>definitely not be responsible for a draw claim. after all, the draw claim is >>>optional, and so the engine should decide whether it wants to claim the draw or >>>not. when you play a game of chess that ends in a repetition but your opponent >>>might still decide to avoid the repetition and lose, you don't go and claim a >>>draw, do you? >> >>This is wrong, for a simple reason. The engine does not see "the real >>game". The GUI does. IE the engine is often given a position that >>never occurs and told to "search this". (pondering). > >On one end we have the engine, on the other end we have the board in the >tournament hall. In between I see an operator and a GUI. Both should be >completely passive IMHO. (other than relaying moves) Why this should be true for >the operator but not for the GUI in not clear to me. Especially, since the GUI >is an optional step - the operator could directly use the xboard-protocol output >for example. I simply don't follow. The operator is "outside the computer". But the computer is playing the game. The hardware, the software, the operating system, the libraries, the data files, etc... We have always referred to "the computer player" and not "the engine" or "the GUI". For obvious reasons. > >I'm not sure what you mean with the pondering "the engine is given a position >that never occurs and told to search this" here. The engine says "play this move. Here is the score and the PV that goes along with that move." The GUI then says "make this move (the expected move from the PV) and search that position..." If the opponent doesn't play that move, that stuff is thrown away and the engine is given the correct position and told to "find a best move." > > In my picture, the engine >decides itself whether it should ponder over whatever position it chooses , or >not ponder at all. (although IIRC, in the UCI-protocol the GUI _does_ tell the >engine to ponder (I consider this a fundamental design flaw though)) > Look at the UCI protocol, which I personally consider to be bad, by the way. It tells the engine when to ponder, when to "sit", when to move, etc... >[snip] > > >>The GUI >>maintains the game board, and the game history, who better to know when a >>3-fold repetition, or a 50-move draw, or a draw due to insufficient material? > >The engine? The typical "engine" counts 2 repeats as a draw, since the third repeat can be forced if two could be forced. The typical engine knows "this move leads to a draw score" but that is all. It doesn't know that it is a draw on the move, or after 20 moves, of if it is a draw by repetition, 50-move-rule, stalemate or insufficient material. The GUI can see that since it handles the "real board position." > >What is the counterpart of the GUI in human-human matches? I don't see any. Of course you don't. "GUI = Graphical User Interface". But there is one similar idea. Look at the rules for a "blind player". He is allowed to have a proxy to move the pieces and tell him how much time is left on his or the opponent's clock. Sound familiar? :) Except for blind players, or handicapped players that can't move pieces by themselves, why would a human need a "user interface" to himself??? The computer, however, doesn't have hands, nor eyes, nor a pencil, etc. > If >an engine replaces one of the humans, I expect the engine to handle all the >things the human would do. (apart from physical things like going to the TD of >course, or giving sad excuses why it lost after the game :) If my engine says >"move e2e4", that's the point when my engine makes the move, not when e2e4 is >played on the GUI. IMHO :) The point of a GUI is to make the engine's output more understandable, and to provide some sort of interface that the human can use. IE suppose you start a game at 8am, and you look at the chess clock on the screen and see some huge number that just happens to represent the number of seconds since January 1, 1970 (the unix time stamp approach). Would you rather figure out how much time you have left, or have the GUI make the translation from Unix Epoch time to normal chess clock time? That's what the GUI is for, to provide an interface between the chess program and the user. It then becomes convenient for the GUI to handle certain things since it maintains the clocks. IE the GUI should call "your flag fell" not the engine. The engine doesn't care squat about _your_ clock time... > > >>I have _always_ had my code done like this. main() detects real 3-fold >>repetitions after the opponent moves, and after the program moves, and >>claims them at the right point. Why do I need to move that out into the >>engine where it makes little sense?? >> >>> >>>because claiming a draw based on 3-fold repetition has something to do whether >>>you mind your opponent deviating and playing on or not, it must necessarily be >>>something the engine decides, and not the interface. >> >>If the engine returns a move that repeats, you can rest assured that the >>engine thinks the draw is the best it can do... > >It's very well possible that (due to HT and other things) the engine all of a >sudden sees a win it could have played before, but in order to try the win it >has to go over a position where the opponent _can_ claim 3-fold repetition. >Maybe he does, maybe he doesn't. It's a _choice_. I'm pretty sure this happenend >in human-human games already. Yes. But I doubt it in computer games. Otherwise it should have varied on the second repetition when the opponent could not force a draw, rather than waiting until the third and hoping he won't claim it. > >If two humans play "Nf3 Nf6 Nf1 Nf8" a hundred times and then continue with a >Spanish game, where White wins, that's perfectly legal. (although a bit stupid I >admit ;) I don't see why this shouldn't be possible in a comp-comp game. Except no computer would do that. If they repeat the third time, they are saying "I can't find anything better, I can find several moves worse, I will take the repetition and the draw and move on. > >Please note, that I don't think that this discussion has a relevance to the case >Jonny-Shredder. An engine programmer _chooses_ a GUI (or none) he wants to use >with his engine. And if this engine happens to handle draw-claims by itself >that's ok in my opinion. > > >Here's a question, which may show very well where we disagree in principle: > >Imagine that your engine wants to make the move e2e4 and sends "move e2e4" to >some GUI. The GUI for some reason plays d2d4 though. What now?T That can't happen without a bug. Thorsten mentioned CSTal losing a game because the engine said "promote to knight" but the GUI promoted to queen. The TD said "the GUI display is what we go by." It was a reasonable decision. > >I would say an error occured on the way engine -> .... -> chessboard, and would >try to continue the game after the move e2e4. Whether the GUI makes this fault >or the operator moves the wrong pawn on the board is about equal for me. How >would you handle such a case? I take the move displayed by the "computer". I don't care what goes on internally. The author either wrote or interfaced to a GUI, and he chose to let that GUI "speak" for his program. What ever that GUI speaks, is the "truth". Otherwise he should debug and fix it. > >Sargon > >PS. The concepts that the GUI handles opening moves or draw-claims are equally >flawed in my opinion. (considering KK or KNK as draw is acceptable by me since >it doesn't possibly change the result of the game) I don't disagree. I don't like the shared GUI if the GUI has _any_ chess decision making inside. Including, but not limited to: (1) making / choosing book moves; (2) making/choosing endgame table moves; (3) telling the engine how much time to use (not how much time is left, but exactly how long to search before presenting a move). The ICGA has ignored the problem. Including the problem of a shared book or book author. We have to live within the rules as stated, however, so I don't see a problem with _everybody_ using the best Kure book, with the Fritz GUI, until the rules are fixed to address the issue correctly.
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.