ICCA rules, was TOP 10 REASONS...
Thomas Kerrigan
silly game. :(
Anyway, you're right, the rules should be much more explicit. With regard
to my own problem, I obviously had a "bug" but I wasn't allowed to set up
the position because my program didn't technically "crash". I think this
is silly. I also think the promotion problem was silly, as your program
obviously didn't want =N.
I'm not sure how a bug rule should work. Try this: the operator gets 2
chances to set up the position and restart his program. I think the 15
minute rule is supid because it gives you a chance to debug, but if you
just set up the position you can play the move your program "really"
wanted, and this upholds the spirit of the tournament.
Cheers,
Tom
------------------------------------------------------------------------------
An exotic journey in downtown Newark is in your future.
Robert Hyatt
Thomas Kerrigan <kerr...@alpha.pr1.k12.co.us> wrote:
-->Glad to hear you folks found the bug. Sorry to hear it was after that
-->silly game. :(
-->
-->Anyway, you're right, the rules should be much more explicit. With regard
-->to my own problem, I obviously had a "bug" but I wasn't allowed to set up
-->the position because my program didn't technically "crash". I think this
-->is silly. I also think the promotion problem was silly, as your program
-->obviously didn't want =N.
Rules are rules. A tournament can be run on "do what I meant, not what I said"
as you are suggesting. You announce a move and you have to play it. Not much
room for interpretation there.
-->
-->I'm not sure how a bug rule should work. Try this: the operator gets 2
-->chances to set up the position and restart his program. I think the 15
-->minute rule is supid because it gives you a chance to debug, but if you
-->just set up the position you can play the move your program "really"
-->wanted, and this upholds the spirit of the tournament.
-->
-->Cheers,
-->Tom
-->
-->------------------------------------------------------------------------------
There is one problem with the above. If a program "crashes" or a machine "crashes"
then perhaps starting over and resetting is legitimate. However, if your program
"hangs" that is simply too bad. Remember that the human cannot assist the program
in any way, so how can you expect David or anybody to determine whether or not
the program has some type of timing bug that made it use an excessive amount of
time? I can see many circumstances where this would be a problem. In effect,
*anyone* could say "hey, I've got a bug and have locked up" rather than letting their
program lose on time.
That's why one of the "golden rules of computer chess competitions" is test, test
and test. It is asking too much of the TD to expect him to be able to differentiate
between a program that's hung due to an O/S interface bug like screwing up the time
when it wraps around at midnight or whatever, and a program that is simply trying
to search too deeply and got into a search it couldn't/wouldn't complete. In short,
that's *your* responsibility to prevent, rather than the TD's responsibility to
figure it out. I've lost a game or two on time in early ACM events, and I've always
checked timing code out carefully since then, including playing *long* games on the
machine I'm going to use, to detect this sort of problem before it embarrasses me in
a tournament.
In this case, you simply have to take your lumps and don't repeat the problem the
next time you compete. The rules *actually* prevent your fixing a bug during a game
as they specifically say that the program parameters can not be modified during the
game. Clearly, modifying the program is a direct violation of this, particularly if
it affects how the program uses time.
Remember the magic word: "test".
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
Hal Bogner
>Glad to hear you folks found the bug. Sorry to hear it was after that
>
>Anyway, you're right, the rules should be much more explicit. With regard
If his program actually played the promotion to a knight, there is no way the
rules could offer him an out. We're not talking US Presidential politics here
- we're talking chess!
What was your program's problem, Tom? Just sitting there and not moving?
>I'm not sure how a bug rule should work. Try this: the operator gets 2
>chances to set up the position and restart his program. I think the 15
>minute rule is supid because it gives you a chance to debug, but if you
>just set up the position you can play the move your program "really"
>wanted, and this upholds the spirit of the tournament.
>
Robert Hyatt
Thomas Kerrigan <kerr...@alpha.pr1.k12.co.us> wrote:
>Getting a chance to set the position up again doesn't give you any extra
>hit points. It just lets you fix "flukes". Take Chess System Tal vs. XXXX
>again. CST obviously played much better than XXXX. If I recall correctly,
>the final score was +13 pawns or so. In fact, Martin told me he was
>thinking about resigning at one point, and because of some idiot
>pondering bug he won. This strikes me as violating the spirit of the
>tournament. Resetting the position would fix this. Resetting the position
>wouldn't fix anything else. If your program pays a suck-o positional
>move, letting it think again won't result in any difference.
>
>Cheers,
>Tom
>
No, but it does allow the following: at 6 ply, you are going to play a
good move, at 8 you stumble onto a "better" move that is an obvious
blunder. You wait a min, stop your program, reset, and when you set the
position up, you enter the correct clock time as you are supposed to. Now,
however, without pondering for a while, and with some time gone off the
clock, the program can't get to 8 ply, and plays the better move. How is
this in the spirit of computer chess? It's happened on more than one
occasion, with someone kicking a power cord out, intentionally dropping a
modem connection, etc. The point is, that once you start the program, it
is completely on its own. You simply have to show up with a debugged program
or suffer the consequences. I've been there, I've suffered, and I learned to
do a better job of testing. You can't put the burden of policing such things
on the TD, and, in fact, asking to restart is technically illegal. I saw Deep
Thought lose a game on time in Cape May, where the computer was up and running,
but the phone system was dead at IBM. Not anybody's fault, but that was
*clearly* beyond their control. Imagine if you let the human factor into the
games, the TD would spend more time handling protests than he would running the
tournament.
Remember: debug, debug, debug, ......
Robert Hyatt
Peter Gillgasch <gil...@ira.uka.de> wrote:
-->In article <4740n4$j...@alpha.pr1.k12.co.us>, kerr...@alpha.pr1.k12.co.us (Thomas Kerrigan) writes:
-->|> Getting a chance to set the position up again doesn't give you any extra
-->|> hit points. It just lets you fix "flukes". Take Chess System Tal vs. XXXX
-->|> again. CST obviously played much better than XXXX. If I recall correctly,
-->|> the final score was +13 pawns or so. In fact, Martin told me he was
-->|> thinking about resigning at one point, and because of some idiot
-->|> pondering bug he won. This strikes me as violating the spirit of the
-->|> tournament.
-->
-->No flame intended but *if* there is any violation of the spirit of
-->the tourney involved then it is not "winning by bugs" but "not resigning
-->when it would be a reasonable thing to do". Note that we often don't
-->resign early simply because we feel reluctant to do so. Best example
-->was round 2 in Hong Kong because it simply was fun to talk with Don while
-->he killed us - it simply didn't matter to me. Now if *Socrates would
-->have crashed before executing the mate I am sure we would have found
-->to a way to hide that detail from Mr Valvo...
-->
-->|> Resetting the position would fix this. Resetting the position
-->|> wouldn't fix anything else. If your program pays a suck-o positional
-->|> move, letting it think again won't result in any difference.
-->
-->Sorry Tom but I have to disagree. Imagine a human tournament
-->and (say) Kasparov simply goes for lunch during a game against
-->Joe Fish. He is the better player, so why is he not allowed to
-->break all rules and expect understanding for doing so?
-->
-->Of course winning (or loosing) because of a bug is not really
-->satisfying, but I wouldn't make such a fuzz about it because
-->it was the *programmer* that put the bug there and computer tourneys
-->are mainly programmer tourneys, not chess tourneys. And if CST
-->plays =N instead of =Q, well it *made* the move and the move
-->was perfectly legal. If the director allows resetting the position
-->in that case, what would be next? Unsound sacrificies?
-->
-->If your program terminates execution and/or you clearly made an
-->operator error then the rules define perfectly what will happen.
-->In all other cases the rules are clear as well. As Bob said: "Test"!
-->
-->-- Peter
-->
-->------------------------------------------------------------
I can recall several instances of my "violating" tournament rules, but
with the express consent of Mike. One case comes to mind a few years
back, when we were playing Zarkov. The game looked hopelessly drawn,
when Zarkov crashed, John restarted, and it crashed again. I approached
mike, and asked that we stop the clock while John debugged and (hopefully)
fixed the problem. He agreed (reluctantly, under my "threat" of crashing
Cray Blitz and making him adjudicate the game.. :) ). John found the
problem, and we continued. Fortunately (for me) we won the game, however,
I felt that it was more interesting (again, for me) to see the game played
out. Notice that both of us agreed to this. Bottom line: such things are
often "morally" right, but you can't expect the TD to create a policy that
would open Pandora's box. Had I said "no, clock continues to run." I doubt
John would have been particularly unhappy; in fact, as I recall, we had to
really "urge" him to fix the problem.
Another problem occurred once due to parallel processing. We reached a position
against HiTech, where after HiTech made a move, I discovered that Cray Blitz was
"hung". It had trashed data structures due to a bizarre timing problem that we
had not seen in weeks of testing. Mike had us kill and restart, since the
program was obviously broken. Hans protested, but Mike's reasoning went like
this: IF CB had hung while thinking, and was still running, but not communicating,
it would forfeit on time; however, it was not hung analyzing, but was hung so
that I could not enter a move. As a result, re-starting was "demanded" by
Valvo, because I offered to resign. Ken Thompson, Tony Marsland, Monty Newborn
and Mike and I had a long discussion. In the end, we restarted. No, I don't
remember how the game turned out. However, as you can see, this can be a
truly sticky issue. Current rules are pretty clear. Subjective decisions have
no place if the tournament is to run smoothly.
Bob
Martin Zentner
>Getting a chance to set the position up again doesn't give you any extra
>hit points. It just lets you fix "flukes". Take Chess System Tal vs. XXXX
>again. CST obviously played much better than XXXX.
I wouldn't dare to say, which program played better in that match. Thorsten
Czub (spelling?) , the operator of CST and Chris Whittington (programmer of
CST)
were both surprised, that XXXX played almost their style of chess. XXXX was
pondering on most moves played by CST!
Between moves 35 and 40, both programs didn't find proper plans and both
parties agreed that this in an interesting match so far. Both programs did
at least show that they have some ideas ...
Then with move 46. ../Rxf1 XXXX overestimated the value of a covered freepawn
and played a rook vs. bishop & pawn sacrifice and after 52. Rg7 played by CST
XXXX scored it correctly as -2.something with a mainline:
53. Rxg3 Bxg3 54. Kxg3 seeing that the remaining pawn (with equal material)
structure was lost ! (The e-pawn will be captured soon.)
CST did *NOT* see this and decided to attack with his king, which wasn't bad,
too, as XXXX couldn't advance its freepawn. That was the first time I thought
about resigning, but as long as that freepawn was on the board, I wanted to
see,
how CST handles this ...
Finally CST captured two more pawns on c5 and b6 bringing XXXX to a
-6.something
score. Again I thought about resigning, but a few moves later XXXX saw a mate
in 6 against it and now I really wanted to resign, but as CST announced that
mate as well, we decided to finish this off as it would just take a few more
seconds. Both parties agreed on "play until mate" !
>If I recall correctly, the final score was +13 pawns or so. In fact, Martin
>told me he was thinking about resigning at one point, and because of some
>idiot pondering bug he won.
1st: From the above, you can see that I was thinking about resigning quite
often, but then again: "A game is over when it's over."
2nd: The score before 75. c8=N wasn't +13, but mate in 2 for CST.
After 75. ../Kxb8 the score was +12.something in favour of XXXX, as that
freepawn was still on the board :-)
3rd: It wasn't a pondering bug, but a hashtable bug, if I recall it correctly.
Thorsten Czub told me, that he reported that bug to Chris Whittington some
month before the WMCCC95 and he didn't fix it !
>This strikes me as violating the spirit of the tournament.
??? A tournament is a contest of programmers. It should show, who did the
best job so far. If your machine crashes, you should loose immediately
regardless of the position. That's a clear point !
(You are responsible for the garbage your program plays or doesn't play,
e.g. Round 1: Gandalf-Stobor (1-0), Round 9: Gromit-XXXX (0-1))
I bet that every programmer had nightmares about their program to crash
at some time in a tourney.
And if it happens, you can be sure, that the programmer will be after
that bug like hell, because it doesn't give a good reputation for a program
that crashes. People will remember this as well as a win against Kasparov !
(Especially if the program is commercially available.)
??? So what could you possibly call "violating the spirit of the tournament" ?
>Resetting the position would fix this.
As the bug was reproducable after reentering the position before c8=N, it
wouldn't have helped to setup again. And again, why should a reset be allowed
at all ?!
>Resetting the position wouldn't fix anything else.
In your first posting you claimed that one should be allowed to play the move
that was obviously better and reset the board to the position after that move.
And this will definetely give you increased performance ! (Ingo Altohoefer and
his 3-brain shows this easily...)
>If your program pays a suck-o positional move, letting it think again won't
>result in any difference.
Agreed, so why give it a second chance ? :-)
[In fact: Could it be that you're argumenting against your own point ?!
At the beginning of your posting you said, resetting would fix flukes and
now you say, that there will be no difference after a reset ?
:-]
>
>Cheers,
>Tom
-Martin
Peter Gillgasch
|> hit points. It just lets you fix "flukes". Take Chess System Tal vs. XXXX
|> thinking about resigning at one point, and because of some idiot
|> tournament.
No flame intended but *if* there is any violation of the spirit of
the tourney involved then it is not "winning by bugs" but "not resigning
when it would be a reasonable thing to do". Note that we often don't
resign early simply because we feel reluctant to do so. Best example
was round 2 in Hong Kong because it simply was fun to talk with Don while
he killed us - it simply didn't matter to me. Now if *Socrates would
have crashed before executing the mate I am sure we would have found
to a way to hide that detail from Mr Valvo...
|> Resetting the position would fix this. Resetting the position
|> wouldn't fix anything else. If your program pays a suck-o positional
|> move, letting it think again won't result in any difference.
Sorry Tom but I have to disagree. Imagine a human tournament
and (say) Kasparov simply goes for lunch during a game against
Joe Fish. He is the better player, so why is he not allowed to
break all rules and expect understanding for doing so?
Of course winning (or loosing) because of a bug is not really
satisfying, but I wouldn't make such a fuzz about it because
it was the *programmer* that put the bug there and computer tourneys
are mainly programmer tourneys, not chess tourneys. And if CST
plays =N instead of =Q, well it *made* the move and the move
was perfectly legal. If the director allows resetting the position
in that case, what would be next? Unsound sacrificies?
If your program terminates execution and/or you clearly made an
operator error then the rules define perfectly what will happen.
In all other cases the rules are clear as well. As Bob said: "Test"!
-- Peter
------------------------------------------------------------
Peter W. Gillgasch
Klosterweg 28/I-113 email gil...@ira.uka.de
76131 Karlsruhe/Germany Phone ++49/(0)721/6904255
Oxford Softworks
> Path:
cpsoft.demon.co.uk!news.demon.co.uk!dispatch.news.demon.net!demon!tank.news.pipex.net!pipex!newsf
eed.internetmci.com!news.sprintlink.net!in2.uu.net!EU.net!Germany.EU.net!zib-berlin.de!irz401!new
s.tu-chemnitz.de!faui0n.informatik.uni-erlangen.de!uni-erlangen.de!rz.uni-passau.de!news
> From: Martin Zentner <zentner>
> Newsgroups: rec.games.chess.computer
> Subject: Re: ICCA rules, was TOP 10 REASONS...
> Date: 31 Oct 1995 13:41:56 GMT
> Organization: University of Passau, Germany
> Lines: 97
> Message-ID: <475934$a...@news.rz.uni-passau.de>
> References: <4740n4$j...@alpha.pr1.k12.co.us>
> NNTP-Posting-Host: 132.231.71.152
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.3 sun4c)
> X-URL: news:4740n4$j...@alpha.pr1.k12.co.us
--
To eliminate any confusion, this game was not subject to appeals or any
intervention from TD. When CSTal played c8=N, it was played on the board, XXXX responded and
the game went to its result. We're talking about a *hypothetical* appeal to TD ....
Yes, it was an interesting game. As you say, moves 35-40 were the sort of 'nothing' positions
where it is difficult for programs to find plans, but other parts of the game had situations with
chances for a result.
The bug wasn't from the hash table, I posted an earlier article explaining the exact reasons. It
has nothing to do with known, but unfixed, bugs; but instead some special case code in a rarely
used loop.
But, these postings do illustrate what happens at the chess tournaments:
Programmers and operators (and kibbitzers) usually talk and discuss and analyse right throughout
the game. Obviously programming teams have emotional involvement and can be sad or happy or
depressed or whatever, we make a strong investment in our work, we invest several days at
tournaments (for some, travelling 1000's of miles).
What I am trying to say is that we are not robots who should not be allowed to touch our
machines, for most programmers a major purpose in competing is to analyse and discuss and inpect
the program output. If a program hangs or is bugged stupidly, this can be detected (no mouse? no
menus? no clock tick? engine says one thing GUI says another?) and, if it is possible for a reset
or reconstruction, it seems to me much more sensible that sensible people should reconstruct and
play on; rather than impose a blanket "that's tough" rule. Programmers want to test *engine*
output, punters want sensible games.
Personally, I would prefer flexible rules, that allowed for bugs and problems rather than the
"can't touch" nonsense that already infects chess. Can't touch the king, can't touch the
opponents pieces, can't speak without j'adoube, penalties if you do. You don't need to be a
psychologist to see where such comes from.
Currently the rules situation is almost totally unclear. There are no written rules that I have
ever seen that cover the bug/crash situation. There is no written list of 'precedents' that are
often used to justify decisions, with the result that 'precedents' get used as secret weapons to
be brought out when needed by those in the know. Lack of clarity leads to problems, poor
decisions and dissatisfied people.
chris whittington
chris whittington
>
> In article <46ulbq$g...@alpha.pr1.k12.co.us>,
> Thomas Kerrigan <kerr...@alpha.pr1.k12.co.us> wrote:
> -->Glad to hear you folks found the bug. Sorry to hear it was after that
> -->silly game. :(
> -->
> -->to my own problem, I obviously had a "bug" but I wasn't allowed to set up
> -->the position because my program didn't technically "crash". I think this
> -->is silly. I also think the promotion problem was silly, as your program
> -->obviously didn't want =N.
>
>
>
> There is one problem with the above. If a program "crashes" or a machine "crashes"
> then perhaps starting over and resetting is legitimate. However, if your program
> "hangs" that is simply too bad. Remember that the human cannot assist the program
> in any way, so how can you expect David or anybody to determine whether or not
> the program has some type of timing bug that made it use an excessive amount of
> time? I can see many circumstances where this would be a problem. In effect,
> *anyone* could say "hey, I've got a bug and have locked up" rather than letting their
> program lose on time.
>
How to tell the difference between a crash and a hang ?
Er, mouse not working ?
menus not working ?
clock not ticking ?
chris whittington
Robert Hyatt
chris whittington <chr...@cpsoft.demon.co.uk> wrote:
-->hy...@willis.cis.uab.edu (Robert Hyatt) wrote:
-->>
-->> In article <46ulbq$g...@alpha.pr1.k12.co.us>,
-->> Thomas Kerrigan <kerr...@alpha.pr1.k12.co.us> wrote:
-->> -->Glad to hear you folks found the bug. Sorry to hear it was after that
-->> -->silly game. :(
-->> -->
-->> -->Anyway, you're right, the rules should be much more explicit. With regard
-->> -->the position because my program didn't technically "crash". I think this
-->> -->is silly. I also think the promotion problem was silly, as your program
-->> -->obviously didn't want =N.
-->>
-->>
-->>
-->> There is one problem with the above. If a program "crashes" or a machine "crashes"
-->> then perhaps starting over and resetting is legitimate. However, if your program
-->> "hangs" that is simply too bad. Remember that the human cannot assist the program
-->> in any way, so how can you expect David or anybody to determine whether or not
-->> the program has some type of timing bug that made it use an excessive amount of
-->> time? I can see many circumstances where this would be a problem. In effect,
-->> *anyone* could say "hey, I've got a bug and have locked up" rather than letting their
-->> program lose on time.
-->>
-->
-->How to tell the difference between a crash and a hang ?
-->Er, mouse not working ?
--> menus not working ?
--> clock not ticking ?
-->
-->chris whittington
-->
-->
Exactly the point. My answer: if the O/S is running (control-C or control-BREAK
will interrupt the program) then the game is over, since the program was hung and
not the machine. If the machine hangs, it's not the program's fault (unless, of
course, you are running under DOS, where you can clobber most anything in memory
you want and make *everything* fail with a program bug.)
Assumption 1: real O/S, and not DOS. In this case, if you can confirm that the
machine is alive and well, then the program loses. program bugs are *not* excusable
and should not be used as a way to let the operator restart the game. Machine
failures are not the program's responsibility and should not penalize it.
Assumption 2: windows: ctrl-alt-del. If windows intercepts this and can kill
the application, the program loses. If not, the machine is at fault and the game
continues.
The intent of allowing restarts after failure has been taken to a completely
silly extreme. That's why the auto-referee would be so nice. If the two
referee programs can talk, both machines are functioning. If something hangs
so that the referree "goes away" reboot, restart and continue. If the referee
is alive and well, but the program won't move, it has two hours or whatever is
left on its clock to wake up. No human intervention. If you want to pop open a
second window, and run an independent task that displays a clock for example (not
connected to the chess program in any way) this would serve as a useful measure of
whether the machine is up or not. Clock running, keep playing.
Jan Eric Larsson
>I'm not sure how a bug rule should work. Try this: the operator gets 2
>chances to set up the position and restart his program. I think the 15
>minute rule is supid because it gives you a chance to debug, but if you
>just set up the position you can play the move your program "really"
Robert Hyatt writes:
>There is one problem with the above. If a program "crashes" or a
>machine "crashes" then perhaps starting over and resetting is
>legitimate. However, if your program "hangs" that is simply too bad.
>... That's why one of the "golden rules of computer chess
>competitions" is test, test and test.
On a related theme, Gordon Goetch of the Hitech team gave me nice
advice once. The Hitech machine sometimes behaved strangely, and
they had the software check out and break seemingly bad things
going on. So it could supposedly sometimes come out with error
messages and ask for a restart, if I understood it right.
If you do something like this, it is important to remember not to
print out a "resulting move" for tracing purposes, or at least to
print the things so it is obviouis that it isn't a game move. The
Hitech team had had opponents demand that they perform "trace" moves
from crashes over the board.
>I've always checked timing code out carefully since then, including
>playing *long* games on the machine I'm going to use, to detect this
>sort of problem before it embarrasses me in a tournament.
And even that might not help. The Cray Blitz "Levy Bet" match
comes to mind, where I seem to remember that the pure mechanics
of transferring and typing in moves messed up the timing. I hope
Robert forgives me for pulling this up. I just wanted to refer
to some relevant chess history :-)
Jan Eric Larsson Phone: +1 415 725 3859
Knowledge Systems Laboratory Fax: +1 415 725 5850
Department of Computer Science E-mail: Lar...@KSL.Stanford.Edu
Stanford University
701 Welch Road, Building C "We watched the thermocouples dance to the
Palo Alto, CA 94304, USA spirited tunes of a high frequency band."
Robert Hyatt
chris whittington <chr...@cpsoft.demon.co.uk> wrote:
-->Martin Zentner <zentner> wrote:
-->>
-->> Oxford Softworks <po...@cpsoft.demon.co.uk> wrote:
-->>
-->> [... my original posting deleted ...]
-->>
-->> >the game went to its result. We're talking about a *hypothetical* appeal to TD >....
-->>
-->> Right.
-->>
-->
-->> >But, these postings do illustrate what happens at the chess tournaments:
-->> >Programmers and operators (and kibbitzers) usually talk and discuss and analyse >right throughout
-->> >the game. Obviously programming teams have emotional involvement and can be sad >or happy or
-->> >depressed or whatever, we make a strong investment in our work, we invest >several days at
-->> >tournaments (for some, travelling 1000's of miles).
-->> >
-->> >What I am trying to say is that we are not robots who should not be allowed to >touch our
-->> >machines, for most programmers a major purpose in competing is to analyse and >discuss and inpect
-->> >the program output. If a program hangs or is bugged stupidly, this can be >detected (no mouse? no
-->> >menus? no clock tick? engine says one thing GUI says another?) and, if it is >possible for a reset
-->> >or reconstruction, it seems to me much more sensible that sensible people >should reconstruct and
-->> >play on; rather than impose a blanket "that's tough" rule. Programmers want to >test *engine*
-->> >output, punters want sensible games.
-->>
-->> I wasn't talking about not moving pieces on the board or not talking with the
-->> other team. And I didn't accuse anyone of cheating, I simply stated, that there
-->> is room for this. But why should an operator need to touch a machine after the
-->> match has started ?
-->>
-->
-->If the program has only one screen of info then there's no need.
-->But some programs have several screens of info (Was it the old Colossus Chess - press the space bar
-->to get the thinking window?). CSTal has three screens of thinking info - I think you saw them
-->during the game, and, personally, I find it interesting to flip between them to see what the program is
-->thinking.
-->As long as the monitor display is open to all to see, then I don't see this should be a problem ?
-->
-->
-->
-->chris whittington
The problem is this: suppose you "rigged" your program so that by flipping
through the screens is such and such an order, you could tell it to search
a little longer? Not likely, you say? More likely than you might suspect,
at least in the mind of your opponent should he be getting crushed. Protests
like this have become commonplace, to the point that ACM rules explicitly disallow
your typing *anything* at all other than a move, and time if asked. You can't
even "query" the system to see if it's up without permission of the TD. This
is a direct result of what I would call paranoia, but it's there, nonetheless.