gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] Re: Re: zergling


From: zergling
Subject: [gnugo-devel] Re: Re: zergling
Date: Tue, 26 Mar 2002 15:43:02 +0800

> The architecture of GNU Go is evolving. How similar it is to
> Many Faces I can't say.

I guess it by david fotland's post. he post a messege about general approach
to computer go in 1996,
and mention some implements of MFGO. I don't think it is a general approach
but a experiential approach.
There are many experiential definitions in his post. And he must write many
many codes to implement it.
    The below is the secure territory definition:
         A) radiate influence from live stones, compare friendly and
            unfriendly influence at each point.  Many possible influence
            functions.
            1) influence falls as 1/dist (sum from all stones) [MFGO]
            2) influence falls as 1/dist^2 (sum from all stones) [Intellect]
            3) assign high value to points with stone, iteratively bump
               each point with majority of influence on nearby points
               [Goliath]
            4) expand boundary from stones to linkages or enemy, then
               contract
         B) find secure linkages between stones, find inside/outside of area
            surrounded by linkages [Nemesis]
         C) at each point ask question - can enemy place a living stone
here?
            [Go4++]

I prefer c, because it is just the meaning of territory. And A and B is
experiential.
We can not construct a strong go program mainly based of experiential
knowledge.

> GNU Go is not finished. You are critical of the current architecture.
> We are well aware that the current architecture won't produce a
> strong program but the architecture will change over time. The
> experiments in pattern-based search that we are doing now will
> be useful later.

I agree with you. If not find a good architecture, what we can do is only
using existing architecture,
make some current useful module better, and look for a good architecture.
And I donst think regression test is
suitable if you focus on pattern-based search. Perhaps it is better to
create a test suit using some
dead/live puzzle of different difficule level. I have thousands of puzzles,
if u need, I can send it to you.

> Global search is hard, and before you can master it you have to master
> local search. I think you have to learn to solve the easy problems
> before you can solve the hard problems. And you do that not by
> speculating how it is done. You do it by trying and seeing what you
> can do.

I agree too. But I have no idea about the strength of gnugo's local search
ability. There are no test, no report.
I run gungo --life at 9*9 board. but It is running about ten minutes but no
move is generated. :(
If computer go's local search is weak then people, then it is no chance to
win people in global scope.

> GNU Go reads (searches) to study life and death. This is local
> search. The next step is semeai, where there are two groups,
> and this is beginning to resemble global search. GNU Go has a
> semeai module that uses search, but it is still not good. This is
> because it takes a long time to get it right.
>
> Dan



reply via email to

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