NOTES

   1 For a game with B+4.5 result taking komi (including dynkomi) into account, board_official_score() would return -4.5, while most other scores will give 4.5 (i.e. black's area is larger than white's, plus komi, by 4.5).  This score (multiplied by 2 to yield an integer called "result" in some places) will be clamped into a value in [0,1] so that unlikely playouts will not affect the average too much.  The values stored in the tree nodes are still absolute (>0.5 means black is favored), but the printed values have been adjusted by tree_node_get_value() such that >0.5 means the currently player (corresponding to nodes just below the root) is favored.  The dynkomi value shown is absolute as well: positive means that black is winning.
   2
   3 When the tree reaches the maximum size, no node will be added until the move is decided and garbage collection is performed; therefore, if too little memory is available and the important nodes (the ones corresponding to tricky moves not understood by the playout engine) are not in the tree when memory is filled, long thinking times won't help.  Pruning is currently not done during a move, and it is done by preserving all nodes within a shallow depth (the node count would increase exponentially) and high-playout nodes in larger depths.  All children of a node are pruned at once, putting the parent node back into the unexpanded state.
   4
   5 TODO:
   6
   7 Setting explore_p=0 causes the algorithm to miss obvious moves, e.g. the capturing move W58 in r6144-pachi-110709.  However, simply increasing it is said to make the tree too wide and shallow (too much exploration), so a balance must be reached.  Note that even if explore_p is increased, moves that need non-obvious follow-ups (e.g. W56 in r6144-pachi-110709) and have large risks otherwise can still be hard to find, as the first playouts of the parent node may well miss the correct follow-up, after which the parent node will cease to be played so much.
   8
   9 When the dynkomi is adjusted, the existing values in the tree are not recomputed, so if large changes in dynkomi is present during one move, the average values and scores will be inaccurate, and more importantly, nodes expanded early will have biased values and thus be explored too (in)frequently.  Resign decisions will be affected as well.  Perhaps we should include a larger linear section (5 points should probably be reasonable) in scale_value(), and avoids adjusting the dynkomi during a move (as opposed to adjustments between moves) unless the average is near the boundary of this linear section, and a correction may be introduced even in this case.  However, other thresholds depending on the average value, such as the resign threshold, should be adjusted accordingly.
  10
  11 Memory use could be optimized.  Some exploration vs. exploitation decisions should be made with the amount of free memory taken into consideration (for example, expand_p can be dynamically raised when memory is tight, since it essentially determines the fraction of games that lead to an expansion).  The depth and playout count thresholds when pruning should be adjusted more robustly according to the maximum size of the temporary tree; currently it is possible that the maximum temp tree size gets exceeded before all nodes within the playout count threshold are included (take a look at the pruning statistics to see whether the maximum tree size is reached; the unit is bytes and each node is currently 88 bytes on a 64-bit system).  Finally, it seems to be inefficient to expand all the (often 300+) children of a node at once whenever its playout count reaches expand_p (and memory is available).  Of course, allowing pruning during a move may well be helpful with limited memory and long thinking times, but thread synchronization must be done carefully, and the aforementioned robustness issues of the pruning process would become more important.