Author: Ulrich Tuerke
Date: 06:35:57 10/14/97
Go up one level in this thread
On October 14, 1997 at 09:00:13, Chris Whittington wrote: > >On October 14, 1997 at 08:38:41, Robert Hyatt wrote: > >> >> >>I responded to Tony also. I suggested the following modification: >>Since >>it is not uncommon for the operator to fudge the clock by some finite >>amount to allow time for forgetting to hit the clock or for technical >>difficulties, I suggest that at the beginning of the match, the two >>operators >>simply inform each other of the "fudge" (IE 5 minutes) and that this be >>enforced for *all* clock updates for that program. IE if we say our >>fudge >>is 5 minutes, then each correction must bring the clock back to the real >>clock - 5 minutes, no exceptions. >> >>In the case of Crafty, I have this built in. so that the operator >>doesn't >>have to enter a false time, we simply set an operator overhead which >>Crafty >>dutifully removes from the clock before calculating target times. But I >>don't >>see why we would object if our opponent hasn't done this and wants to >>"lie" >>to the program, just so he consistently lies by exactly the same amount >>for >>each clock update... > >Any fudge allowance opens up the possibility of cheating in some way you >haven't yet dreamed of. > >programs should enter only the REAL time (+/- 30 secs at most). > >Any desired fudge can be done within the program. Most do some sort of >operator fudge anyway, as you point out with Crafty. If they don't, well >they should do; just like they should save the game as PGN and show the >move on the screen and and and. > >Chris Whittington > I would prefer Bob's solution. Why not agree on a constant operator time prior to start of the game. This time has to be subtracted from the remaining time on the physical clock; and that is the time to be entered. This is a unique recipe where I do not see the chance for manipulation. To enter the remaining time +/- max 30 seconds on the other hand would leave some space to manipulate. Furthermore, there are programs not accounting for an operator time (as mine); entering the remaining time without a reserve would soon lead to the next deviation for these programs (and put a lot of stress on the operators). Regards, Uli > >> >> >> >>On October 14, 1997 at 05:41:32, Amir Ban wrote: >> >>> >>>WMCCC participants received an email from Tony about clock handlind. I >>>replied with a suggestion that I am posting here for the forum's >>>consideration >>> >>>Amir >>> >>>----------------------------------------------------------- >>> >>>Tony, >>> >>>Here is a suggestion: >>> >>>Let us reverse the rule here. Require all operators to keep their >>>program clocks up-to-date whenever they wish, in such a way that it >>>is not more than two minutes behind or ahead of the official clock. >>>If the clock is off by more than two minutes, then the opponent or >>>the TD can demand that the clock be adjusted not later than before >>>the next program input. In specific cases, the TD may demand the >>>clock to be adjusted as accurately as the program allows. >>> >>>The rationale is simple: The only way to manipulate is to have an >>>internal clock which is biased in some direction, so this should be >>>forbidden. Synchronization at all times should be encouraged. The >>>fact that there are two clocks that must be synchronised is a >>>technical nuisance of our field and I don't understand what logic >>>there is in restricting synchronisation at all times. >>> >>>Regards, >>> >>>Amir >>> >>>P.S. I will post this suggestion on CCC for additional feedback. >>> >>> >>>> From: Tony Marsland >>>> To: 15wmcc@cs.ualberta.ca >>>> Date: Mon, 13 Oct 1997 22:31:43 -0600 (MDT) >>>> Cc: DavidL@intrsrch.demon.co.uk (David Levy) >>>> Organization: University of Alberta >>> >>>> To all 15WMCC participants and interested parties: >>>> >>>> A question has been asked about rule 11, specifically about when time >>>> clock synchronization can be done. In essence rule 11 reads: >>>> >>>> An operator can only >>>> (1) type in moves and >>>> (2) synchronize the internal computer clock with an official clock. >>>> This latter activity must be observed by the Tournament Director or his >>>> designate. >>>> >>>> Always the intent this rule was to discourage (prevent) people from >>>> trying to manipulate their program through the time-control mechanism. >>>> >>>> Years ago we expected the computer to make a rational decision about >>>> when its internal clock should be synchronized, and it was required to >>>> output a message to that effect. This caused some systems difficulties, >>>> and led others to simply output this "synchronize" message every move. >>>> This seems like a bit of a subversion of the intent, but very practical. >>>> >>>> Since anybody can output a clock adjust message at every move, it seems >>>> reasonable that this be the default. But, since most people don't >>>> actually adjust their clock every move (it takes time and requires the >>>> attention of the TD), it seems that other more flexible and more >>>> convenient criteria are needed. >>>> >>>> Since the purposes of the rule is to ensure that any slow/fast running >>>> of the official external mechanical clock can be reflected in the >>>> computer's internal clock, I propose the following working arrangement: >>>> >>>> >>>> Recognizing that it is impossible for the computer to know that the >>>> "official" clock is malfunctioning unless the operator tells it, >>>> operators may adjust the programs chess clock whenever the program >>>> clock and the official clock differ by more than 30 seconds. When >>>> the two clocks differ by more than one minute, the opponent can insist >>>> that the clock be synchonized before the opponent's next move is made >>>> on the board. >>>> >>>> It follows that either operator can request a clock adjustment, and so >>>> both parties must be able to view the screen of the affected computer >>>> while the change goes on. >>>> >>>> Whether the TD must be present to observe this adjustment to the >>>> internal clock is open, and will be decided before the start >>>> of each round. This whole issue will have to be agreed to at the >>>> players' meeting before the event starts. This message is just to >>>> provide one mechanism for you to consider. >>>> >>>> Good luck with your preparations, I hope this guideline meets with >>>> general approval. >>>> >>>> Tony Marsland >>>>
This page took 0.01 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.