From 76621704d0e2577f845e14183c05ca9480b1d6be Mon Sep 17 00:00:00 2001 From: Petr Baudis Date: Sat, 16 Apr 2011 03:53:52 +0200 Subject: [PATCH] README: Grammar polishing, rewording and extending the text --- HACKING | 3 ++- README | 95 ++++++++++++++++++++++++++++++++++++----------------------------- 2 files changed, 55 insertions(+), 43 deletions(-) diff --git a/HACKING b/HACKING index 4fb7e35..655ea49 100644 --- a/HACKING +++ b/HACKING @@ -80,7 +80,8 @@ Pachi consists of the following components: UCT architecture ================ -The UCT engine has non-trivial structure by itself: +The UCT engine (the proper name should be MCTS as it does not have that +much common with classic UCT now) has non-trivial structure by itself: +-------------+ +-----+ +-------------------+ | node policy | -- | UCT | --- | node prior-hinter | diff --git a/README b/README index 55e92c0..996b54b 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -Pachi is two things: a simple modular framework for robots playing +Pachi can refer to: a simple modular framework for programs playing the game of Go/Weiqi/Baduk, and a reasonably strong engine built within this framework. @@ -6,38 +6,58 @@ within this framework. Engine ------ +The default engine plays by Chinese rules and should be about +3d KGS strength on 9x9. On 19x19, it might be about KGS 2k, assuming +reasonable hardware, e.g. two-core Athlon64 machine. On a higher-end +(e.g. six-way Intel i7) machine, it can hold a solid KGS 1d rank. +When using a large cluster (64 machines, 20 cores each), it will +maintain KGS 3d and has won a 7-stone handicap against Zhou Junxun 9p. + By default, Pachi currently uses the UCT engine that combines -monte-carlo approach with tree search; UCB1AMAF tree policy using +Monte Carlo approach with tree search; UCB1AMAF tree policy using the RAVE method is used for tree search, while the Moggy playout policy using 3x3 patterns and various tactical checks is used for -the random Monte-Carlo playouts. - -The default engine plays by Chinese rules and should be about -2d KGS strength on 9x9. On 19x19, it might be about KGS 4k. Of couse, -this assumes reasonable hardware, e.g. four-threaded Core2 machine. +the semi-random Monte Carlo playouts. -At the same time, various other approaches and tricks are being tried -and minor improvements have been achieved; they are enabled when they -give an universal playing strength boosts. +At the same time, we keep trying a wide variety of other approaches +and enhancements. Pachi is an active research platform and quite a few +improvements have been already achieved. We rigorously play-test new +features and enable them by default only when they give a universal +strength boost. By default, Pachi will run on a single CPU core, taking up to 3GiB of memory, not pondering, etc. You can adjust these parameters by passing it extra command-line options: - ./zzgo -t _1200 threads=8,max_tree_size=500,fast_alloc + ./zzgo -t _1200 threads=8,max_tree_size=500,fast_alloc,pondering This will make Pachi play with time settings 20:00 S.D. (unless it gets told otherwise over GTP), with 8 threads, taking up to 500MiB of memory (+ several tens MiB as a constant overhead). 'fast_alloc' is just a good idea to do in case of memory-sensitive runs (will become -default soon). +default soon). 'pondering' will make Pachi keep thinking during the +opponent's turn. -For now, there is no comprehensive documentation, but you can get -a pretty good idea by looking at the uct_state_init() function in -uct/uct.c - you will find the list of UCT engine options there, each +For now, there is no comprehensive documentation of options, but you +can get a pretty good idea by looking at the uct_state_init() function +in uct/uct.c - you will find the list of UCT engine options there, each with a description. + +Except UCT, Pachi supports a simple idiotbot-like engine and an example +treeless MonteCarlo-player. The MonteCarlo simulation ("playout") +policies are also pluggable, by default we use the one that makes use of +heavy domain knowledge. + +Other special engines are also provided: +* a "distributed" engine for cluster play; the description at the top of + distributed/distributed.c should provide all the guidance +* a simple "replay" engine that will simply play moves according + to the playout policy suggestions +* few other purely for development usage + + Pachi can be used as a test opponent for development of other go-playing programs. For example, to get the "plainest UCT" player, use: @@ -60,24 +80,14 @@ that board_symmetry_update() has goto break_symmetry at the beginning and board_clear has board->symmetry.type = SYM_NONE. -Except UCT, Pachi supports a simple idiotbot-like engine and an example -treeless MonteCarlo-player. The MonteCarlo simulation ("playout") -policies are also pluggable, by default we use one that makes use of -heavy domain knowledge. - -Special engines are also provided for development support: -* a simple "replay" engine that will simply play moves according - to the playout policy suggestions - - Analysis -------- -Pachi can also help you analyze your games, by being able to provide +Pachi can also help you analyze your games by being able to provide its opinion on various positions. The user interface is very rudimentary, but the ability is certainly there. -There are currently two Pachi interfaces for this purpose. One +There are currently two Pachi interfaces provided for this purpose. One possibility is to evaluate all moves within a given game and show how the winrates for both players evolved - i.e. who was winning at which game stage. This is implemented using the `tools/sgf-analyse.pl` script. @@ -119,14 +129,16 @@ and most yose situations, expect a lot of noise. Framework --------- -The aim of the framework is to make it easy to plug your engine -to the common infrastructure and implement your ideas while +The aim of the software framework is to make it easy to plug your +engine to the common infrastructure and implement your ideas while minimalizing the overhead of implementing the GTP, speed-optimized -board tools, etc. Also, there are premade random playout and UCT -tree engines, so that you can directly tweak only particular policies. -The infrastructure is pretty fast and it should be quite easy -to extend it to provide more facilities for your engine (but it should -be at the same time kept as simple as possible). +board implementation, etc. Also, there are premade random playout +and UCT tree engines, so that you can directly tweak only particular +policies. The infrastructure is pretty fast and it should be quite +easy for you (or us) to extend it to provide more facilities for +your engine. + +See the HACKING file for a more detailed developer's view of Pachi. Licence @@ -153,18 +165,17 @@ To build Pachi, simply type: make -Built zzgo binary (named that way from historical reasons) in the current -directory is a GTP client; use your favorite Go client to connect to it -(generally it should be possible to use it in place of GNU Go; the -command-line usage is however different), or use kgsGtp to connect to KGS; -DO NOT make it accessible directly to enemy users since the parser is -not secure - see the HACKING file for details. +The resulting binary program `zzgo` (named that way from historical +reasons) is a GTP client; connect to it using your favorite Go program +interface (e.g. gogui or qgo), or use kgsGtp to connect it to KGS. +(DO NOT make the GTP interface accessible directly to untrusted users +since the parser is not secure - see the HACKING file for details.) The zzgo binary can take many parameters, as well as the particular engine being used; the defaults should be fine for initial usage, -you will have to consult the sources for fine-tuning the parameters. +see above for some tips. -In case you hit compilation issues (e.g. when building on a MacOS/X) +In case you hit compilation issues (e.g. when building on MacOS/X) or want to change the build configuration, check the user configurable section at the top of the Makefile. -- 2.11.4.GIT