Update Manual Syntax and Learning and Tutorial Planning

This allow the div HTML elements for grid views

Author: moschmdt

.markdownlint.json

@@ -20,5 +20,10 @@
     },
     "MD025": {
         "front_matter_title": ""
+    },
+    "MD033": {
+        "allowed_elements": [
+            "div"
+        ]
     }
 }

docs/soar_manual/03_SyntaxOfSoarPrograms.md

@@ -1938,7 +1938,7 @@ After this rule fires, working memory might look like:
 `(S1 ^heading 526.432 ^true-heading 166.5)`.
 
 **size** — This function returns an integer symbol whose value is the count of
-WME aug- mentations on a given ID argument. Providing a non-ID argument results
+WME augmentations on a given ID argument. Providing a non-ID argument results
 in an error. For example:
 
 ```Soar

docs/soar_manual/04_ProceduralKnowledgeLearning.md

@@ -27,7 +27,7 @@ internally before executing them in the world. In addition, planning provides a
 way of comparing alternative operators based on the states they produce.
 Chunking builds rules that summarize the comparisons and evaluations that occur
 in the look-ahead search so that in the future the rules fire, making look-ahead
-search unnecessary – converting deliberation into reaction.
+search unnecessary - converting deliberation into reaction.
 
 Many planning systems have a two-stage cycle of planning and execution.
 They always plan when given a new problem and then execute the plan step
@@ -354,11 +354,12 @@ a few Water Jug specific rules; however, that means that with each new
 task, new state copy rules must also be written. To avoid this, we have
 written a general set of rules that can copy down the augmentations.
 These rules match against augmentations of the problem space to
-determine with state augmentations to copy. Below are the legal
+determine which state augmentations to copy. Below are the legal
 augmentations dealing with state copying and their meaning:
 
--   default-state-copy no: Do not copy any augmentations automatically.
--   one-level-attributes: copies augmentations of the state and preserves their value.
+-   `default-state-copy no`: Do not copy any augmentations automatically.
+-   `one-level-attributes`: copies augmentations of the state and preserves
+    their value.
 
     Example:
 
@@ -367,7 +368,7 @@ augmentations dealing with state copying and their meaning:
     (s2 ^color c1)
     ```
 
--   two-level-attributes: copies augmentations of the state and creates
+-   `two-level-attributes`: copies augmentations of the state and creates
     new identifiers for values. Shared identifiers replaced with same
     new identifier.
 
@@ -378,9 +379,9 @@ augmentations dealing with state copying and their meaning:
     (s2 ^color c5) (c5 ^hue green)
     ```
 
--   all-attributes-at-level one: copies all attributes of state as
-    one-level-attributes (except dont-copy ones and Soar created ones
-    such as impasse, operator, superstate)
+-   `all-attributes-at-level one`: copies all attributes of state as
+    one-level-attributes (except `dont-copy` ones and Soar created ones
+    such as `impasse`, `operator`, `superstate`)
 
     Example:
 
@@ -389,9 +390,9 @@ augmentations dealing with state copying and their meaning:
     (s2 ^color c1) (s2 ^size big)
     ```
 
--   all-attributes-at-level two: copies all attributes of state as
-    two-level-attributes (except dont-copy ones and Soar created ones
-    such as impasse, operator, superstate)
+-   `all-attributes-at-level two`: copies all attributes of state as
+    two-level-attributes (except `dont-copy` ones and Soar created ones
+    such as `impasse`, `operator`, `superstate`)
 
     Example:
 
@@ -400,22 +401,22 @@ augmentations dealing with state copying and their meaning:
     (s2 ^color c5) (c5 ^hue green)
     ```
 
--   dont-copy: will not copy that attribute.
+-   `dont-copy`: will not copy that attribute.
 
     Example:
 
     ```Soar
     (p1 ^dont-copy size)
     ```
 
--   don’t-copy-anything: will not copy any attributes
+-   `dont-copy-anything`: will not copy any attributes
 
     ```Soar
     (p1 ^dont-copy-anything yes)
     ```
 
 If no augmentations relative to copying are included, the default is to
-do all-attributes-at-level one. The desired state is also copied over,
+do `all-attributes-at-level one`. The desired state is also copied over,
 based on the copy commands for the state.
 
 These rules support two levels of copying. How should you decide what
@@ -451,9 +452,10 @@ sp {water-jug*apply*fill
       ^empty <volume>)
    -->
    (<j> ^contents <volume>
-      0 -
+         0 -
       ^empty 0
-      <volume> - ) # (1)}
+         <volume> - ) # (1)
+}
 ```
 
 1.  To remove a working memory element, use `-`.
@@ -481,9 +483,9 @@ sp {water-jug*elaborate*problem-space
       ^two-level-attributes jug)}
 ```
 
-You could use ^all-attributes-at-level two instead, but it is best to
+You could use `^all-attributes-at-level two` instead, but it is best to
 list exactly the attributes you need to have copied. After using this,
-the substate, s3, would have the following structure:
+the substate, `s3`, would have the following structure:
 
 ```Soar
 (s3 ^jug j3 j4)
@@ -522,7 +524,7 @@ working memory when an operator is applied, although it requires fewer
 working memory elements to be copied during the creation of the initial
 state. This approach also is less natural in that it implies that a new
 jug is created as opposed to just modifying the contents of the existing
-jug. For these two reasons, the first approach (two-level-attribute
+jug. For these two reasons, the first approach (`two-level-attribute`
 copying) is preferred.
 
 #### Selecting the operator being evaluated
@@ -564,7 +566,7 @@ Once the new state is created, an evaluation can be made. An
 augmentation is added to the state in parallel to the operator being
 applied: `^tried-tied-operator <o>`. This augmentation can be tested by
 rules to ensure that they are evaluating the result of applying the
-operator as opposed to the copy of the original state – although this
+operator as opposed to the copy of the original state - although this
 will not work for operators that apply as a sequence of rules.
 
 The simplest evaluations to compute are success and failure. Success is
@@ -594,26 +596,26 @@ In addition to success and failure, the selection rules can process
 other symbolic evaluations as well as numeric evaluations. The symbolic
 preferences that are processed are as follows:
 
--   success: This state is the desired state. This is translated into a
+-   **success**: This state is the desired state. This is translated into a
     best preference. It is also translated into a better preference if
     another operator has a result state with an evaluation of
     partial-success.
 
--   partial-success: This state is on the path to success. This is
+-   **partial-success**: This state is on the path to success. This is
     translated into a best preference.
 
--   indifferent: This state is known to be neither success of failure.
+-   **indifferent**: This state is known to be neither success of failure.
     This is translated into an indifference preference.
 
--   failure: The desired state cannot be achieved from this state. This
+-   **failure**: The desired state cannot be achieved from this state. This
     is translated into a reject preference.
 
--   partial-failure: All paths from this state lead to failure. This is
+-   **partial-failure**: All paths from this state lead to failure. This is
     translated into a worst preference.
 
 For numeric evaluations, an augmentation named `^numeric-value` should be
 created for the evaluation object for an operator. We will discuss
-numeric evaluations in more detail in a future section.
+numeric evaluations in more detail in a [future section](#numeric-evaluations).
 
 If you include your original rules, the selection rules, and the two new
 rules described above (`water-jug*elaborate*problem-space`,
@@ -646,10 +648,10 @@ following:
     test for this is: `(<s1> ^tried-tied-operator)`
 1.  That there is a duplicate of that state that is earlier in the state
     stack. There is nothing inherent in Soar that keeps track of all
-    earlier states – only the superstate is readily available. We need
+    earlier states - only the superstate is readily available. We need
     to add rules that elaborate each state with all of its superstates
     (and their superstates). We will call this the superstate-set.
-    Computing this requires only two rules – one that adds its
+    Computing this requires only two rules - one that adds its
     superstate to the superstate-set and one that adds all of the
     superstate-set of the superstate to its superstate-set.
 
@@ -874,7 +876,7 @@ path to the goal. Specifically, chunking can learn a rule that states:
 
 This rule is learned when the operator to move one missionary to the
 left is evaluated in a evaluation subgoal and discovered to lead to a
-failure state – where there is one missionary and two cannibals on the
+failure state - where there is one missionary and two cannibals on the
 right bank. The problem with this rule is that it doesn’t include a test
 that no cannibals are also moved. If the operator moves a cannibal at
 the same time it moves a missionary, it does not produce a failure

docs/soar_manual/Images/chunking-rule-formation.png

@@ -14,3 +14,5 @@
 *[EpMem]: Episodic Memory
 *[ECR]: Expected Current Reward
 *[EFR]: Expected Future Reward
+*[EBC]: Explanation-based Chunking
+*[ROSK]: Relevant Operator Selection Knowledge