Playing igowin / Many Faces of Go

So I downloaded and played igowin when I first started looking at computer go (about when I started this blog). For a time I played the little 9x9 regularly, maybe a couple of times most days for maybe 6 months. then I odn't play it for maybe eight months, try it again (the same installed version), and I'm two stones stronger against it, without playing go in the intervening period. I suspect that I'd slipped into dreadful point-and-click-without-thinking habits when I was playing it regularly.

Silver Star 2006 from North Korea the best computer-go program?

The Korea Times has some very strong claims for the Silver Star 2006. I wonder whether it comes with a an English localisation? Somehow I suspect not...

Japanese Rules of Go

I've been giving some thought recently to what a finite state machine for the Japanese rules of go would look like. The more I think about it, the more complex encoding the full rules will be.

Which isn't to say that trying to build an FSM is necessarily a bad thing...

gobase

GoBase is a website run by Dutch go player Jan van der Steen. In comprises three main parts, a large and actively maintained database of games (including even the minor rounds of current contests), a set of life and death problems and news stories taken from a diverse range of places, including the computer-go mailing lists, recent contest results and articles.

Personally I find that the articles are the best part of the site, and recent ones such as Pieter Mioch's world amateur go championships give an insight into the go world that game results and life and death problems (both available elsewhere) don't.

Burlington Free Press Go Article

A current article in the Burlington Free Press describes aspects of the game, including some of the historical roots and some of the local aspects.

So much for the GNU Go wins

After a couple of weeks not playing go I've now dropped 3-4 stones against GNU go. On the positive side I'm now playing even with the free version of igowin on 9x9 boards, which is an improvement of about 2 stones.

About problems in generalizing a tsumego program to open positions (1996) and Optimizing GoTools' Search Heuristic using Genetic Algorithms (2004).

The first paper is literally a statement of problems, whereas the second reports on using GAs to tune the computationally expensive answer to the problem, i.e. picking values for using in the heuristics.

The results of using the GA were actually quite reassuring. Improvements of 8-20% over the hand-tuned solution are reported.

Methods for Competitive Co-evolution: Finding Opponents Worth Beating

This is an interesting paper about the challenges of finding a good evaluation function for genetic algorithms. They use GAs to evolve a two populations, tested against each other. Interestingly there is this quote:

For Nim, a perfect solution can be found after about 150 million games with parameters tuned well. Typically, success in the competition for Nim is much more balanced between the two population during most of the tun. The first population spends much time trying strategies which employ an incorrect first move. Such strategies can never be perfect, but can be difficult to beat if most other moves had been optimised. Eventually, a strategy employing a correct first move is optimized to the point of perfection.

Evolving a player for go could avoid this problem by using randomised starting points for a significant number of games. This would encourage the evolution of strategies that are truly good in the middle and end game, irrespective of their performance in the opening, thus splitting the problem in two. Maybe random games from an archive could be used as starting positions for solving the end game, splitting it into three?

A new protocol for computer-go ?

As mentioned previously I've been thinking about a go protocol, a protocol that is suitable to use everywhere GTP is plus:

• Ruleset negotiation
• Handicap and komi negotiation
• Extendable (extensible for you Americans) for unusual boards (large sizes and so forth)
• End-game negotiation for the liveness of groups (and thus score)

The whole concept of "negotiation" is, of course, foreign to GTP, in which there is a controller (which as the name implies is in control) and an engine (which has almost no control).

The other issue is that computers, having effectively infinite patience equalled only by their stupidity, are not very good at negotiation. The issue of end-game negotiation is only of the perennially verbose yet unresolved subjects on the computer-go mailing list (see for example this thread). This undermines my confidence that computer-go programs, left to themselves, will ever reach a consensus.

If they can't be left to themselves, then suddenly we don't have a two-party protocol, we have a multi-way protocol, which opens up new vistas, in terms of complexity and implementation effort…

... a complete can of worms.

Go Text Protocol

I've been reading the GTP (Go Text Protocol) spec (version 2, draft 1, July 2002). It's a tool that everyone seems to use to communicate with computer-go engines, whether it's GUIs communicating with engines, servers communicating with engines or scripts that play engines against each other (twogtp and friends).

I've been thinking about why it's done so well and is so widely implemented:

1. It has a clear objective (communication between a master and a computer-go engine)
2. It does what it needs and as little as possible else (unnecessary commands in the reference implementation as namespaced out)
3. It is as simple as possible
4. It leaves out the issue of haggling over rules (Chinese/Japanese/New Zealand/etc), komi and handicapping.
5. It leaves out the issue of arranging who is to play
6. There is a widely available, high quality reference implementation (GNU Go) which is useful in itself
7. It is clearly better than the protocol it replaced (GMP)

These appear have completely outweighed the fact that the sections seven and nine of the spec are completely empty and the last six commands are completely undocumented. It also doesn't handle boards above 25x25, to be fair, few if any other programs do either, mainly because the standard notation breaks down when the letters A-H and J-Z are all taken (I is not used).

This got me to thinking whether it might not be possible to define a protocol that covered a broader range of problems.