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

["Jim O'Flaherty, Jr." <jim_oflaherty_jr@xxxxxxxxx>]

What is HydraGo?  Website?


Jim O'Flaherty

--- Vincent Diepeveen <diep@xxxxxxxxxxxxxxxxx> wrote:

> 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/
> 

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