[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[computer-go] expert programmers (was Re: Pattern matching -example play)
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?)
> 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/