[Pachi] Low-hanging fruit - hacking ideas
pasky at ucw.cz
Sun May 29 18:13:04 CEST 2011
Not sure if anyone who would be interested in actually contributing to
Pachi long-term is reading this list. If not, it's in the archives for
the posterity. ;-)
There's couple of low-hanging fruit ideas that would enjoy some
attention and I'm unlikely to get to them soon. They could make a great
introductory project for people considering to participate in Pachi
development. Ordered roughly by expected difficulty...
* Auto-generate command-line options manual page from code
* Help create regression suite of games
* Opening book (mainly for 19x19) (good also for Go experts with no
* Handicap placement
* Implement gogui livestats extensions
* board_safe_to_play() - Pachi 10% speedup possible?
* Rewrite UCT tree implementation
-- No code, or just some easy scripting.
* Auto-generate command-line options manual page from code - those
comments embedded in pachi.c, uct/uct.c and playout/moggy.c. This way,
users will have nice documentation and the comments will never go
out of date.
* Help create regression suite of games - SGF games where Pachi
misplays obviously, with the correct move marked appropriately. We can
then script up something simple that will use tools/sgf2gtp.pl and run
automated testing. Or it would be useful to write up exact reasons why
Pachi misevaluates the position - together, we can compile some HOWTO
on investigating Pachi's misevaluations.
* Opening book (mainly for 19x19) - we have support for Fuego opening
book syntax, but Fuego's default book is not very good. Ben Lambrecht's
opening book performance needs to be investigated in detail. It would
be ideal to start building our own SGF file with opening book - work
where high level Go players can help - or better extend Ben Lambrecht's
opening book in this regard. Better way than whole-board opening book
would be nice too, but that's already a whole research problem. :)
-- Coding projects
* Handicap placement - deep in my mailbox, I have a report buried that
says fixed_handicap stone placement is not conforming to GTP specs.
* Implement gogui livestats extensions, or at least get started with
some small subset. I'm still used to debugging Pachi using -d 9 and
watching stderr, but it got a lot of using to and I cannot expect anyone
who hasn't written the code to undertake this ordeal.
* board_safe_to_play() calls in 3x3 pattern checks - we do this
way too often, repeatedly for the same coordinates in the same situation
and this shows very high on profiles. Fixing this might lead up to 10%
speedup of Pachi playouts.
* Rewrite UCT tree implementation to have records of all children in
single node. This should significantly improve speed and reduce memory
usage, but it's a fairly large, hairy and boring project...
If anyone needs a helping hand to guide them through the codebase,
just ask! We will be happy to help you out!
Petr "Pasky" Baudis
UNIX is user friendly, it's just picky about who its friends are.
More information about the Pachi