Re: [computer-go] Learning : was Chess programs versus go programs

[Chris Fant <chrisfant@xxxxxxxxx>]

On Wed, 08 Dec 2004 06:17:14 +0100, Vincent Diepeveen <diep@xxxxxxxxxxxxxxxxx> wrote:
> In history nothing has ever beaten human learning capacity. The human way
> to learn things is without any compare.

I'll tell you what's without compare: the rate at which computing power grows.

> If you optimize all those thousands of patterns by hand, nothing beats
> human learning there. From a single game i'm sure all the fantastic go
> players here who also program a go program, are capable of exactly knowing
> where the bug is and in which pattern, which an automatic system never
> figures out in its entire life.

In a learning system (at least in mine), the bugs are not in the
patterns, the bugs are in the code that generates the patterns.  Fix
one bug, benefit many/most/all patterns.  I have tens of millions of
patterns.

> The reason why it's not so obvious to everyone here yet why global search
> is so very important, is because of the huge effort done by strong go
> player- programmers who created strong evaluatoin functions.

A strong evaluation function is essential.  I think everyone here
knows that, and I think everyone knew that a long time ago.  You will
hear people say that searching more moves only makes the program
worse.  This is because the evaluation functions STILL aren't good.  A
trivial chess evaluation function (add up the piece values) is good
enough that for a given search depth (probably needs to be greater
than two or three), searching wider has an overall improvement in
strength.  I will probably be attacked for this statement because it
is out of my domain, but hopefully I got my point across.

> As my chessprogram has the biggest chess evaluation function on the planet,
> i'm in the know how difficult it is to write that.

Because you wrote a complex chess evaluation function, you know all
about Go evaluation functions?

> The more complexity something has, the more difficult automatic tuning it
> gets as the optimizers don't even know where to start optimizing.

Here's where you really start to get lost.

> Suppose that we have an optimal tuned evaluation function. Really *optimal*
> for the knowledge it has.
> 
> Only 2 parameters are wrong tuned.

So feed it more data.  If you have given it a large enough amount of
data, the only parameters that will be wrong are the ones that don't
matter much.  Assuming of course, that you have not done something bad
in your learning algorithm (this is the heart of the problem).

> So it will conclude with respect to the 1 eye pattern that it is wrong to
> make it worth more. The reason for that is because when it played a few
> games making 1 eye it didn't care to make 2 eyes, so it then also created 1
> eye in some other group meanwhile losing this group as it just has 1.

So there is a parameter dependancy.  It has to raise the weight of
2-eye before it raises the weight of 1-eye.  I'm sure there are
countless examples of this in learning systems of all types.

> Now this is a dead simple example of course. The more complex your
> evaluation function gets the more difficulty for a human to tune it. Yet
> that's relative easy still for him.

Yes, this is dead simple, so there is no need to use an automatic
learning approach.  But there are many things in this world which are
not as simple

> It will be busy lightyears testing before it figures out that laying a
> block of stones all over the board is real bad. 

My system starts with the following knowledge: the rules, Benson
safety, how to score a game in which no valid moves remain (where
valid means that it does not fill a single point eye owned by a single
chain).  From this knowledge and my learning algorithm, it quickly
learns lots of basic go knowlegde that I have not programmed in.  I am
not saying that it plays well, but simply that it is learning.  The
ability to learn higher level knowledge will require more creativity
on my part and more time to write the code (the same thing that is
required to improve any Go program).

> A single cpu can have 1 billion transistors. 1 billion. All hand designed.

I'm sure they use many different types of transistors, but not 1
billion different types.  Most are exactly like the one beside it.

> So the design is still by hand, but the actual transistor layout is done by
> verilog type compilers.

Verilog compilers don't know what a transistor is.  They know what
gates are available in a given library.  They use those gates to build
an efficient, equivalent representation of the verilog source code. 
This is all pre-layout.  Layout is another step entirely.

> verilog compilers currently cannot optimize such designs very well when
> number of transistors increase.

Humans break up the design into managable blocks and then feed to the
compiler.

> Those processors have a number of transistors which *no* human can
> understand fully. Yet hand implementing the design into transistor is
> BETTER and going
> to be relatively better in future than automatic compiling your design to
> transistors.

The trend in digital circuit design is toward more automatic
processing steps.  This is getting better all the time as the
automation tools improve and computing power increases.  This include
compiling the logic into gates as well as placing those gates in place
and routing the connections between them.

> Yet in engineering even such sizes, especially at such sizes, hand design
> wins from automatic design a lot.

Hand design is done in places that you can do it once and stamp it out
millions of times, like a memory cell (they take a huge portion of
those transistors).  Control logic is handled automatically because
there is no point in putting in the effort to do it by hand if you are
only going to need one instance of it.  Plus, a human probably
couldn't do it as well anyway do to it's complex, seemingly random
nature.

> For those verilog compilers they don't use an average pc by the way.
> They use at least 256 processor machines or more. They really throw insane
> amounts of system time at those designs.

Right, they are willing to spend lots of money on the automatic
approach, because it is better than doing it by hand.

> Still believe in automatic learners in go?

Yep.
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/