A fairly strong Go/Baduk/Weiqi playing program
C Perl C++ Shell Makefile
Latest commit 1311539 Aug 5, 2016 @pasky committed on GitHub Merge pull request #53 from lemonsqueeze/seki_sar_fix
Selfatari fix
Permalink
Failed to load latest commit information.
distributed add attribute noreturn to thread callbacks Apr 5, 2016
joseki joseki_done(): fix memleak, free jd->patterns[].moves Jul 10, 2015
media media: Add two pictures of Pachi; let's not neglect its personality! Apr 16, 2011
montecarlo replay, montecarlo: engine_done May 1, 2016
patternplay Resolving compiler warnings on gcc 4.7 Jul 16, 2012
patternscan patternscan: Fix crash when only a single game (or small) is fed in Mar 21, 2012
playout moggy seki: always defend big groups + eyefill atari fix Jul 19, 2016
random Eschew Surplusage: e->name -Engine Jan 14, 2012
replay playout: free policy state (b->ps) at board destroy time Jul 19, 2016
t-play autotest: Fix gogui handicap patch link Feb 3, 2016
t-predict t-predict: test components prediction rates May 1, 2016
t-regress dead stones: add own unclear dead groups if it doesn't change the out… Jul 4, 2016
t-unit moggy seki: always defend big groups + eyefill atari fix Jul 19, 2016
tactics selfatari.c: reverted is_bad_selfatari() changes, was better before. Aug 3, 2016
tools tools: scripts to convert board diagrams from board_print() to t-unit… Jul 11, 2016
uct prior: try not to prune useful ladders, Jul 14, 2016
.gitignore Add MSYS2_64 switch in Makefile Jun 6, 2016
.travis.yml Travis CI is failing Jun 10, 2016
ANDROID.txt Fix build in packaging systems like portage or debian Dec 16, 2013
COPYING Licence: Relicence all Pachi from MIT to GPLv2 Dec 11, 2009
CREDITS joseki19.pdict: Dictionary with lines auto-extracted from Kogo Dec 5, 2010
HACKING t-predict: test components prediction rates May 1, 2016
Makefile Makefile: handle caffe in unusual places Aug 5, 2016
Makefile.lib Makefile: c++ rules Mar 28, 2016
README use Detlef's 54% dcnn Apr 20, 2016
TODO TODO: GNUGo cross-pollination? Dec 15, 2013
board.c playout: free policy state (b->ps) at board destroy time Jul 19, 2016
board.h playout: free policy state (b->ps) at board destroy time Jul 19, 2016
book.dat.bad book.dat*: Tweak based on 9x9 computer olympiad Nov 22, 2011
book.dat.extra book.dat*: Tweak based on 9x9 computer olympiad Nov 22, 2011
chat.c the C language doesn't allow for argument name omission Apr 5, 2016
chat.h Add option -c chat_file to support fancy replies to kgs-chat Apr 22, 2012
dcnn.cpp dcnn engine: plays dcnn best move May 1, 2016
dcnn.h dcnn engine: plays dcnn best move May 1, 2016
debug.h Header guards: Rename ZZGO_* to PACHI_* Apr 16, 2011
engine.h replay: replay_sample_moves(), Jul 11, 2016
fbook.c fbook_init(): Remove bogus comment Aug 12, 2012
fbook.h fbook_init(): Return NULL if the book turned out to stay empty May 29, 2011
fixp.h Header guards: Rename ZZGO_* to PACHI_* Apr 16, 2011
gogui.h gogui-best_moves Jan 29, 2016
gtp.c uct: moved printhook_ownermap() logic to ownermap.c, Jul 11, 2016
gtp.h gogui-analyze_commands (uct only) Jan 29, 2016
joseki19.pdict joseki19.pdict: Dictionary with lines auto-extracted from Kogo Dec 5, 2010
move.c move.[ch]: Add str2scoord(), export coord2bstr() to avoid mallocs May 8, 2010
move.h t-unit: board_undo stress test Jul 11, 2016
mq.h dead stones: add own unclear dead groups if it doesn't change the out… Jul 4, 2016
network.c Merge branch 'pull-req/win32' of https://github.com/sthalik/pachi Mar 29, 2016
network.h Use appropriate socket includes on WIN32 Jan 22, 2012
ownermap.c uct: moved printhook_ownermap() logic to ownermap.c, Jul 11, 2016
ownermap.h uct: moved printhook_ownermap() logic to ownermap.c, Jul 11, 2016
pachi.c replay: replay_sample_moves(), Jul 11, 2016
pattern.c PATTERN_SPEC_MATCH_DEFAULT: Disable PF_CAPTURE_COUNTSTONES as it was … Dec 10, 2013
pattern.h feature_payloads(): Take pattern_setup inst. of pattern_config as fir… Mar 21, 2012
pattern3.c pattern3: Group commands in block after if clause Mar 31, 2016
pattern3.h Moggy, Pattern3: Add support for assigning gamma values to 3x3 patter… Mar 22, 2013
patternprob.c pattern_rate_moves(): Add a debug print listing all patterns considered Dec 13, 2013
patternprob.h Patternplay: Use patterns_init(); pattern_rate_moves() uses pattern_s… Jan 11, 2012
patternsp.c Merge branch 'master' of ssh://repo.or.cz/srv/git/pachi Feb 10, 2012
patternsp.h MAX_PATTERN_DIST: 6 -> 7 Mar 22, 2012
playout.c playout: free policy state (b->ps) at board destroy time Jul 19, 2016
playout.h playout: free policy state (b->ps) at board destroy time Jul 19, 2016
probdist.c Elo, probdist: Do not needlessly consider board edges Jul 3, 2010
probdist.h Header guards: Rename ZZGO_* to PACHI_* Apr 16, 2011
random.c Removes unnecessary if; corrects missing semicolon Dec 25, 2015
random.h fast_frandom() always returns float, not floating_t May 18, 2012
stats.h stats.h: move floating_t up front Mar 15, 2016
stone.c Initial commit - basics work, but below idiotbot level Nov 11, 2007
stone.h Header guards: Rename ZZGO_* to PACHI_* Apr 16, 2011
timeinfo.c time_sleep(): WIN32-specific implementation without nanosleep() Jan 22, 2012
timeinfo.h Header guards: Rename ZZGO_* to PACHI_* Apr 16, 2011
util.h rename DOUBLE_TIME to DOUBLE_FLOATING Jun 18, 2016
version.h Pachi Genjo-devel 11.99 Apr 13, 2015

README

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.


Installation
------------

To build Pachi, simply type:

	make

The resulting binary program `pachi` is a GTP client; connect to it
with 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 pachi program can take many parameters, as well as the particular
engine being used; the defaults should be fine for initial usage,
see below for some more tips.

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.


Engine
------

The default engine plays by Chinese rules and should be about 7d KGS
strength on 9x9. On 19x19 (using e.g. six-way Intel i7), it can hold
a solid KGS 2d rank.  When using a large cluster (64 machines,
20 cores each), it maintains KGS 3d to 4d and has won e.g. a 7-stone
handicap game against Zhou Junxun 9p.

By default, Pachi currently uses the UCT engine that combines
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 semi-random Monte Carlo playouts.  Large-scale board patterns
are used in the tree search.

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.

How to run
~~~~~~~~~~

By default, Pachi will run on a single CPU core, taking up to 1.4GiB
of memory and taking a little under 15 seconds per move.  You can
adjust these parameters by passing it extra command line options:

	./pachi -t _1200 threads=8,max_tree_size=3072

This will make Pachi play with time settings 20:00 S.D. with 8 threads,
taking up to 3GiB of memory (+ several tens MiB as a constant overhead)
and thinking during the opponent's turn as well.

Pachi can use an opening book in a Fuego-compatible format - you can
obtain one at http://gnugo.baduk.org/fuegoob.htm and use it in Pachi
with the -f parameter:

	./pachi -f book.dat ...

You may wish to append some custom Pachi opening book lines to book.dat;
take them from the book.dat.extra file. If using the default Fuego book,
you may want to remove the lines listed in book.dat.bad.

Pachi can also use a pattern database to improve its playing performance.
You can get it at http://pachi.or.cz/pat/ - you will also find further
instructions there.

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. At any rate, usually the three options above are
the only ones you really want to tweak.

DCNN support
~~~~~~~~~~~~

Pachi can use a neural network as source of good moves to consider.
Currently this makes it about 1 stone stronger and tends to make the games
more pretty.

First, build Pachi with DCNN support:
- Install Caffe library (http://caffe.berkeleyvision.org)
  CPU only build is fine, no need for GPU, cuda or the other optional
  dependencies.
- Edit Makefile, set DCNN=1, point it to where caffe is installed and build.

Install dcnn files in current directory where pachi will run.
Detlef Schmicker's 54% dcnn can be found at:  
  http://physik.de/CNNlast.tar.gz

More information about this dcnn can be found at:
  http://computer-go.org/pipermail/computer-go/2015-December/008324.html

If you want to use a network with different inputs you'll have to tweak
dcnn.cpp to accomodate it. Pachi will check for "golast19.prototxt" and
"golast.trained" files on startup and use them if present when
playing on 19x19. For now dcnn and pondering can't be used together
(pondering data is thrown away).


Greedy Pachi
~~~~~~~~~~~~

Normally, Pachi cares only for win or loss and does not take into
account the point amount. This means that it will play slack endgame
when winning and crazy moves followed with a resign when losing.

It may give you a more pleasurable playing experience if Pachi
_does_ take into account the point size, strives for a maximum
(reasonable) win margin when winning and minimal point loss when
losing. This is possible by using the maximize_score parameter, e.g.:

	./pachi -t _1200 threads=8,maximize_score

This enables an aggressive dynamic komi usage and end result margin
is included in node values aside of winrate. Pachi will also enter
scoring even when losing (normally, Pachi will never pass in that case).
Note that if you pass any 'dynkomi' parameter to Pachi, you will reset
the values set by 'maximize_score'.

Note that Pachi in this mode may be slightly weaker, and result margin
should not be taken into account when judging either player's strength.
During the game, the winning/losing margin can be approximated from
Pachi's "extra komi" or "xkomi" reporting in the progress messages.

Experiments and Testing
~~~~~~~~~~~~~~~~~~~~~~~

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
* a simple "patternplay" engine that will play moves according to the
  learned patterns
* 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:

	./pachi -t =5000 policy=ucb1,playout=light,prior=eqex=0,dynkomi=none,pondering=0,pass_all_alive

This will fix the number of playouts per move to 5000, switch the node
selection policy from ucb1amaf to ucb1 (i.e. disable RAVE), switch the
playouts from heuristic-heavy moggy to uniformly random light, stop
prioring the node values heuristically, turn off dynamic komi, disable
thinking on the opponent's time and make sure Pachi passes only when
just 10% alive stones remain on the board (to avoid disputes during
counting).

You can of course selectively re-enable various features or tweak this
further. But please note that using Pachi in this mode is not tested
extensively, so check its performance in whatever version you test
before you use it as a reference.

Note that even in this "basic UCT" mode, Pachi optimizes tree search
by considering board symmetries at the beginning. Currently, there's no
easy option to turn that off. The easiest way is to tweak board.c so
that board_symmetry_update() has goto break_symmetry at the beginning
and board_clear has board->symmetry.type = SYM_NONE.


Analysis
--------

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 several Pachi interfaces provided for this purpose.

Winrate Development
~~~~~~~~~~~~~~~~~~~

Pachi can 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.
See the comment on top of the script about its usage.

Move Ranking
~~~~~~~~~~~~

Pachi can evaluate all available moves in a given situation
and for each give a value between 0 and 1 representing perceived
likelihood of winning the game if one would play that move. I.e. it can
suggest which moves would be good and bad in a single given situation.

To achieve the latter, note the number of move at the situation you
want to evaluate and run the `tools/sgf-ratemove.sh` script.
See the comment on top of the script about its usage.

Pattern Move Hinting
~~~~~~~~~~~~~~~~~~~~

Pachi can show instantenous pattern-based move suggestions very much
like for example Moyo Go Studio (though of course without a GUI).
You can use the Move Ranking method above (tools/sgf-ratemove.sh),
but pass it an extra parameter '-e patternplay'.


Framework
---------

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 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.

Also, if you are interested about Pachi's architecture, algorithms
etc., consider taking a look at Petr Baudis' Master's Thesis:

	http://pasky.or.cz/go/prace.pdf

...or a slightly newer scientific paper on Pachi:

	http://pasky.or.cz/go/pachi-tr.pdf


Licence
-------

Pachi is distributed under the GPLv2 licence (see the COPYING file for
details and full text of the licence); you are welcome to tweak it as
you wish (contributing back upstream is welcome) and distribute
it freely, but only together with the source code. You are welcome
to make private modifications to the code (e.g. try new algorithms and
approaches), use them internally or even to have your bot play on the
internet and enter competitions, but as soon as you want to release it
to the public, you need to release the source code as well.

One exception is the Autotest framework, which is licenced under the
terms of the MIT licence (close to public domain) - you are free to
use it any way you wish.