Solving Go

   

This page is poorly organized and needs wiki master editing.


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, on most board sizes 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

Boards for which Go is solved

Go has been solved for boards up to 5x5, where the number of variations is managable enough to let the computer go through all of them in reasonable time.

For 7x7, a group of strong players have, with help from the computer, tried to find perfect play. They claim to have looked at all reasonable variations, but of course not at all variations. Thus 7x7 is not truly solved in the way that is meant on this page.

Spectrum article

The IEEE (Institute of Electrical and Electronic Engineers) publishes a journal called Spectrum. An October 2007, article titled [ext] Cracking Go by hardware and chip designer Feng-Hsiung Hsu PhD. that designed Deep Blue, the chess computer that beat World Chess Champion Garry Kasparov. Hsu stated in the article Nevertheless, I believe that a world-champion-level Go machine can be built within 10 years, based upon the same method of intensive analysis--brute force, basically--that Deep Blue employed for chess. In the article, Dr. Hsu does not discuss these characteristics, among others, that distinguish Go from Chess:

  1. the lack of a whole board opening book. Opening books played a crucial role in Deep Blue.
  2. the consequences of a local fight upon other fights and the global position. Chess is essentially a single local fight.
  3. the lack of a reasonable whole board evaluation function.

Dr. Hsu mentions two challenges the effort faces:

  1. the first problem is the tree of analysis.
  2. the second problem is the evaluation of the end positions.

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 = between 10^(10^48) and 10^(10^171) (according to [ext] research by [ext] Tromp & Farnebäck)

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.

Herman Hiddema: For a rough estimate, lets make some assumptions:

  1. In any position, there are (on average) 10 reasonable moves.
  2. An average game lasts for 200 moves.

Given these assumptions, the number of reasonable games is in the order of 10^200

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) 2009 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About