Re: [computer-go] expert programmers (was Re: Pattern matching-example play)

[Vincent Diepeveen <diep@xxxxxxxxx>]

At 08:18 29-11-2004 -0600, William Harold Newman wrote:
>On Mon, Nov 29, 2004 at 11:31:00AM +0100, Frank de Groot wrote:
>> 
>> ----- Original Message ----- 
>> From: "chrilly" <chrilly@xxxxxxxxxxxxxxxxx>
>> To: "computer-go" <computer-go@xxxxxxxxxxxxxxxxx>
>> Sent: Monday, November 29, 2004 10:12 AM
>> Subject: Re: [computer-go] Pattern matching - example play
>> 
>> 
>> >I think the best combination is a relative poor playing but excellent
>> >programmer and a high-rated advisor.
>> 
>> Let's say a Go programmer has only two properties: "hacking" ability and Go
>> knowledge.
>> I wonder at what stage in the development of a Go program, and at what
>> strength, Go knowledge becomes more important than hacking ability.
>> 
>> I even wonder whether Go knowledge is very important at all.
>
>I think it should be at least somewhat important. For example, without
>being at least a low kyu player, it might be hard to accurately
>understand the relative importance of things your program is getting
>wrong, even at current levels of computer play. (Should my program be
>worrying more about connections, or solving more problems locally?
>Should my program be invading more? Should I dropping work on all
>other problems until I improve my moyo heuristics?)

Well, of course it's even easier to argue about whether you need any go
knowledge when you have not written a go program at all.

Additionally if you have never coded go patterns before it's very difficult
to realize that what you can do automatic just will never be able to beat
automatic things. There is more possibilities to extract patterns in
automatic ways from the go board than there is board positions on the go
board.

So i'm very sure that creating a perfect automatic player is needing a
magnitude more calculation power than what you need to solve the entire
game by a brute force search.

The brute force search has an upper limit of like 10^30 in go what's needed
to search it to death, whereas go in itself is like 10^100 which means that
an automatic learner needs more like 10^150 to reach the same level like
the 'search to death'.

Of course it's easier to preach to the choir when the choir finds the
current go software that bad, that they are willing to listen to every
possible other solution such as automatic patterns.

Yet as soon as the go software manages to raise its level quite some,
especially play tactical a bit better, that will be the end of the choir
believing in automatic learning approaches. Better tactics is just a matter
of searching a bit deeper and considering more brute force search, in
whatever way that gets achieved. 

Just imagine that next year some HydraGo shows up. Playing incredible
anti-positional moves, then in the middlegame it just kills all go software
because it has better tactics in life&death.

You'll see 1000 posts here then about that only a deeper brute force search
matters.

>> L&D for example. Everybody uses pretty reliable heuristics to cutoff early,
>> like an eyeshape library and n-th order liberties (static evaluation).
>
>On the other hand, maybe at today's level of program strength the
>answer to all my parenthesized questions above is "work on life and
>death!":-)
>
>Admittedly, it can be easy even for a very weak player to see when a
>program is making gross life and death mistakes. Even if the
>programmer is unable to read out the problems himself, many L&D
>mistakes should be visible as gross anomalies in the evolution of the
>program's estimates of the score during the game. But other, non-L&D
>errors can be more difficult to see. if a program was getting in
>trouble by going much too much for territory while accumulating much
>too much thinness and aji, or by ignoring the difference between sente
>and gote, I think it would be much harder for a weak player to spot,
>or even to understand after a stronger player pointed it out. 
> 
>> When one is a strong Go player, one might be tempted to implement one's
>> knowledge of L&D and use that to terminate a L&D search branch early.
>
>I'm not sure whether being a strong Go player is helpful for
>implementing life and death. But I would guess that being at least a
>10 kyu Go player would be helpful for making a program which placed a
>recognizably sane priority on connection into large groups (and
>disconnecting enemy groups) as opposed to doing things locally; being
>at least a low kyu Go player would be helpful for making a program
>which had some sort of recognizably sane should-I-invade heuristic, or
>respected sente and gote (at whatever level of precision is meaningful
>given the program's reading/estimating ability, anyway); and being at
>least a dan player would be helpful for making a program which had
>some recognizably sane balance between preserving thickness and aji
>and pursuing of goals which can be read out and assigned a definite
>territorial score.
>
>Now, things like sente and aji may not be all that important given the
>other limitations of current programs. (They may not even be
>meaningful: how can you have a useful opinion about whether something
>is sente or gote when you can't determine whether you're alive or dead
>in the successor positions?) I think, though, that at some point sente
>and aji will become important. Similarly, as I understand it (never
>having written a chess program, but having studied the chess
>programming literature when I started programming go) king safety and
>center control and pawn structure weren't so important for very weak
>early chess programs, but later strong chess programs needed to think
>about them (not just discover their consequences through search). If I
>(with, in reality, a chess rating of perhaps 1500-1600) imagine myself
>as a 1000 chess player trying to decide how to represent king safety
>in my computer chess program, I speculate that it'd be worth acquiring
>more-than-1000 chess understanding first.
>
>-- 
>William Harold Newman <william.newman@xxxxxxxxxxxxxxxxx>
>What part of "Gestalt" don't you understand? -- Karsten M. Self
>_______________________________________________
>computer-go mailing list
>computer-go@xxxxxxxxxxxxxxxxx
>http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/