Re: computer-go: FPGA

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

Very well put and I agree.

Don 


   From: "Mark Boon" <tesuji@xxxxxxxxxxxxxxxxx>
   References: <200008310422.AAA13851@xxxxxxxxxxxxxxxxx>
   Date: Thu, 31 Aug 2000 10:43:04 +0200
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   X-Priority: 3
   X-MSMail-Priority: Normal
   X-Mailer: Microsoft Outlook Express 5.00.2314.1300
   X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
   Sender: owner-computer-go@xxxxxxxxxxxxxxxxx
   Precedence: bulk
   Reply-To: computer-go@xxxxxxxxxxxxxxxxx
   Content-Type: text/plain;
	   charset="iso-8859-1"
   Content-Length: 3027


   ----- Original Message -----
   From: Don Dailey <drd@xxxxxxxxxxxxxxxxx>
   To: <computer-go@xxxxxxxxxxxxxxxxx>
   Sent: Thursday, August 31, 2000 6:22 AM
   Subject: Re: computer-go: FPGA


   >
   > As far as  lookahead  is concerned, it takes   a lot of  power to look
   > ahead a single move in go.  So I'm not locked into the idea that there
   > must  be  a search  based  solution.  But   I don't want  to make  any
   > assumptions either, this is what hurt computer chess for a while.
   >
   >
   > Don
   >

   You definitely have a point, and I also think in Go one shouldn't try to
   think in terms of reading more plies. Each increase in power of computers by
   an order of magnitude make it possible to conceive solutions that were out
   of the question before. For example, most programs use (hard-coded) rules
   and patterns for a large variety of things. I'm thinking of eye-space,
   connections, etc. These rules provide a fast and easy way to give a rough
   result, but they're not very accurate and (more importantly) not very
   flexible. For the current level of the program that's not a problem, but it
   becomes a ball and chain later on because they provide a fixed capability
   that is difficult to replace. This is probably the main reason why the
   development of Go programs seems to have stagnated. If I were to design a
   computer-Go program now, I would probably replace many of those parts by
   something that uses lookahead to compute them.

   In general this holds for any use of patterns. Most Go programs heavily rely
   on them for the majority of the things they do. That is very understandable,
   since for many things it would be hard to define and program the principles
   behind the pattern. But it's obvious that just using the patterns lacks real
   understanding of the problem at hand and will severely limit what it can do
   with them. And it certainly wouldn't improve with more computing power. So a
   purists ideal would be to make a program that initially doesn't have any
   patterns at all. Everything should be computed from first principles. Next,
   one can use patterns to speed things up, say for move ordering. But that's
   all they should be used for, providing a guide to find the desired result
   faster, not to cover up some missing capability.

   For the next step, the focus can then be on computer-generated patterns. One
   could think of making a program that uses a genetic algorithm to produce
   patterns. If a newly generated pattern improves the speed with which it
   finds the solution to some known problem it will be allowed to proliferate.
   For the time being, these patterns can still be human-generated, as long as
   the pattern and their function are properly separated. If pattern-learning
   technigues then later become more feasible they can be used instead. The
   power of this idea must be obvious, as the level of the computer can
   increase this way even without having increasingly more computer-power. Just
   let the program run at night, breeding patterns. No, correct that, let all
   the idle computers in the world run at night...

       Mark