Documentation for the GNU Go Project Edition 3.0.0 August, 2001 By Daniel Bump, David Denholm, Jerome Dumonteil, Gunnar Farneb¨ack, Thomas Traber, Tanguy Urvoy, Inge Wallin GNU GO 3.0 Copyright °c 1999, 2000, 2001 Free Software Foundation, Inc. This is Edition 3.0.0 of The GNU Go Project documentation, for the 3.0 version of the GNU GO program. Published by the Free Software Foundation 675 Massachusetts Avenue Cambridge, MA 02139-3309 USA Phone: +1-617-876-3296 Permission is granted to make and distribute verbatim or modified copies of this manual is given provided that the terms of the GNU Free Documentation License (see Section A.2 [GFDL], page 179) are respected. Permission is granted to make and distribute verbatim or modified copies of the program GNU Go is given provided the terms of the GNU General Public License (see Section A.1 [GPL], page 173) are respected. Chapter 1: Introduction 1 1 Introduction This is GNU Go 3.0, a Go program. Development versions of GNU Go may be found at http://www.gnu.org/software/gnugo/devel.html. Contact us at [email protected] if you are interested in helping. 1.1 About GNU Go and this Manual The challenge of Computer Go is not to beat the computer, but to program the computer. In Computer Chess, strong programs are capable of playing at the highest level, even challenging such a player as Garry Kasparov. No Go program even as strong as amateur shodan exists. The challenge is to write such a program. To be sure, existing Go programs are strong enough to be interesting as opponents, and the hope exists that some day soon a truly strong program can be written. GNU Go is getting stronger. For one thing, we’ve paid a lot of attention to life and death. GNU Go 3.0 can consistently give GNU Go 2.6 a four stone handicap. In a four stone game against GNU Go 2.6, GNU Go 3.0 very often kills a group. Until now, Go programs have always been distributed as binaries only. The algorithms in these proprietary programs are secret. No-one but the programmer can examine them to admire or criticise. As a consequence, anyone who wished to work on a Go program usually had to start from scratch. This may be one reason that Go programs have not reached a higher level of play. Unlike most Go programs, GNU Go is Free Software. Its algorithms and source code are open and documented. They are free for any one to inspect or enhance. We hope this freedom will give GNU Go’s descendents a certain competetive advantage. Here is GNU Go’s Manual. There are doubtless inaccuracies. The ultimate documenta- tion is in the commented source code itself. The first three chapters of this manual are for the general user. Chapter 3 is the User’s Guide. The rest of the book is for programmers, or persons curious about how GNU Go works. Chapter 4 is a general overview of the engine. Chapter 5 introduces various tools for looking into the GNU Go engine and finding out why it makes a certain move, and Chapters 6–7 form a general programmer’s reference to the GNU Go API. The remaining chapters are more detailed explorations of different aspects of GNU Go’s internals. 1.2 Copyrights Copyright 1999, 2000, 2001 by the Free Software Foundation except for the files ‘gmp.c’ and ‘gmp.h’, which are copyrighted by Bill Shubert ([email protected]). All files are under the GNU General Public License (see Section A.1 [GPL], page 173), except ‘gmp.c’, ‘gmp.h’, ‘gtp.c’, ‘gtp.h’, the files ‘interface/html/*’ and ‘win/makefile.win’. The two files ‘gmp.c’ and ‘gmp.h’ were placed in the public domain by William Shubert, their author, and are free for unrestricted use. Chapter 1: Introduction 2 The files ‘gtp.c’ and ‘gtp.h’ are copyright the Free Software Foundation. In the interests of promoting the Go Text Protocol these two files are licensed under a less restrictive license than the GPL and are free for unrestricted use (see Section A.3 [GTP License], page 185). The files ‘interface/html/*’ are not part of GNU Go but are a separate program and are included in the distribution for the convenience of anyone looking for a CGI interface to GNU Go. They were placed in the public domain by their author, Douglas Ridgway, and are free for unrestricted use. The file ‘win/makefile.win’ is also in the public domain and is free for unrestricted use. 1.3 Authors GNU Go maintainers are Daniel Bump and Gunnar Farneb¨ack. GNU Go authors (in chronological order of contribution) are Man Li, Daniel Bump, David Denholm, Gunnar Farneb¨ack, Nils Lohner, Jerome Dumonteil, Tommy Thorn, Nicklas Ekstrand, Inge Wallin, Thomas Traber, Douglas Ridgway, Teun Burgers, Tanguy Urvoy, Thien-Thi Nguyen, Heikki Levanto, Mark Vytlacil, Adriaan van Kessel, Wolfgang Manner, Jens Yllman and Don Dailey. 1.4 Thanks We would like to thank Arthur Britto, Tim Hunt, Piotr Lakomy, Paul Leonard, Jean- Louis Martineau, Andreas Roever and Pierce Wetter for helpful correspondence. Thanks to everyone who stepped on a bug (and sent us a report)! Thanks to Gary Boos, Peter Gucwa, Martijn van der Kooij, Michael Margolis, Trevor Morris, Mans Ullerstam, Don Wagner and Yin Zheng for help with Visual C++. And thanks to Alan Crossman, Stephan Somogyi, Pierce Wetter and Mathias Wagner for help with Macintosh. Special thanks to Ebba Berggren for creating our logo, based on a design by Tanguy Ur- voy and comments by Alan Crossman. The old GNU Go logo was adapted from Jamal Han- nah’s typing GNU: http://www.gnu.org/graphics/atypinggnu.html. Both logos can be found in ‘doc/newlogo.*’ and ‘doc/oldlogo.*’. We would like to thank Stuart Cracraft, Richard Stallman and Man Lung Li for their interest in making this program a part of GNU, William Shubert for writing CGoban and gmp.c, Rene Grothmann for Jago and Erik van Riper and his collaborators for NNGS. 1.5 The GNU Go Task List You can help make GNU Go the best Go program. This is a task-list for anyone who is interested in helping with GNU Go. If you want to work on such a project you should correspond with us until we reach a common vision of how the feature will work! A note about copyright. The Free Software Foundation has the copyright to GNU Go. For this reason, before any code can be accepted as a part of the official release of GNU Go, the Free Software Foundation will want you to sign a copyright assignment. Chapter 1: Introduction 3 Of course you could work on a forked version without signing such a disclaimer. You can also distribute such a forked version of the program so long as you also distribute the source code to your modifications under the GPL (see Section A.1 [GPL], page 173). But if you want your changes to the program to be incorporated into the version we distribute we need you to assign the copyright. Please contact the GNU Go maintainers, Daniel Bump ([email protected]) and Gunnar Farneb¨ack ([email protected]), to get more information and the papers to sign. Below is a list of things YOU could work on. We are already working on some of these tasks, but don’t let that stop you. Please contact us or the person assigned to task for further discussion. 1. Report and fix bugs. Bugs are an important cause of weakness in any Go program! If you can, send us bug FIXES as well as bug reports. If you see some bad behavior, figure out what causes it, and what to do about fixing it. And send us a patch! If you find an interesting bug and cannot tell us how to fix it, we would be happy to have you tell us about it anyway. Send us the sgf file (if possible) and attach other relevant information, such as the GNU Go version number. In cases of assertion failures and segmentation faults we probably want to know what operating system and compiler you were using, in order to determine if the problem is platform dependent. 2. Extend the regression test suites. See the texinfo manual in the doc directory for a description of how to do this. In particular it would be useful with test suites for common life and death problems. Currently second line groups, L groups and the tripod shape are reasonably well covered, but there is for example almost nothing on comb formations, carpenter’s square, and so on. Other areas where test suites would be most welcome are fuseki, tesuji, and endgame. 3. Tune the pattern databases. This is a sort of art. It is not necessary to do any programming to do this since most of the patterns do not require helpers. We would like it if a few more Dan level players would learn this skill. 4. Extend and tune the Joseki database. 5. Rewrite the semeai module The semeai module is vastly in need of improvement. In fact, semeai can probably only be analyzed by reading to discover what backfilling is needed before we can make atari. 6. Write a connection analysis module. The connection analysis is today completely static and has a hard time identifying mutually dependent connections or moves that simultaneously threatens two or more connections. This could be improved by writing a connection reader, which like the owl code uses pattern matching to find a small amount of key moves to try.