[gnugo-devel] task list

[away12345]

can anyone give some simple task instead of this task below?



 GNU Go Task List



You can help make GNU Go the best Go program.



This is a task-list for anyone who is interested in helping with GNU

Go. If you want to work on such a project you should correspond with

us until we reach a common vision of how the feature will work!



A note about copyright. Before any code can be accepted as a part of

the official release of GNU Go, the Free Software Foundation will want

you to sign a copyright disclaimer. Of course you can work on a forked

version without signing such a disclaimer. If you want your changes to

the program to be incorporated into the version we distribute we need

such a disclaimer. Please contact the GNU Go maintainers, Daniel Bump

(address@hidden) and Gunnar Farneback

(address@hidden), to get more information and the papers to

sign.



Below is a list of things YOU could work on. We are already working on

some of these tasks, but don't let that stop you. Please contact us or

the person assigned to task for further discussion.



//--------------------------------------------------------------

// General

//--------------------------------------------------------------



 * If you can, send us bug FIXES as well as bug reports. If you see

   some bad behavior, figure out what causes it, and what to do about

   fixing it. And send us a patch! If you find an interesting bug and

   cannot tell us how to fix it, we would be happy to have you tell us

   about it anyway. Send us the sgf file (if possible) and attach

   other relevant information, such as the GNU Go version number. In

   cases of assertion failures and segmentation faults we probably

   want to know what operating system and compiler you were using, in

   order to determine if the problem is platform dependent.



//--------------------------------------------------------------

// smaller projects

//--------------------------------------------------------------



These issues are of tactical nature, i.e. they concern some specific

feature or the infrastructure of the engine.  Some of these are quiet

small, maybe doable in a day for an experienced GNU Go programmer.

They might also be useful project to start with for a new project

member.  Some of them are bigger and demand a deeper knowledge of the

engine internals.  The issues are presented here in an approximate

order of perceived difficulty.



 * Add more checks in patterns/mkpat.c testing whether the main diagram 

and

   the constraint diagram are consistent.



 * Break out handling of movelists into its own file and generalize it.

   This is started in 3.1.16. Move lists are used, among other places, 

   in worms.c where it is used to store moves that capture, save, 

   threaten to capture and threaten to save the worm.



 * Implement move lists storing important moves for dragons and eyes

   in the same way as it is used for worms.  Half eyes are already

   halfway done.  The moves are stored, but not the attack and defend

   codes (LOSE, KO_A, KO_B and WIN).



 * Make the cache not waste storage on 64 bit systems.



 * Implement detection of superko violation in the board code. We

   probably only want this optionally in play_move() and in a variant

   of is_legal().



 * The dragon data is split into two arrays, dragon[] and dragon2[].

   The dragon2 array only have one entry per dragon, in contrast to

   the dragon array where all the data is stored once for every

   intersection of the board.  Complete the conversion of eye_data,

   half_eye_data, worm and dragon to use the same structure as the

   dragon2 array.



 * Support for ko in eyes.db and optics.c.



 * Integrate the time handling code in play_gtp.c with the autolevel

   code in clock.c. Alternatively, replace them both with something

   better. Basing it on some solid system identification theory and/or

   control theory wouldn't hurt.



 * Write a script which plays through the joseki databases and checks

   that the engine really generates a joseki move for all positions in

   the databases. This would also be interesting to run with the

   --nojosekidb option.





//--------------------------------------------------------------

// long term issues

//--------------------------------------------------------------





These issues are strategic in nature. They will help us to improve the

playing strength of the program and/or enhance certain aspects of it.



 * Extend the regression test suites.

   See the texinfo manual in the doc directory for a description of

   how to do this. In particular it would be useful with test suites

   for common life and death problems. Currently second line groups, L

   groups and the tripod shape are reasonably well covered, but there

   is for example almost nothing on comb formations, carpenter's

   square, and so on. Other areas where test suites would be most

   welcome are fuseki, tesuji, and endgame.



 * Tuning the pattern databases. These are under constant revision.  

Tuning

   them is a sort of art. It is not necessary to do any programming to 

do 

   this since most of the patterns do not require helpers. We would like 

it if

   a few more Dan level players would learn this skill.



 * Extend and tune the Joseki database. It might be very useful to 

implement

   a semi-automatic way of doing this. The current method based on sgf 

files

   becomes difficult with existing tools.



 * The semeai module is still in need of improvement. (This is underway.)



 * GNU Go does not have a move generator that tries explicitly to build

   moyos, or reduce/invade opponent's moyos. Such a move generator could

   be built using the same type of code that is used in the owl life and

   death reader, or the connection reader mentioned in point 5 above.



 * A much improved combination module.  The combination module of

   today only finds combinations of threats to capture enemy groups.

   A more useful combination module would e.g. find combinations of

   threats to capture a group or enter opponent territory.  It would

   also be strong enough to find combinations of strategic moves and

   more indirect threats (a threat to a threat).  Possibly it could

   combine threats in AND-OR trees (DAGs?) that could be searched

   using ordinary tree search algorithms.  (Revision of combination.c

   is underway.)



 * Speed up the tactical reading. GNU Go is reasonably accurate when

   it comes to tactical reading, but not always very fast.  The main

   problem is that too many ineffective moves are tested, leading to

   strange variations that shouldn't need consideration.  To improve

   one could refine the move generation heuristics in the reading.

   Also, one should implement some more of the standard tree search

   optimizations used in alpha-beta readers.



 * Improve the heuristics for assessment of the safety of a

   group. This might take into account number of eyes / half eyes,

   moyo in corners, moyo along the edge, moyo in the center, proximity

   to living friendly groups, weak opponent groups etc. It is of

   particular interest to be able to accurately determine how a move

   affects the safety of all groups on the board.





//--------------------------------------------------------------

// Ideas

//--------------------------------------------------------------





These are some ideas that have been floated on the mailing list.  Some

of them are down-to-earth, and some are just blue sky ramblings.  They

are presented here for inspiration.



 * A good GUI.

   A start is being made with GoThic, a goban widget based on the QT

   toolkit.  This is linked from the GNU Go development web page on

   gnu.org. Other starts have been made based on GTK, but so far

   nothing more than a start has been attempted.



 * A graphical pattern editor.

   This would make it much easier for non-programmers to improve the

   strength of GNU Go.  It could also be used as a debugging tool for

   the programmers.  This project has the GUI as a prerequisite.

   The challenge here is not to make a tool which makes it easier to

   create patterns but to make it easier to overview and maintain the

   database.



 * Make the engine thread safe and use multiple CPUs on an SMP

   machine.



 * Making the engine use many machines loosely connected on the

   internet or in a cluster.



 * Think on the opponent's time.



 * A global alpha-beta reader.  This would probably be very slow and

   could only read 2 or 3 moves ahead.  Still it could find fatal

   errors and improve the moves that GNU Go makes.



 * A strategic module that identifies high-level goals and then gives

   these goals to the rest of the engine.  It should be able to

   identify if we are ahead in territory or thickness, if we should

   play safe or if we should play daringly (e.g. if behind).  It

   should also identify weak areas where we can attack or where we

   should defend.  Maybe this module doesn't have to be written in C.

   Maybe PROLOG, LISP or some other AI language would be better.



 * A parameter that makes GNU Go play different styles.  Such styles

   could be 'play for territory', 'play aggressively', 'play tricky

   moves (hamete)', and so on.  It could be used to present human

   users with different kinds of opponents or to tell GNU Go how to

   play certain computer opponents in tournaments.



 * Generalize representation and handling of threats so that we have a

   graph representation of threats that can be searched to see how

   different threats interact.



 * An endgame module based on ideas from combinatorial game theory.

   To be really useful this would have to deal with early endgame

   positions.



 * Fuseki tuning by hand is difficult. People who are interested

   in doing machine learning experiments with GNU Go could try

   working with fuseki. This may be one of the areas with most

   potential for substantial and reasonably quick improvements.



 * Create a paradigm for handling other types of ko (approach move ko,

   multi-step ko, etc) and then write code that handles them. 
______________________________________


×¢²áÐÂÀËÃâ·ÑÓÊÏ䣬¼¤»î2G¿Õ¼ä£¡£¨ http://mail.sina.com.cn/chooseMode.html £©

===================================================================
Ï¢ÕÇÀû¶à£¬°²Ðľ۲Æ-º£¸»Í¨»õ±ÒÊг¡»ù½ðÔÚ·¢ÐУ¡ 
(http://ad4.sina.com.cn/wlw/all/zhuiyu.html)