Re: computer-go: Two ways to program a GO-engine

[Roland <goprog@xxxxxxx>]

Hello,

R>   1. Try to make a program that achieves perfect or near perfect play.
R>   2. Try to make a program that plays like the best human players. In

I'm answering my own posting now, because after I got some answers
here is what came out: it seems to be agreed that task 1. will never
be solved due to complexity problems(np-complete or hard or whatever).
Thus we should concentrate on approach 2. As another reader pointed
out, most development in chess programs has been achieved through
hardware progress which enabled deeper search. Well this will
presumably never happen in Go because of the reasons we all know
about. So our only chance is to give the program a human
understanding. Well, I think we should concentrate on 2 issues:

a)how to translate abstract knowledge to a computer.
b)how make the computer think in abstract terms.

This seems to be also pretty interesting in terms of artificial
intelligence.

But why am I posting this what most of you probably already know? Well
the fact is, that in most programs I miss this basically correct
approach! Of course you may say:"No but my program performs all sort
of computations, taking into account territory, influence, etc...so it
tries to emulate human thinking."
Sure, every program use some heuristics who work more or less and
applies it blindly. One example are the joseki libraries that many
programs have, without having a real understanding of what each move
means, and therefore they won't be able to handle any unknown pattern.
The human pro player knows not only the josekis, but he has an
understanding of why each move is played the way it is. The proverb
goes:"Don't learn Joseki, learn from Joseki".

The idea I have in mind, is to DESIGN a game engine from the very
scratch with the purpose to emulate abstract human thinking in terms of GO
play. So its not just making a lot of functions like
"compute-influence", "look-which-stones-belong-to-the-same-group",
etc...It's deeper than that. The goal would be to model more abstract
terms, don't know how, and best of all make it easy to upgrade, so
that if you suddenly recognize that you have to add another bit of
abstract knowledge, you will know where to change the program. This is
where I think not enough work has been done. Most programs started
with some simple routines and heuristics 10 years ago and have grown
to their actual size by adding more and more functions to it. But they
don't have been designed correctly from the scratch.
It's the same when you want to program a compiler(which I did once
btw). You first have to build a concept in your mind, of the compiler
engine, how it will work, without going into details. Once you have
figured it out, the details of programming derive automatically from your
main concept. And if I remembered correctly, they needed 10 years to
program the first compiler in history. After they figured it out,
today you can program a simple compiler in one year or less(like we
had to do in one of our computer science classes). I somewhat have the feeling that its
this kind of fundamental work that is still missing.


Does this make sense to you?

-- 
Best regards,
 Roland