Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site randvax.ARPA
Path: utzoo!linus!philabs!seismo!hao!hplabs!sdcrdcf!randvax!jim
From: jim@randvax.ARPA (Jim Gillogly)
Newsgroups: net.games.go
Subject: Re: AGJ article
Message-ID: <1605@randvax.ARPA>
Date: Sat, 31-Dec-83 14:49:04 EST
Article-I.D.: randvax.1605
Posted: Sat Dec 31 14:49:04 1983
Date-Received: Wed, 4-Jan-84 02:35:09 EST
References: <7025@arizona.UUCP>
Organization: Rand Corp., Santa Monica
Lines: 20

--------
I don't think performance on Joseki situations is a good overall measure
of the skill of a program.  I can imagine a program that does a local
search for tactical problems and life-or-death situations (you didn't
say Fuseki, so I don't have to look at interactions with other corners)
and has stored all the lines in Ishida's Joseki dictionary (or some more
massive work).  That's all reasonable technology from the chess programming
world.  The Zobrist and Ryder programs each played a credible opening.

However, none of the hacks we chess programmers found to "cook" chess will
work in the middle game.  In chess you can make up for bad strategic
thinking with superior tactics, but that won't hack it in Go.  I'll go
further:  I bet I could write a program that would play Joseki at a 2 kyu
(amateur) level (i.e. as well as I could), but we need all new hacks to
achieve even 10 kyu in the middle game because the strategic concepts
aren't well understood. (Ever try to tell a program what "sabaki" means?)

		Jim Gillogly    I/ /
		randvax!jim     I_/
		jim@rand-unix   I