Author: Robert Hyatt
Date: 09:48:11 12/26/03
Go up one level in this thread
On December 26, 2003 at 05:14:51, martin fierz wrote: >[snip] > >>Here is the question you have to answer: "what engine will "notice and inform >>you about a 3-fold repetition" but not intend to claim it? The answer is none. > >which doesn't mean that it *could* do so. e.g. i just played a game which ended >in a 3-fold repetition, and i noticed it in my mind before claiming the draw. >the engine might even output a line like "37. Be3+ would be a 3-fold repetition" >and then think about whether it really wants to do this. Sure, but then an engine "could" connect 110vac to the keyboard, so we also need a rule that says the operator _must_ wear rubber gloves. And nothing prevents a high-voltage overage in the CRT to produce a few x-rays, so a rule for lead clothing. The point is that we are making rules for how _programs_ play today, and how they have played for the last 35 years. And the rule is very clear for those programs. If, one day, a program wants to behave as you say, there is _nothing_ that prevents it by today's rules. He would simply tell the TD "sometimes my program informs me about a 3-fold repetition but does not want to claim it, sometimes it does want to claim it, and when it does, it uses this specific language: "xxxxxxxxxxxxx"". That is all that is needed. In the absense of that, any mention of 3-fold repetition to the operator is a statement of fact, not a "casual observation." > >>>I'm not talking about a program which has the bad position and is happy to draw >>>(not about the Jonny case anymore, but more general), but I'm talking about the >>>program who has the much *better* position, but couldn't avoid the repetition. >>>Now, how does this program *only inform* the operator that is has spotted the >>>repetition, but not claim at the same time? >> >> >>That is a circular and pointless argument. IE the program repeated for the >>second time and couldn't avoid it. If it can't avoid the 3rd repetition >>either, then what possible point is there to continue, since it also won't >>be able to avoid the 4th, or the 5th, if it couldn't avoid the 3rd. This >>seems to be based on a humans ability to overlook the obvious (the repetition) >>and give you another chance. Computers won't overlook anything, and if you >>think you have winning chances, you vary before the 3rd repetition to keep the >>game alive. That is the _only_ way to play. And it is certainly the way the >>tree search handles this... > >you can imagine different scenarios if you really want :-) Not with _any_ program that is playing today. Nor any program I have seen play over the past 35 years. So write your "exception". And tell the TD. And there will be _no_ problem. Look at the specific rules. Anything out of the ordinary has to be approved by the TD beforehand, such as something to clear the input buffer, etc. This would _not_ cause any problem, just so you didn't wait until the situation arose before telling him... >e.g. say i programmed my engine to think deeply after a 2fold repetition, to >make sure that by playing it's next move which will allow the opponent to claim >a draw it is not making a mistake (incidentally, humans who are aware that they >would be giving the opponent the opportunity to draw would do that). so my >program thinks over that move for an hour and has only a few minutes left on the >clock. then, my opponent's program decides to avoid the repetition because i >have little time left on my clock, i.e. it can avoid the repetition but end up >in an objectively bad position, but it's speculating on my lack of time (humans >do that too). using a contempt factor which adjusts itself according to the >opponent's remaining time can produce such behavior. > >i think mike is quite right. the rules are too ambiguous on this point and >should be changed. what if i use a pop-up box in my program with informational >purpose? i could have one which says "i claim a draw" and one which says "FYI: i >could claim a draw here if i wanted" - since i might want my program to show >this so that i see that it knows. The rules do _not_ disallow that. You simply have to tell the TD before-hand since it is an exception to 100% of the other programs. IE you could make up your own chess notation if you want, just so you tell the TD and your opponent so he can understand your screen output. You can _not_ write rules for every possible thing programmers _might_ do. So we have always written them for what has been happening in previous events, and they sometimes get slightly tweaked at the player's meeting right before the first round, if something comes up that is not clearly within the scope of some rule or another. But trying to anticipate what programs "might" do is hopeless. You have to wait until they _do_ do it and then make sure that the rules fit for the next time. IE the cloning rule came about due to Crafty. It wasn't there 15 years ago. > what if my pop-up texts were not quite as >explicit? if i used "3-fold repetition" instead of the FYI text? for me it would >be clear that my program is not claiming a draw, but the TD wouldn't know >that... That is _your_ responsibility_ to tell him. I again go back to my 1977 game B-qb4 which was winning, B-kb4 which lost. My program said kb4 in the "my move is xxx" output, but when it displayed the board, it had clearly played B-qb4. Had I known about that bug, and told David prior to the game, there would have been no problem. If your program pops up informational stuff, it is up to you to make sure that the TD and your opponent knows what it means, and that has always been the case without causing _any_ problems. IE how your program asks about the clock time is important. And the TD and your opponent are supposed to know so that they can see what you are doing is within the rules. > >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.