[Top][All Lists]

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

Re: [gnugo-devel] breakin code discussion

From: SP LEE
Subject: Re: [gnugo-devel] breakin code discussion
Date: Mon, 28 Jul 2003 18:02:18 -0700

> Arend wrote:
> > I don't want to be impolite, but I think anyone interested in
> > performance could have noticed that gnugo-vs-gnugo games are
> > 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 -- 
> > are probably worst case performance wise). The reason for this is
> > twogtp matches are far more peaceful than typical games, and hence
> > 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
> >
> > 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

I have replayed the game I posted in In
that game the break-in code was disabled and I enabled break-in during
replay. I don't dare to draw any general conclusion and my comments are
specific to this game.

There are two places where gnugo thinks different with and without
break-in code.

Move 98 (black): GNU Go plays G8 (31.50) - Game move G8 (31.50)
Move 100 (black): GNU Go plays J11 (39.61) - Game move Q15 (19.35)
Move 102 (black): GNU Go plays J11 (39.61) - Game move J11 (39.61)

Move 146 (black): GNU Go plays Q7 (7.60) - Game move F19 (6.30)
Move 148 (black): GNU Go plays E19 (12.06) - Game move E19 (12.06)
Move 150 (black): GNU Go plays Q7 (7.60) - Game move Q7 (7.60)

It's interesting that in both cases the break-in code finds a territory
defending move earlier than without break-in code.

SP Lee

reply via email to

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