[Pachi] TODO list update
pasky at ucw.cz
Sun Dec 15 16:04:04 CET 2013
I've taken few minutes to revamp, update and expand our long-outdated
TODO list, in case anything in there would pique someone's interest. :)
Some of these features do not actually require modifying Pachi's C
codebase but involve working just with Pachi's output, or do not require
digging into the "black magic" parts of the code that involve actual
Go-playing, yet would be immensely useful - e.g. the offline/online game
analysis features would be great both for Pachi users and for developers
as a debugging aid.
I think reproducing e.g. CrazyStone's game analysis features in the
open source environment could be just a few hours/part-days of work,
there is no major barrier here, and it can be easily done in a high level
language if C feels too arcane.
But of course, there are "easy" entry points for people who would
like to directly help make Pachi play stronger. To get familiar with
the codebase, contributing some docs is always appreciated; the
"self-contained tasks" section lists some other ideas. What about
teaching Pachi about the monkey jump? There is still a lot of fairly
low-hanging fruit around.
Here goes the current version of the TODO list:
> * Manual page - full usage documentation
> * GTP interface documentation
> * Further optimize board implementation, profiling fun
> * Clean up GTP interface, allow custom GTP commands for modules
> * gogui-friendly GTP interface
> * Implement parameter setup over GTP (less important)
> * Fix the build system to allow fully parallel build
> However, revamp to something like cmake (or, ugh, autotools)
> is not guaranteed to be appreciated.
> Self-contained tasks:
> * Improving Pachi's game analysis features
> We provide just a few user-unfriendly proof-of-concept scripts
> but it should be fairly easy to upgrade them to something
> that creates a nice webpage with move-by-move statistics,
> winrate evolution, pattern moves andwhatnot. CrazyStone stats
> output may be used for inspiration, but we can take it further!
> This could be done even if you are afraid of Pachi's codebase,
> just using Pachi's output.
> * Try to disable the bsize pattern feature
> It just fudges the pattern evaluation since for most tactical
> patterns fourth line vs. fifth line just doesn't matter. Maybe
> its max should be 2 and maybe it should just be gone, needs
> regenerating the pattern database and benchmarking.
> * Develop dedicated playout handling for few common tactical situations
> Monkey jump (and its followup sequences!), bent four in the
> corner, ...
> * Fix seki recognition to be stable
> Try to research and fix most cases harmed by selfatarirate=100
> or find another way to fix seki.
> * Try to avoid using a hash table for 3x3 patterns
> Instead autogenerate procedural matching code; may be more
> efficient (the near-guaranteed L1 cache miss is fairly expensive).
> * Optimizing our tree implementation for cache-efficiency
> Statistics of all children of a parent node shall be contained
> in an array of the parent node so that move evaluation during
> the descent can access them sequentially in memory, instead
> of walking a linked list. Pasky already tried once but it's
> somewhat arduous and dull work.
> * Clean up the is_private() hack in the distributed engine
> We should simply check against a proper IP range ACL specified
> as a parameter instead.
> General improvements:
> * Online Pachi game analysis/dump features
> Make Pachi generate a webpage with *lots* of details after each
> move while playing a game. This can provide game analysis info
> for observer or casual opponent, but could also help with
> debugging when just dumping stuff on stderr is intractable.
> * Automated building of opening book
> * Expanding and tagging the regression suite
> Even better, create a nice UI for our users to contribute and
> What about drawing testcases from GNUGo's regression suite?
> * Implement Pachi support to fishtest
> http://tests.stockfishchess.org/tests would allow crowdsourcing
> Pachi parameter tuning.
> * Split playout aspects to custom-stackable pieces?
> * Port to Intel Phi (if we get the hardware :)
> Some heuristics to test:
> * Try to adapt and reuse GNUGo's pattern matching code/database
> * Local trees (work in progress, no luck so far)
> * Liberty maps (work in progress)
> * Implement a tsumego solver and apply it once per playout (stv insp.,
> see Eric van der Werf's PhD thesis?)
> * MM local-based patterns in playouts (work in progress, no luck so far)
> * Balanced local-based patterns?
> * Killer moves (redundant to RAVE?)
> * Reverse status learning
> Run on game corpus. Start at final position, watch development
> of status of all stones. The moment the final status and expected
> status changes, analyze, especially if move choice differs. Use
> learnt status-fixing moves in simulations somehow.
> Tried to do this on Pachi-played KGS games; no measurable effect
> (maybe too small sample).
Happy seasonal hacking,
Petr "Pasky" Baudis
More information about the Pachi