[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is GNU Go 3.6, a Go program. Development versions of GNU Go may be found at http://www.gnu.org/software/gnugo/devel.html. Contact us at gnugo@gnu.org if you are interested in helping.
1.1 About GNU Go and this Manual 1.2 Copyrights Copyright 1.3 Authors The Authors of GNU Go 1.4 Thanks Acknowledgements 1.5 The GNU Go Task List The GNU Go Task list
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. GNU Go 3.6 plays at about the level of 9 kyu.
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 documentation 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.
Copyright 1999, 2000, 2001, 2002, 2003 and 2004 by the Free Software Foundation except as noted below.
All files are under the GNU General Public License (see section A.1 GNU GENERAL PUBLIC LICENSE), except `gmp.c', `gmp.h', `gtp.c', `gtp.h', the files `interface/html/*' and `win/makefile.win'.
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 The Go Text Protocol License).
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.
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 files `regression/games/golois/*sgf' are copyright Tristan Cazenave and are included with his permission.
The SGF files in `regression/games/handtalk/' are copyright Jessie Annala and are used with permission.
The SGF files in `regression/games/mertin13x13/' are copyright Stefan Mertin and are used with permission.
The remaining SGF files are either copyright by the FSF or are in the public domain.
GNU Go maintainers are Daniel Bump, Gunnar Farneback and Arend Bayer. GNU Go authors (in chronological order of contribution) are Man Li, Wayne Iba, Daniel Bump, David Denholm, Gunnar Farnebäck, 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, Don Dailey, Måns Ullerstam, Arend Bayer, Trevor Morris, Evan Berggren Daniel, Fernando Portela, Paul Pogonyshev, S.P. Lee and Stephane Nicolet and Martin Holters.
We would like to thank Arthur Britto, David Doshay, Tim Hunt, Matthias Krings, 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, Måns Ullerstam, Don Wagner and Yin Zheng for help with Visual C++.
Thanks to Alan Crossman, Stephan Somogyi, Pierce Wetter and Mathias Wagner for help with Macintosh. And thanks to Marco Scheurer and Shigeru Mabuchi for helping us find various problems.
Thanks to Jessie Annala for the Handtalk games.
Special thanks to Ebba Berggren for creating our logo, based on a design by Tanguy Urvoy and comments by Alan Crossman. The old GNU Go logo was adapted from Jamal Hannah'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.
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.
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 GNU GENERAL PUBLIC LICENSE). 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 (bump@sporadic.stanford.edu) and Gunnar Farnebäck (gunnar@lysator.liu.se), 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.
These issues are of tactical nature, i.e. they concern some specific feature or the infrastructure of the engine. Some of these are quiet small, maybe doable in a day for an experienced GNU Go programmer. They might also be useful project to start with for a new project member. Some of them are bigger and demand a deeper knowledge of the engine internals. The issues are presented here in an approximate order of perceived difficulty.
play_move()
and in a variant
of is_legal()
.
dragon[]
and dragon2[]
. The dragon2 array only have one entry per dragon, in
contrast to the dragon array where all the data is stored once for every
intersection of the board. Complete the conversion of eye_data,
half_eye_data, worm and dragon to use the same structure as the dragon2 array.
These issues are strategic in nature. They will help us to improve the playing strength of the program and/or enhance certain aspects of it.
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.
These are under constant revision. Tuning them 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.
It might be very useful to implement a semi-automatic way of doing this. The current method based on sgf files become difficult to maintain with existing tools.
The combination module of today only finds combinations of threats to capture enemy groups. A more useful combination module would e.g. find combinations of threats to capture a group or enter opponent territory. It would also be strong enough to find combinations of strategic moves and more indirect threats (a threat to a threat). Possibly it could combine threats in AND-OR trees (DAGs?) that could be searched using ordinary tree search algorithms. (Revision of `combination.c' is underway.)
GNU Go is reasonably accurate when it comes to tactical reading, but not always very fast. The main problem is that too many ineffective moves are tested, leading to strange variations that shouldn't need consideration. To improve one could refine the move generation heuristics in the reading. Also, one should implement some more of the standard tree search optimizations used in alpha-beta readers.
This might take into account number of eyes / half eyes, moyo in corners, moyo along the edge, moyo in the center, proximity to living friendly groups, weak opponent groups etc. It is of particular interest to be able to accurately determine how a move affects the safety of all groups on the board.
These are some ideas that have been floated on the mailing list. Some of them are down-to-earth, and some are just blue sky ramblings. They are presented here for inspiration.
A start is being made with GoThic, a goban widget based on the QT toolkit. This is linked from the GNU Go development web page on gnu.org. Other starts have been made based on GTK, but so far nothing more than a start has been attempted.
This would make it much easier for non-programmers to improve the strength of GNU Go. It could also be used as a debugging tool for the programmers. This project has the GUI as a prerequisite. The challenge here is not to make a tool which makes it easier to create patterns but to make it easier to overview and maintain the database.
This would probably be very slow and could only read 2 or 3 moves ahead. Still it could find fatal errors and improve the moves that GNU Go makes.
A strategic module that identifies high-level goals and then gives these goals to the rest of the engine. It should be able to identify if we are ahead in territory or thickness, if we should play safe or if we should play daringly (e.g. if behind). It should also identify weak areas where we can attack or where we should defend. Maybe this module doesn't have to be written in C. Maybe PROLOG, LISP or some other AI language would be better.
Such styles could be 'play for territory', 'play aggressively', 'play tricky moves (hamete)', and so on. It could be used to present human users with different kinds of opponents or to tell GNU Go how to play certain computer opponents in tournaments.
To be really useful this would have to deal with early endgame positions.
Fuseki tuning by hand is difficult. I'd like to encourage people who are interested in doing machine learning experiments with GNU Go work with the fuseki. This may be one of the areas with most potential for substantial and reasonably quick improvements.
Create a paradigm for handling other types of ko (approach move ko, multi-step ko, etc) and then write code that handles them.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |