[Pachi] TODO list update

Stanislaw Halik sthalik at misaki.pl
Mon Dec 16 14:06:47 CET 2013


wait till stats moved to parent, imo


On December 16, 2013 11:04:03 AM jonathan chetwynd 
<j.chetwynd at btconnect.com> wrote:
| Petr,
|
| good to see some activity,
|
| is there a sense in me updating pachi** at peepo.com?
|
| are there any stats that you already imagine visualised?
| that could be on the board in real time, but also other approaches
| eg player stats:
| http://peepo.com/pics/oursin.svg
| which has quite a few subtle layers.
|
| I'm ready to add features. if there's interest...
|
| ~:"
|
| **is the current distribution stronger on 2 threads?
| is it likely to be broken?
| eg JSON whatever...
|
|
| On 15/12/13 15:04, Petr Baudis wrote:
| >    Hi!
| >
| >    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:
| >
| >> Docs:
| >> * Manual page - full usage documentation
| >> * GTP interface documentation
| >>
| >> Base:
| >> * 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
| >> 	crowdsource!
| >>   	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
| > _______________________________________________
| > Pachi mailing list
| > Pachi at v.or.cz
| > http://rover.ms.mff.cuni.cz/mailman/listinfo/pachi
| >
| > .
| >
|
|
| _______________________________________________
| Pachi mailing list
| Pachi at v.or.cz
| http://rover.ms.mff.cuni.cz/mailman/listinfo/pachi




More information about the Pachi mailing list