[computer-go] Anchor player

[Łukasz Lew]

Ok, I set up ZG1-d2-5k and ZG1-d2-10k. (and removed MCx series) :)

Can You elaborate a little on how does AnchorMan chooses a move
(algoritmic part)
Is it faster than O(81)? :) Maybe it just sort the moves before the game?

Lukasz

On 9/26/06, Don Dailey <drd at mit.edu> wrote:
> 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/
> > > > >
> > >
> > >
>
>