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.

"Monte Carlo Go" by Bernd Brügmann

I've just read "Monte Carlo Go" by Bernd Brügmann, which uses simulated annealing to evaluate positions when playing go. The system is not particularly effective, mainly because of the very slow cooling required to play well.

I know it goes completely against all the theory behind the solution, but I can't help but think that maybe one could do better than random plays. I particular, it seems to me that the best ranked positions from not n are likely to at least be candidates for move n+1.

Bayesian Pattern Ranking for Move Prediction in the Game of Go

Bayesian Pattern Ranking for Move Prediction in the Game of Go by David Stern, Ralf Herbrich and Thore Graepel at Cambridge / Microsoft uses nested patterns with learnt priority (rank) to "obtain a probability distribution for professional play over legal moves in a given position." Trained using a corpus of 20000 professional games they also discuss building a million game corpus of variable-level games (presumably games played on internet go servers?).

It seems to me that the problem they're setting out to solve isn't the one they need to solve―at the end of the day generating reasonable moves is the goal, and pro moves are only an approximation. There is also the problem that the system assumes that the board positions and the opponents' moves are reasonable. There were some clear attacks against early computer chess players which worked by playing unreasonable moves to get out of the opening book.

Another issue is the shape of he pattern. The patterns are (effectively) circular, whereas there are many, many, go proverbs suggesting that they should be biased towards the board edge (where territory is to be made) over the center.

Thore Graepel's Home Page

GoGui ?

A recent comment suggested that I use GoGui as the starting point for my implementation.

GoGui is a GTP <==> GUI toolkit implemented in Java and licenced under the GPL. Reusing someone elses code has great appeal, of course, but it's not entirely clear whether it'll do what I want it to do. In particular it's not clear at first glance whether the model of a game and a move is sufficiently flexible.

I'll have to check it out...

My Friday Night Files

A great site by Jan van Rongen. It's not new, just new to me... It's amazing the different takes people have on the same game...

An implementation plan

If I'm going to write a computer go player, I need a plan. Plans drawn at this stage are inevitably only approximations, but here's my current plan:

• Infrastructure – the framework to hang the rest on
  • SGF parser
  • SGF writer (simpler that the parser since it only needs to handle the properties I'm actually using)
  • a graphic goban (so i can play the program)
  • GTP client (so I can play my program against other people and other programs)
  • GTP engine (so i can organise play-offs)
  • test suite (so ease debugging)
• Opening: a classical opening book, assembled from pro and senior-amateur games. Also code to handle symmetry.
• Mid-game: a genetic algorithm prioritising a list of relatively complex template patterns.
• End-game: a theorem prover, perhaps along the lines of gotools, but with incremental additions of knowledge to the database as positions are proven safe/unsafe.

One advantage of have separate beginning, middle and end games is that I can develop, test and debug them separately.

GNU Go wins

For the first time ever I won a couple of games against GNU Go with only 2 stones handicap. Of course, now I've boasted about it I'll have a run of bad luck.

I'm certainly getting better, but I'm not entirely sure which of my go-related activities is having the big effect, whether it's playing in person (which I'm doing once every week or two at a local go club), playing against bots (mainly GNU Go and igowin), studing go gome (which I haven't done much of for a couple of weeks), playing against real people (maybe two games twice a week) or even reading computer go related papers and planning my own system. Probably a combination of all of them.

GNU Go: http://www.gnu.org/software/gnugo/gnugo.html

igowin / Many faces of go http://www.netcom.com/~fotland/manyfaces.html

Computer Go: an AI Oriented Survey

I've just finished "Computer Go an AI Oriented Survey" by Bruno Bouzy and Tristan Cazenave. A very long survey, packed with so many details that I suspect I'll need to reread it in a week or two. As well as surveying a wide range of techniques used to tackle go, it also discusses some of the representations used by specific implementations.

There were quite a few interesting pieces about the end game, and I shall have to read some of the primary papers (which all seem to be listed in the very extensive bibliography).

I was surprised both at the lack of genetic algorithm approaches used with patterns (as opposed to neural networks) mentioned and also at the fact that all researchers seem to be opting for light weight patterns rather than complex patterns, both of which seem promising to me.

The final paragraph contains a very interesting explanation for the wide gap in perceived strength of go programs: that human player can learn the faults of a computer go player over a series of games, and systematically exploit them. Whereas a human player quickly learns in at least a shallow sense to fix faults as they are repeated exploited (or at least alters play to fight their exploitation), computer go players are static and cannot adapt themselves.

Computer Go an AI Oriented Survey: http://www.ai.univ-paris8.fr/~cazenave/CG-AISurvey.pdf

Home page for Bruno Bouzy: http://www.math-info.univ-paris5.fr/~bouzy/Go.html

Home page for Tristan Cazenave: http://www.ai.univ-paris8.fr/~cazenave/

An Improved Safety Solver for Computer Go

I've just read "an improved safety solver for computer go" by Xiaozhen Niu and Martin Müller, describing their work on the program 'explorer.' Focusing entirely on the end game, it seeks to prove that safe groups are indeed safe. Building on the work of Benson (I _really_ must track down a copy of that paper), and develop new algorithms for complex regions using merging to join them together. Very interesting stuff. I think part of the reason I find it appealing is that it is proof based rather the heuristic.

Their methodology seems a little unusual, in that they are building what is essentially a theorem proving tool, but only trialling it on positive examples, which seems little unsafe. Maybe I missed something or they discuss it in a different paper.

They introduce their algorithms in pseudo-code, which is convenient.

This kind of approach seems very appealing to me, perhaps because such non-heuristic work seems more solid than other work I've read, a better base to build upon.

The Computer Go Group at Univresity of Alberta: http://www.cs.ualberta.ca/~games/go/

There is death in the hane

This is a proverb I seem to regularly loose sight of, before being re-taught by various opponents, both human and robotic (igowin seems particularly good at teaching me this lesson). Hopefully by naming my account after the proverb, I'll stand some chance of remembering it.

I suspect that my problem is a symptom of my difficulty drawing a line between strategy and tactics, too often I play an attachment without really considering whether I mean to start a fight and my opponent immediately answers with a hane and I suffer a loss. The loss isn't necessarily the stone I attached with, of course, but it's there somewhere.

igowin / Many faces of go: http://www.netcom.com/~fotland/manyfaces.html

Some thoughts on rules

I've been thinking about rules and rulesets in go.

A plurality of rulesets is unfortunate, in that it significant complicates the problem, giving several targets to aim for when building a computer go player. Fortunately few, if any, computer go players are sufficiently advanced for differences between rulesets to become a significant factor. Also, the fact that there are several rulesets potential gives computer go researchers and others choices about which rulesets to use.

Many computer go players choose to ignore certain rules, including avoid capture by seki and even ko. Noting but not modelling certain aspects of the problem is of course a classic feature of decomposition-based problem solving styles used in computer science and mathematics (and one which I'm sure my system will eventually have, once I have a system to have such features).

Personally I'm a fan of the New Zealand rules, because: (a) they're clearly stated; (b) they are stated in a way that suits my current purposes (i.e. in a mathematical way); (c) they don't have exceptions; (d) they don't have a history of change and (e) they are widely and correctly understood (perhaps largely because of the previous reasons). On the other hand, they exist in a cultural wasteland, there is a dearth of pro-level games on record using the New Zealand ruleset and none of the "famous" games have been played using them. This is not a serious issue, of course, if one is learning oneself, but if one is building a computer go player there are a number of uses for a larger corpus of pro-level games---pattern extraction, statistical comparisons and finding example end-games. It is also less of an issue if one is evolving (or proving) a system from first principals.

The New Zealand ruleset: http://homepages.ihug.co.nz/~barryp/rules.htm