[Top][All Lists]
[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
- [gnugo-devel] idea, Dan Stromberg, 2003/09/06
- Re: [gnugo-devel] idea,
Evan Berggren Daniel <=