Changeset 15606 for branches/MCTS-SymbReg-2796/HeuristicLab.Algorithms.DataAnalysis/3.4/MctsSymbolicRegression/MctsSymbolicRegressionStatic.cs

Timestamp:

01/12/18 16:27:39 (6 years ago)

Author:

gkronber

Message:

#2796: comments and typos

File:

• branches/MCTS-SymbReg-2796/HeuristicLab.Algorithms.DataAnalysis/3.4/MctsSymbolicRegression/MctsSymbolicRegressionStatic.cs (modified) (9 diffs)

branches/MCTS-SymbReg-2796/HeuristicLab.Algorithms.DataAnalysis/3.4/MctsSymbolicRegression/MctsSymbolicRegressionStatic.cs

@@ -48 +48 @@
     //      - standardization of variables is possible (or might be necessary) as we adjust numeric parameters of the expression anyway
     //      - to simplify the problem we can restrict the set of functions e.g. we assume which functions are necessary for the problem instance
-    //        -> several steps: (a) polyinomials, (b) rational polynomials, (c) exponential or logarithmic functions, rational functions with exponential and logarithmic parts
+    //        -> several steps: (a) polynomials, (b) rational polynomials, (c) exponential or logarithmic functions, rational functions with exponential and logarithmic parts
     // 3) efficiency and effectiveness for real-world problems
     //    - e.g. Tower problem
@@ -56 +56 @@
     // TODO: The samples of x1*... or x2*... do not give any information about the relevance of the interaction term x1*x2 in general!
     //       --> E.g. if x1, x2 ~ N(0, 1) or U(-1, 1) this is trivial to show
-    //       --> Therefore, looking at rollout statistics for arm selection is useless in the general case!
+    //       --> Therefore, looking at roll-out statistics for arm selection (MCTS-style) is useless in the general case!
     //       --> It is necessary to rely on other features for the arm selection. 
     //       --> TODO: Which heuristics can we apply? 
@@ -64 +64 @@
     //       and later we find the a longer form x1 + x1 + x2 where the number of variable references
     //       exceeds the maximum in the automaton this leads to an error (see unit tests) 
-    // ~~obsolete TODO: After state unification the recursive backpropagation of results takes a lot of time. How can this be improved?
-    // ~~obsolete TODO: Why is the algorithm so slow for rather greedy policies (e.g. low C value in UCB)?
-    // ~~obsolete TODO: check if we can use a quality measure with range [-1..1] in policies
     // TODO: unit tests for benchmark problems which contain log / exp / x^-1 but without numeric constants 
     // TODO: check if transformation of y is correct and works (Obj 2)
@@ -77 +74 @@
     // TODO: analyze / improve perf of ExprHashing (canonical form for expressions)
     // TODO: support empty test partition
-    // TODO: the algorithm should be invariant to linear transformations of the space (y = f(x') = f( Ax ) ) for invertible transformations A --> unit tests
+    // TODO: the algorithm should be invariant to linear transformations of the space (y = f(x') = f( Ax ) ) for invertible transformations A --> see unit tests
     #region static API
 
@@ -102 +99 @@
       internal readonly Tree tree;
       internal readonly Func<byte[], int, double> evalFun;
-      // MCTS might get stuck. Track statistics on the number of effective rollouts
+      // MCTS might get stuck. Track statistics on the number of effective roll-outs
       internal int totalRollouts;
       internal int effectiveRollouts;
@@ -228 +225 @@
       }
 
-      // takes the code of the best solution and creates and equivalent symbolic regression model
+      // takes the code of the best solution and creates and equivalent symbolic regression models
       public ISymbolicRegressionModel BestModel {
         get {
@@ -539 +536 @@
       // State equivalence is checked through ExprHash (based on the generated code through the path).
 
-      // We switch between rollout-mode and expansion mode
-      // Rollout-mode means we are navigating an existing path through the tree (using a rollout policy, e.g. UCB)
-      // Expansion mode means we expand the graph, creating new nodes and edges (using an expansion policy, e.g. shortest route to a complete expression)
-      // In expansion mode we might re-enter the graph and switch back to rollout-mode
-      // We do this until we reach a complete expression (final state)
-
-      // Loops in the graph are prevented by checking that the level of a child must be larger than the level of the parent
+      // We switch between rollout-mode and expansion mode.
+      // Rollout-mode means we are navigating an existing path through the tree (using a rollout policy, e.g. UCB).
+      // Expansion mode means we expand the graph, creating new nodes and edges (using an expansion policy, e.g. shortest route to a complete expression).
+      // In expansion mode we might re-enter the graph and switch back to rollout-mode.
+      // We do this until we reach a complete expression (final state).
+
+      // Loops in the graph are prevented by checking that the level of a child must be larger than the level of the parent.
       // Sub-graphs which have been completely searched are marked as done.
       // Roll-out could lead to a state where all follow-states are done. In this case we call the rollout ineffective.
@@ -806 +803 @@
 
     // for debugging only
-
+    #region debugging
 
     private static string TraceTree(Tree tree, State state) {
@@ -894 +891 @@
       return sb.ToString();
     }
+  #endregion
   }
 }