Solving Go

   

Solving Go

Go is finite, and so it can be "solved." That is, one or more "best games" can be found by looking at every possible game.

However, we don't have enough time/computing power to realistically look at every game, so this discussion is purely academic. Our goal is a time estimate, as large as that may be.

Table of contents Index of sub-pages

Distributed Computing

We have Seti@home and other massive distributed computing? projects, why not SolvingGo@Home?

Deja Vu?

I know this has been discussed at least once on SL and probably once everywhere go players gather.

It has. See solving go on small boards (5 by 5 is solved) and Number of Possible Outcomes of a Game (after 32 moves on 19 by 19, number of possible games exceeds number of atoms in universe). Pashley

Also Possible number of go games.

I would just like to come up with a time estimate. This estimate may be: two million years, and I would not be surprised.

Alex: I think two million years is on the low side, probably by several dozen orders of magnitude. For number of possible games, you're probably going to end up with something related to the permutations of legal board positions, which is itself an insanely large number, which makes the number of possible games an insanely, insanely large number.

Time Estimate

First, how many games are legal games of Go? Let this number be L, for Legal.

Second, what portion of legal games are reasonable? This number is the most difficult to estimate. Let this number be R. Let R be a decimal number from 0 to 1, expressing percentage.

Third, how quickly can a computer evaluate a finished game and determine it's outcome? This number will be relatively constant. Let's use E, for evaluation.

Fourth, how quickly can a computer generate a reasonable game? This is difficult to estimate, but should be relatively constant. Let's use G, for generate.

Finally, how many users will donate their computers, and for how long? Let U be users, and T be hours/day.

U*T gives us hours per day of computer time.

L*R gives us how many games we must evaluate.

(G+E)(L*R) gives us the total computer-time for the project. Let's measure this in hours, as we measure U and T.

Time Estimate in days = ( ( G + E ) * ( L * R ) ) / ( U * T )

Values

Computer task times

These two "constants" vary a good deal depending on the speed of the computer used, but most people have computers of similar speed. Most people probably have at least Pentium 3.

Let's measure G and E with hours, as with U and T. Just to keep it simple.

G = 0.0005 to 0.00001 hours

Generating the game. Different approaches could be taken. Most likely, dozens to hundreds of games could be generated per second.

E = 0.00001 hours

Evaluating the score. Very quick for a computer. Less than a hundreth of a second.

Games

L = ?

Maximum number of legal positions is 3^361*362 (see discussion)

Note that the question 'how many legal positions' does not equal 'How many legal games'

R = ?

This is the most difficult to estimate. I welcome your thoughts.

For example, we could specify "only games with first moves in corners" or "only games with first moves in corners OR approaching other corners" These two specifications eliminate a huge number of games (and yet leave a ridiculous number)

We can't really say "only games matching a fuseki played by a pro" because pros could have failed to play the best fuseki yet.

Likewise, we can't really restrict by joseki.

Users

U = 10,000

As few as one thousand, but with the East, maybe many more. Maybe as many as fifty thousand, but probably more like ten thousand.

T = 3 hours / day

Some users will give 24 hours of CPU time. Some will only leave it on at night. Some will only run it as a screen-saver and will turn their computers off at night. Unfortunately, the last category will be the largest.

Uncertainty analysis

These numbers obviously involve a lot of guesswork, so any result will have a large uncertainty.

A more formal uncertainty analysis should wait until we have better numbers.

Discussion

Thank you for taking the time to read this. I am sure it will generate some discussion. Please concentrate on finding better estimates for our variables, especially R.


Author: Jared


This is a copy of the living page "Solving Go" at Sensei's Library.
(OC) 2007 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About