Re: [computer-go] KGS Tournaments: Cheating

[David G Doshay <ddoshay@xxxxxxx>]

On 7, Mar 2005, at 8:38 AM, Stuart Yeates wrote:

> On Mon, 7 Mar 2005 11:22:29 -0500, Evan Daniel <evanbd@xxxxxxxxxxxxxxxxx> 
> wrote:
> > On Mon, 7 Mar 2005 16:06:34 +0000, Stuart Yeates <syeates@xxxxxxxxxxxxxxxxx> 
> > wrote:
> > > On Mon, 7 Mar 2005 13:25:04 +0000, Nick Wedd <nick@xxxxxxxxxxxxxxxxx> 
> > > wrote:
> > I think a better fashion is to have copies of the code in use sent to
> > a third party or tournament organizer beforehand, and have them
> > reproduce the moves later if needed.  That prevents cheating the
> > second time around.  To account for time variations and the like, just
> > reproduce the game several times with slightly different times
> > available; the program is likely to produce the same move each time,
> > and should certainly be capable of producing the move on one of the
> > settings.  Requiring exact reproducibility is a pain, but "close
> > enough" should cover most cases.
> This works fine for general purpose programs on general purpose 
> hardware.
>
> If someone has a program written in an obscure programming language
> using libraries they don't have the rights to copy/reproduce and
> custom hardware, this approach looks significantly more challenging.
I am willing to jump through a number of hoops to prevent cheating,
but for any computer other than a cluster of G5 Macs to try and
reproduce what SlugGo does would take a VERY long time. SlugGo
is written such that a single computer CAN do exactly what it does,
but it will take just over 25 times as long on a single G5 cpu, and
roughly twice that long on a single G4, for the settings we are using
now (24 search paths). At some point we will see what all 72 cpus can
do, and then the time for a single cpu would go up accordingly.

I am not complaining, and I certainly am not asking to be treated any
differently than other programmers, just making an observation.

Also, the use of a RNG in GNU Go does lead to slightly different
evaluations of otherwise close moves, but SlugGo saves enough
information about its move generation that I believe that a
"reasonable" TD could look at this file and see that "Oh, it chose
a different move, but in the tournament the difference between these
choices was small, and the same choices are close this time too."

I have been thinking about how to prevent cheating in a remote Go
tournament ever since we started SlugGo because I knew that I was
not going to be carting 2 full sized racks of stuff anywhere.

I have been unable to think of anything that would cleanly allow
confidence that no human was assisting a remote computer. As
per the cartoon in the New Yorker: "On the internet nobody knows
you're a dog." Or anything else.

With the announcement of the Mac Mini I can now build a smaller
cluster of slower G4 computers for travel. Given time limits it will
not be able to search as deeply or as wide as the full cluster at the
university, but it is all that I can do.

Cheers,
David


_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/