Author: Robert Hyatt
Date: 20:45:52 12/09/03
Go up one level in this thread
On December 09, 2003 at 20:32:57, Bob Durrett wrote: >On December 09, 2003 at 11:55:11, Robert Hyatt wrote: > >>On December 09, 2003 at 11:13:56, martin fierz wrote: >> >>>On December 09, 2003 at 10:50:23, Sune Fischer wrote: >>> >>>[snip] >>> >>>>If the bare engine had been playing he would have had to add a few things the >>>>GUI normally takes care of. >>>>For UCI engines it is expected that the GUI handles certain (trivial) things. >>> >>>claiming a draw on 3-fold repetition is *not* a trivial thing. there are >>>different possible cases: >>> >>>1) if your opponent avoids it, he loses >>>2) if your opponent avoids it, he wins >>> >>>in case 2) you should of course claim the draw, because perhaps he will notice >>>he could avoid it. in case 1) however, you can safely repeat the moves, and not >>>claim the draw. it is *not* mandatory to claim a draw on the 3rd repetition. so >>>you should basically not claim it if you might win if your opponent avoids the >>>draw. >> >>This is a zero-sum game. If I avoid a draw, I am doing so because I think I >>can win. Therefore my opponent will be trying to draw to avoid the same loss. >> >>It doesn't matter what my _real_ opponent will choose to do, what matters is >>what I _think_ he will do inside my search, because my search is given the >>task of playing a move that repeats for the 2nd or 3rd time (with a score of >>0.00) or playing a move that avoids the repetition and doesn't give my opponent >>the opportunity to repeat. When you repeat for the third time, you definitely >>hand a draw to your opponent. He can take it or decline, beyond your control. >>But you have put the future of the game in his hands.. I don't repeat hoping >>my opponent won't. >> >>> >>>how do you expect a GUI to make the right decision? imagine the following >>>absurdity: jonny is running without GUI and happily repeats moves against >>>shredder, and does not claim the draw because the engine doesn't know about it. >>>shredder has a bug and allows a 3-fold repetition but will deviate before the >>>fourth repetition. now shredders GUI stops shredder from moving, and says "i >>>claim a draw with my move XY because of 3fold repetition" - this would have been >>>hilarious for everybody except SMK :-) >> >>The GUI doesn't make _any_ decision. It plays the move the engine supplies. > >In the following I am not talking just about one specific chess-playing machine, >but a "generic" or "typical" chess machine. Specific machines may not be >typical. [We may not know all the details regarding the internal workings of >ALL chess-playing machines.] > >Rhetorical Question: "What software typically generates the original position >evaluation score?" Perhaps the "main engine" returns not only a move [in some >specific way] but also additional information [such as, but not limited to, the >position evaluation score.] Most programs use two threads. One to interact with the operator. We usually call this the UI (User Interface). Or if it is graphically-based, like xboard, we call that a GUI (Graphical User Interface). In some programs, the GUI is a part of the engine. IE in Crafty, I have a UI that is definitely a part of the "chess program". But when I run with xboard, xboard and crafty are separate "programs" that work together to play chess. Crafty needs something to display the board. The GUI needs something to make moves against the human. The program simply tells the GUI/UI "I want to play this move, and here is the score if the opponent wants to see it." That's it. The GUI/UI interacts with the real chess board (the one where the game is being played.) This is the _natural_ place to pick up repetitions, 50-move draws, etc. Because if the engine chose to make a move that led to a drawn position, it _knew_ what it was doing. The GUI has to make the move and / or relay the draw claim as appropriate... > The engine "returns" the information, presumably, >to the GUI. Subsequently or concurrently, the GUI "processes" some or all of >the information provided to it [perhaps incrementally as it comes in], plus any >information generated in the GUI software or elsewhere [such as tablebase >software, clocks, stored user preferences, and user real-time inputs]. The GUI >then "makes a decision." [Like it or not, the GUI is doing this, not an >engine.] Then the GUI "decides" what to display to the human operator. The GUI >could be programmed to stop and start the engine(s) under certain circumstances. > [A trivial example would be when the GUI receives a "stop" or "start" command >from the human user.] > >In my opinion, ChessBase displays a 0.00 evaluation score sometimes when it >should not and visa versa. [I am prepared to discuss that more if someone from >Chessbase wants to.] \ Don't get hung up on 0.00 for draw. In Crafty, draw can go from -1.00 to +1.00 depending on the rating of the opponent, when playing an automatic game (say on a chess server). If you assume that +.5 means "I don't want a draw" you would be dead wrong. It might mean "I want a draw _real_ bad"... > >Note that we have said nothing about the "format" or "protocols" associated with >the information transfers occuring inside the "chess-playing machine." >Clocking, interrupts, registers, and the like are just too hard to talk about. > That is why we have always said "computer chess player" in the past. That includes the hardware and software, in toto... This "smart GUI" stuff has been around for a while (a GUI that does more than relay from engine to human, ie chessbase GUI can select opening moves, play endgame tablebase moves, etc.). We have discussed this many times. The ICGA simply refuses to address the problem for fear of pissing off some commercial interests. Therein lies most of the problems. "all programs are _not_ created "equal" in this context." >Bob D. > > >>If that leads to a 3-fold repetition, the GUI claims it correctly... I don't >>understand this "how do you expect the GUI to make the right decision?" >>stuff when the GUI only does what the engine tells it to do. If the engine >>says "play this move" then the GUI plays that move, and if that produces a >>3-fold (or 50-move-rule) draw, then the GUI claims it, _knowing_ that the >>engine knew that was happening... >> >> >> >> >> >> >>> >>>since 3fold repetition is something you claim or don't claim based on the >>>current position, it is clearly something the GUI shouldn't be doing! >> >>It doesn't. The engine makes the choice to repeat. But once it does, >>it _knows_ it wants the draw, else the engine would have avoided it. You >>are saying the engine plays a move leading to a forced draw, but it isn't >>sure it wants to claim it. That is simply wrong. The search doesn't work >>that way... >> >> >> >>> >>>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.