Author: Robert Hyatt
Date: 08:48:14 12/09/03
Go up one level in this thread
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). Additionally, an engine could logicall be written to claim that 2 repeats make a draw, leaving the actual 3-fold repeat claim to the GUI. Why should the engine have to make this decision. IE the engine probes an endgame table and gets 0.0.. Is it a draw _right now_ or N moves into the future. What about 50-move rule draws? The GUI _must_ display things in the right order, so why have the engine tell the GUI what to do, then the GUI has to do it anyway. It is a very logical "separation of concerns" to let the GUI handle the OTB game positions, while the engine just searches and gives the GUI a suggested best move. The engine doesn't need to tell the GUI "I think this is a draw on the move, or in 10 moves, or in 50 moves." That is unnecessary. 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? Why would you want the engine to handle the search case, but at the root have code to tell the GUI what to do, when sometimes the GUI has to ignore the engine since the position is not "real" anyway (a ponder search for example). 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... > >in the shredder-jonny game, just imagine how ridiculous it would have been if >shredder's interface had claimed the draw :-) > We simply call that a "bug" and move on. Many games have been lost due to program bugs. I can show you ACM games where we had pawns on the 8th rank and not promoted. I can show you a program that lost because it promoted to a queen and not a knight (the program didn't do under-promotions in the search at all and paid for it in 1992 at the ACM event in New Mexico. >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.