[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computer-go: Complexity & SW
>
> > I suspect that if the number of man-years and master involvement
> > invested in go as opposed to chess had been reversed, today we would
> > be seeing computer go programs playing at 3 or 4 dan and computer
> > chess software struggling along with USCF ratings of around 1750.
>
> I suspect this would not at all be the case. As far as I can see
> (which is not very far), the key to "solving" chess has been that it
> can be solved with brute force (or relatively brute quite-much-force).
> It is of course tempting to speculate that something as powerful would
> have been found for go. But so far we don't even know where to look
> for such a solution...
The fraction of total processing power devoted to full-width
searching (brute force) in chess software has been falling for
nearly 25 years. While I would not bet the house on this,
I am 80% sure that most cycles in high-level programs (commercial,
as opposes to student) go to stuff like plausible move determination,
position evaluation, and position representation. All this is exactly
what go programming is about.
The intrinsic complexity of a game -- the number of possible moves,
the number of positions -- has zip to do with the difficulty of making
a reasonably strong program. Humans play games by learning some
number of patterns and then using those patterns to probe the
nature of real positions. When two people play, the one with best set
of patterns wins, usually. This is true regardless of how complex the
game is. If a game has a complexity rating of X, the guy with the
better patterns wins. If the game has a complexity rating of x^100,
the guy with the better patterns wins. How hard God would find the
games is not to the point.
This is how both go and chess programming works: finding a better
set of patterns than those driving the last rev. I see nothing about
chess to lead me to think that the task of building a machine good
enough to beat a chess master is any easier than building one to
beat a 1 dan amateur. (I would agree that a chess program could
conceivably win a game or two against a rank beginner using only 1
or 2 ply searches, which a go program could not, but that isn't
relevant to anything.)
Possibly slightly more processing power should be allocated to full-
width searching in the case of chess, but the distinction would be on
the order of 10% (go) versus 25% (chess) or something like that.
An inconsequential difference.
What matters is that chess has attracted hundreds of man-years
more development time than go, and that advantage has proved
overwhelming, as one would expect it would.
.
>
> > If someone was to offer a a million dollar prize for a program that
> > could play 1 dan (amateur) I'm sure it would be delivered in two or
> > three years, regardless of how complex GO is in any ultimate sense.
>
> I think the Ing price was a considerable amount of money (something in
> that neighbourhod), and it was available for several years. Its
> requirement was to beat a junior champion (or Taiwan?), corresponding
> to (say) 4 dan amateur. The prize expired this year, but it had been
> up for quite some time. I don't think anyone seriously believed it
> coule be claimed. (Someone with all the facts, please fill in and
> correct my mistakes!)
>
> No, I believe that go is fundamentally more difficult to program than
> chess. At least on today's computers and todays computer science...
> That is why it is such a challenge!
>
>
> Regards
> Heikki
>
>
>
>
>
> --
> Heikki Levanto LSD Levanto Software Development heikki@xxxxxxxxxxxxxxxxx
> "In Murphy we Turst"
>
>
www.pobox.com/~fhapgood