Author: Daniel Clausen
Date: 06:14:56 12/10/03
Go up one level in this thread
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'm not sure what you mean with the pondering "the engine is given a position that never occurs and told to search this" here. 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)) [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? What is the counterpart of the GUI in human-human matches? I don't see any. 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 :) >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. 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. 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? 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? 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)
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.