Re: [gnugo-devel] breakin code discussion

[SP LEE]

> 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
>

I have replayed the game I posted in
http://mail.gnu.org/archive/html/gnugo-devel/2003-07/msg00231.html. 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