gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] idea


From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] idea
Date: Mon, 8 Sep 2003 00:16:47 -0400 (EDT)

On Sat, 6 Sep 2003, Dan Stromberg wrote:

> What if gnugo were augmented with something kombillo-like?
>
> Moreover, what if the kombillo-like tool knew how to look at a large
> database of not just pro games, but also amateur games?  And what if it
> knew how to find the play in a given situation made not just most
> commonly, but by players of the highest (weighted) average rank?  That
> way, you don't just get excellent answers to excellent moves from your
> database - you also get quite a number of decent answers to slightly
> less decent moves (as well as slightly less decent answers to decent
> moves, which could be thrown out, or weighted lower when gnugo is
> choosing a move).
>
> Naturally, this will never cover all moves, but used with the existing
> approach of gnugo, they could become a powerful combination.
>
> Even if just a traditional kombillo-like approach is used, this could
> still give a formidable opening.
>
> Comments?
>
> (I'm planning to take this up with the kombillo maintainer again once
> he's back from vacation)

It's an interesting idea.  Unfortunately, I'm not really sure of a good
way to add it to the current architecture.

This isn't fundamentally different from an opening book; there are some
relatively standard techniques for generating opening books, and you can
draw from game libraries when doing so.  I know Inge Wallin has some code
that does some of this, and I think he may have long-term plans to
incorporate it into gnugo (Inge, did you say something about that at some
point, or am I making it up?).

Another option is to not change the gnugo engine at all.  I have written
the beginnings of a metamachine that keeps a game tree outside of gnugo,
and uses gnugo to suggest moves and evaluate ending board positions; at
present, I don't really trust gnugo's evaluations, so I just play the game
to the end after a node or so of branching.  This approach has the
advantage that you can get moves from different sources than just gnugo;
one option is a collection of games, another is human suggestions.
Obviously, there are problems at large sizes, so I only have it play 9x9
boards.  I haven't yet tried importing a large game library, but that's on
the todo list once I implement a few other features.  I haven't heard a
lot of interest in the code yet, but let me know if you want to try
playing with it; I should warn you that at present it's kinda hackish and
ugly though.

So far I think the results are interesting; I'm giving it a lot of help,
but with its current game tree I can't always beat it (when I don't
give it any advice), and when giving it advice I find that it not
uncommonly comes up with better moves than I do (of course, it not
uncommonly comes up with really awful moves, but that's what the advice is
for...).

Evan Daniel




reply via email to

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