[Pachi] TODO list update

jonathan chetwynd j.chetwynd at btconnect.com
Mon Dec 16 11:04:03 CET 2013


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




More information about the Pachi mailing list