Re: [gnugo-devel] re: some question

[Gunnar Farneback]

"zergling" wrote:
> I am designing a computer go program. Natually I hope it will be the best.
> Perpaps what I said make you unhappy. I dont want to debase your work.
> But there is a fact, handtalk, a small program, can beat most computer
> go programs. So we should be concerned more about the theory. If we run
> the wrong way, it is hard to reach or even near the goal. A high building
> should not have a soft base.

You're making very far leaping conclusions from the fact that Handtalk
is small in relation to its strength. In particular since the
following excerpt from http://www.wulu.com/ht-techn.htm seems to
contradict your later arguments:

| The move decision in Handtalk is mainly based on static evaluation.
| In the earlier versions up to 1994, look-ahead is not included in
| the move decision. In 1995, look-ahead is tried to be included, but
| the strength appeared not higher. Although it was getting a little
| stronger in the recent years, the look-ahead for move decision seems
| disappointing. Recently I made a new version of Handtalk without
| look-ahead for move decision. It seems somewhat weaker than the
| version with look-ahead in the games vs. the latter, but nearly the
| same strength as the latter in the games vs. other programs.
|
| The strength of Handtalk mainly depends on the precise calculations
| in its static evaluation. An important key is block identification
| and safety estimation of blocks (here I use the term 'block' instead
| of the common used term 'group' to avoid confusion with the term
| group in group theory of mathematics).

> English is not my native language, so perhaps I make some wrong expression.
> I hope it not affect the meaning.

It probably doesn't but sometimes it may affect the clarity.

> But I think perhaps gnugo would be better to contain a "global
> search" to replace the worm_reason owl_reason fuseki etc. "Global
> search" is base on the result of "local search", to reduce the
> complexity. It is difinitely right. It is easy to prove. So how
> about spliting the local search to more search?

Sorry, but I can't make much sense of this. Could you try to explain
it in more detail?

> Search is more accurate and just a little expensive then static
> judgement when the explored nodes is in limitation.

I'm not sure what you want to say here either, but usually it's
necessary to do a static evaluation of the leaf nodes. To keep the
number of nodes sufficiently limited is a non-trivial problem.

> In this way , the program will be beautiful. It only cantains search and
> evaluation.
> Now look at gnugo's code:
>     do_genmove(...){
>         examine_position(color, EXAMINE_ALL);
>         worm_reasons(color);
>         owl_reasons(color);
>         fuseki(color);
>         shapes(color);
>         combinations(color);
>         endgame_shapes(color);
>         fill_liberty(move, color);
>         aftermath_genmove();
>     }
> 
> Forgive my offence, It is really ugly.

I disagree. There are certainly pieces of the code which are more or
less ugly, but the structure of genmove() really doesn't bother me.

> Many computer go program has some database about eyes shape etc.
> They are used to accelerate the search. But they are only
> to accelerate the search. It means the database only record the
> familiar search's result. If using search engine, it must get
> the same result in longer time. In this way. the search engine can maintain
> the database automaticly.

There may be a few programs following this philosophy but I very much
doubt that it would be common, especially among strong programs.
Please give an example of a strong program which does not make use of
any hand tuned pattern databases.

> The program is still poor, it can not know about anything. But it can give
> me some information using probalility.

Are you refering to some program you have written?

> There is one sample, there are two white group A and B??they are surround
> with black.
> but they have some probability to connect. How to choose connect or not?
> if a is alive A's value is value_a , B's is value_b, current connect
> probability is connect1,
> A's alive probability is alive_a , B's is alive_a, a move make connect
> probability increase to connect2
> What is the value of this move?
> 
> before move:
>     total_value1 = (value_a * alive_a + value_b * alive_b) * (1-connect1)
>         + (value_a+value_b)*((alive_a+alive_b)>1)? 1:
> (alive_a+aliveb))*connect1
> after move:
>     total_value2 = ... (the same function as above but using connect2
> replace connect1)
> 
> the move's value = total_value2-total_value1;
> 
> It match the fact, it is a valuable move to connect 2 weak group.
> But valueless to connect 2 alive group.

This is in practice not very different from how GNU Go values
connections, see connection_value() in value_moves.c

> I think we can find many probability to describe the concept of the go.
> And we can use search to make probablity accurate.

Why would this be more successful than other approaches?

To be perfectly honest I'm doubtful whether you have some real
insights to share or are just hypothesising about things you know very
little about. Would you care to share some information about your
knowledge and experience in the following areas?

* games programming in general
* go programming
* statistical methods

/Gunnar