[computer-go] Anchor player

[Don Dailey]

On Tue, 2006-09-26 at 23:32 +0200, Łukasz Lew wrote:
> On 9/26/06, Don Dailey <drd at mit.edu> wrote:
> > Lukasz,
> >
> > Can you test this at 5K and 10K simulations?    Also, have you tested it
> > at other depths?
> 
> Only D2. This is because I use D2 all as first i.e. I maintain stats n^2 stats,
> where n is the number of legal moves.
> 
> >
> > If it gets over 1500.0  on CGOS with 5K simulations it would be an
> > excellent candidate.  It's still interesting if it requires 10K.
> 
> I believe this will be not enough, as I use truely random playouts -
> I don't use capture heuristic, nor any move ordering.

But just give it a try and see what happens.  I expect it to be over
1400, perhaps close or beyond 1500 but it would be nice to see.   

> > I am surprised because I had a player that I thought did the same thing
> > and it did not test particularly well.  I wonder now if I had an
> > implementation bug or it breaks down if you search too deep because I
> > think I did this with 4 ply searches.
> 
> It's difficult to obtain enoug samples with a constraint that
> particular 4 moves
> should be played in game.

I see that I didn't do it exactly the same as you.  I just experimented
with various kinds of summaries of the path of each line.   Your way is
more specific to reality.   

> > How deep did you gather the stat's, until the end of the game or did you
> > have a stopping rule or limit for the stat gathering part?
> 
> In ZG1-d2 I update 30 * 30 stats - for each pair of moves played in
> first 30 moves of playout.
> BTW Updating in D2 takes 3/4 of running time.
> 
> Does Anchor plays only 10k (5k?) games? What kind of enhancements does it have?

AnchorMan starts with a very basic simulation like the generic players
we have been experimenting with, but it also makes use of the territory
map that you can create with those simulations (the percentage of time
each point is owned by one player or the other.)    It basically avoids
making certain kinds of moves into territory that it has no chance of
owning.   One good rule is to simply avoid self-atari if the map says
the territory is not yours.   AnchorMan doesn't say NO to those moves,
it just applies incentives to do or not do certain things.  Nothing
particularly sophisticated and no patterns.  

It makes it possible to have a very fast 1500.0 program on CGOS and it
was designed as a PDA program so it had to be fast.

- Don 

> Lukasz
> 
> >
> > - Don
> >
> >
> > > Yes, You're right. 100K simulations, depth 2.
> > > To be specific:
> > > I make 100K totally random from beginning to end simulations from
> > > current board.
> > > For each vertexes v1, v2 , colors c1, c2 I gather number of won games
> > > where c1 was played at v1 and c2 at v2. (without restriction that v1
> > > is played before v2).
> > > Then I do fixed depth-2 search evaluating leaves by gathered
> > > statistics. (I check for superko here)
> >
> >
> >
> >
> >
> > On Tue, 2006-09-26 at 22:23 +0200, Łukasz Lew wrote:
> > > Depth 2, described earlier seems to be a good candidate.
> > >
> > > Lukasz Lew
> > >
> > > On 9/26/06, Don Dailey <drd at mit.edu> wrote:
> > > > On Tue, 2006-09-26 at 14:03 -0400, House, Jason J. wrote:
> > > > > How well does a monte carlo bot with a fixed number of simulations fit
> > > > > your profile?  It fits everything except maybe requirement #6
> > > > > (resources).  It's also has the added benefit of being extremely
> > simple
> > > > > to code and for others to understand.
> > > >
> > > > It fits very closely.  If it's limited to about 10,000 simulations, it
> > > > doesn't take much resources but it's a bit on the weak side.
> > > >
> > > > There are a few enhancements that can be done to salvage the strength
> > > > but they must be simple and well defined (and documented) if we want
> > > > something that fits all the criteria I mentioned.
> > > >
> > > > I think it's ideal if the algorithm is documented to the extent that
> > > > equivalent clones can be implemented and especially if the description
> > > > can remain quite simple.    I wouldn't want this to become a complex
> > > > engineering project.
> > > >
> > > > - Don
> > > >
> > > >
> > > > _______________________________________________
> > > > computer-go mailing list
> > > > computer-go at computer-go.org
> > > > http://www.computer-go.org/mailman/listinfo/computer-go/
> > > >
> >
> >