gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] breakin code discussion


From: Gunnar Farneback
Subject: Re: [gnugo-devel] breakin code discussion
Date: Tue, 29 Jul 2003 00:18:50 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Arend wrote:
> I don't want to be impolite, but I think anyone interested in gnugo's
> performance could have noticed that gnugo-vs-gnugo games are typically
> very fast, a lot faster than NNGS games (which are btw still _a lot_
> faster than when I play a high handicap game against gnugo myself -- these
> are probably worst case performance wise). The reason for this is that
> twogtp matches are far more peaceful than typical games, and hence owl
> costs are far lower than usual. Thus the costs of the connection code and
> the break-in are overvalued there.

Agreed. What I wonder is if there are other ways to get good speed
measures than extending the set of games to replay. Could twogtp games
against some other available engine give more heavy fighting, e.g.?

> While this is true, the numbers recently cited for this are obviously based
> on too few games. Thanks to Inge I can refer to
> http://mail.gnu.org/archive/html/gnugo-devel/2003-07/msg00027.html
> instead.

It is indeed true that we need hundreds of games to determine winning
percentages with an accuracy of a few percent and reasonable
reliability. The problem is of course that this takes lots of time,
making it infeasible for most people. Still, I believe that we
together have sufficient computing power to perform such experiments,
if we could only utilize it efficiently.

This would require a fair amount of infrastructure, but should be
a perfectly feasible project for someone who is sufficiently familiar
with some language like Perl, Python, or Pike. I can provide some
design ideas if someone wants to embark on such a project.

/Gunnar




reply via email to

[Prev in Thread] Current Thread [Next in Thread]