[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computer-go: FPGA
----- 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