Here are some numbers from AntIgo. Alvaro's suggestion seems like a good
one-we're almost there anyway. (I'm not in favor of permitting suicide, but
that's a minor detail.)
I lose a lot more time in UCT than Don does. I think his data structures
are nicer than mine. I haven't tried the epsilon trick yet. It might help quite
a lot.
When I switched from lite to heavy playouts, my program got much stronger,
most of my previous speed optimizations became irrelevant, and UCT became less
of a time sink.
1.8 Ghz laptop
max game length = 3 * 81
no mercy rule
no suicide allowed at all
komi = 7.5
Lite playouts
white wins 57% of the time
average game length 111 (including final 2 passes)
not counting passes 107
games / sec = 22614
UCT games / sec = 10966
if only expand a new node after 100 visits 15058 games / sec
heavy playouts
average game length 109
not counting passes 101
games / sec = 4134
UCT games / sec = 3483
- Dave Hillis
-----Original Message-----
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Mon, 19 Mar 2007 8:31 AM
Subject: Re: [computer-go] average length of 9x9 MC playout
On Mon, 2007-03-19 at 07:42 -0400, Álvaro Begué wrote:
> Hi, everyone. This is my first post to the list.
>
> Beginning chess programmers have something called "perft" at their
> disposal, which is just a count node of a search tree of fixed depth,
> with no prunning whatsoever and no extensions. It's easy to detect
> errors in your move generation or do/undo functions by comparing these
> results with the results of other programs.
>
> The average length of a simulation could play a similar role in
> MC-based go programming. We would have to agree on a simple setting
> that people could try to reproduce. For example:
> 1 - Completely random moves.
> 2 - Multi-stone suicides allowed
> 3 - Don't play in things that look like eyes (all four neighbors are
> the same color or outside, and the enemy has occupied at most one of
> the four corners if in the middle of the board or no corners at all if
> on the border).
> 4 - The game is played until neither player has a valid move.
>
> If people typically disallow multi-stone suicides (although this seems
> expensive to me), change rule 2 to its opposite. We could also change
> 4 to stop when any one player doesn't have a valid move. Any set of
> rules which is specific enough to allow reproducibility is good
> enough, and maybe we can agree on one in this thread.
Unfortunately, each program is different and I suspect what works best
may have to do with the data structure of your programs.
But I agree, that's why I am interested to see what number others are
getting, if they do it the same way I do.
> Álvaro.
>
>
> On 3/19/07, Eduardo Sabbatella <[EMAIL PROTECTED]> wrote:
> > My thoughts about average moves is directly related to
> > the move selection algoritm you use.
> >
> > Using totally random move generator, I'm sure
> > everybody should get the same average of moves.
> >
> > But using diferent heuristics in order to get not 'so'
> > random moves (i.e. ataries getting double possibility,
> > patterns, etc).. Average moves should be different
> > using different approachs,
> >
> > what do you think?
> >
> > My 2 cents,
> > Eduardo
> >
> _______________________________________________
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam
and email virus protection.
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
