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 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 and some timing decisions will be affected as well, although since the statistics used for dynkomi adjustment itself are reset in komi_by_value(), dynkomi adjustment is not affected.  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.  Alternatively, we can adjust up or down the value according to the current dynkomi.
   8
   9 Memory use could be optimized.  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; the unit is bytes and each node is currently 88 bytes on a 64-bit system, and "temp tree overflow" will be reported).  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); due to the relatively high first-play urgency when explore_p is high, a few more playouts on the parent node will visit a similar number of these child nodes, but many of the children are still untouched, and eeven the touched ones only need a small amount of information.  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.  Also note the assumptions made in the program, e.g. in uct_search_result() it is assumed that pass is always the first child.
  10
  11 Currently, pruning is necessary during tree_promote_node() under fast_alloc, because we only have a limited amount of space to copy the surviving nodes into.  This wastes a bit of time in copying (although without fast_alloc, freeing the numerous dead nodes individually will be even slower, and in any case marking the surviving nodes will take almost as many cache misses as copying), and while the pruned nodes are expanded again.  To solve this problem, we can add a version number to each node which is incremented only for surviving ones, and in this way it will be easier to find free nodes; however, threading issues remain to be considered.
  12
  13 Fix the "cannot promote move node" problem when run under gogui-twogtp.
  14
  15 Time control does not seem to work properly (pachi plays very fast and says that the game is internally lost by time) when the same pachi plays both black and white when pondering.  Perhaps this configuration is simply not supported.
  16
  17 Revise board_estimated_moves_left() to use the ownermap information from UCT.