Fix hyphens and whitespaces from conversion

docs/soar_manual/03_SyntaxOfSoarPrograms.md

@@ -4,7 +4,7 @@
 # The Syntax of Soar Programs
 
 This chapter describes in detail the syntax of elements in working memory,
-preference mem- ory, and production memory, and how impasses and I/O are
+preference memory, and production memory, and how impasses and I/O are
 represented in working memory and in productions. Working memory elements and
 preferences are created as Soar runs, while productions are created by the user
 or through chunking. The bulk of this chapter explains the syntax for writing
@@ -115,7 +115,7 @@ to find a specific attribute.
 Working memory is a set, so that at any time, there are never duplicate versions
 of working memory elements. However, it is possible for several working memory
 elements to share the same identifier and attribute but have different values.
-Such attributes are called multi- valued attributes or _multi-attributes_. For
+Such attributes are called multi-valued attributes or _multi-attributes_. For
 example, state `S1`, above, has two attributes that are multi-valued: `thing`
 and `ontop`.
 
@@ -157,7 +157,7 @@ _timetag_.
 ### Acceptable preferences in working memory
 
 The `acceptable` preferences for operators appear in working memory as
-identifier-attribute- value-preference quadruples. No other preferences appear
+identifier-attribute-value-preference quadruples. No other preferences appear
 in working memory. A template for an `acceptable` preference in working memory
 is:
 
@@ -591,7 +591,7 @@ sp {example*lti*predicates
 
 In this production,`<orig-sti>`, is tested for whether it is linked to some LTI.
 It is also compared against `<result-sti>`(a working memory element retrieved
-from long-term mem- ory and known to be linked to an LTI) to see if the two
+from long-term memory and known to be linked to an LTI) to see if the two
 elements point to the same long-term memory. Note the the `@+` in this example
 is actually unnecessary, since the `{ @ <orig-sti> <result-sti> }` test will
 fail to match if either value tested is not linked to an LTI.
@@ -719,7 +719,7 @@ On the other hand, the condition:
 ```
 
 would match only if there is no object in working memory that matches all three
-attribute- value tests.
+attribute-value tests.
 
 ##### Example Production
 
@@ -809,7 +809,7 @@ That is, "not (A and B and C)" becomes "(not A) or (not B) or (not C)".
 #### Multi-valued attributes
 
 An object in working memory may have multiple augmentations that specify the
-same at- tribute with different values; these are called multi-valued
+same attribute with different values; these are called multi-valued
 attributes, or multi-attributes for short. To shorten the specification of a
 condition, tests for multi-valued attributes can be shortened so that the value
 tests are together.
@@ -1394,7 +1394,7 @@ The identifier and value will always be variables, such as
 
 The preference notation appears similar to the predicate tests that appear on
 the left-hand side of productions, but has very different meaning. Predicates
-cannot be used on the right- hand side of a production and you cannot restrict
+cannot be used on the right-hand side of a production and you cannot restrict
 the bindings of variables on the right-hand side of a production. (Such
 restrictions can happen only in the conditions.)
 
@@ -1476,7 +1476,7 @@ But `(<s> ^operator <o1> <o2> >, <o3>)` would be interpreted as
 
 The fourth type of action that can occur in productions is called a _right-hand
 side function_. Right-hand side functions allow productions to create side
-effects other than changing work- ing memory. The RHS functions are described
+effects other than changing working memory. The RHS functions are described
 below, organized by the type of side effect they have.
 
 ##### Stopping and pausing Soar
@@ -1671,7 +1671,7 @@ expects either an integer constant, symbolic constant, or floating point
 constant. The symbolic constant must be a string which can be interpreted as a
 single floating point number. This function essentially operates as a type
 casting function. For example, if you wanted to print out an integer expression
-as a floating-point num- ber, you could do the following:
+as a floating-point number, you could do the following:
 
 ```Soar
 sp {
@@ -1747,7 +1747,7 @@ After this rule fires, working memory would look like:
 ```
 
 **concat** — Given an arbitrary number of symbols, this function concatenates
-them to- gether into a single constant symbol. For example:
+them together into a single constant symbol. For example:
 
 ```Soar
 sp {example
@@ -1760,7 +1760,7 @@ After this rule fires, the WME `(S1 ^name foobar6)` will be added.
 
 **deep-copy** — This function returns a copy of the given symbol along with
 linked copies of all descendant symbols. In other terms, a full copy is made of
-the working mem- ory subgraph that can be reached when starting from the given
+the working memory subgraph that can be reached when starting from the given
 symbol. All copied identifiers are created as new IDs, and all copied values
 remain the same. For example:
 

docs/soar_manual/04_ProceduralKnowledgeLearning.md

@@ -14,7 +14,7 @@ Whenever a rule fires and creates such new superstate knowledge, which are
 called **results**, Soar learns a new rule and immediately adds it to production
 memory. In future similar situations, the new chunk will fire and create the
 appropriate results in a single step, which eliminates the need to spawn another
-subgoal to perform similar problem- solving. In other words, rather than
+subgoal to perform similar problem-solving. In other words, rather than
 contemplating and figuring out what to do, the agent immediately knows what to
 do.
 
@@ -216,7 +216,7 @@ concepts: _identity_.
     cannot be generalized and must contain a specific value.** - All elements in
     the original rule that reference specific constant values are trivially
     assigned the NULL identity. - A variable’s identity can also be _mapped to the
-    NULL identity_. When this hap- pens, we say the identity has been
+    NULL identity_. When this happens, we say the identity has been
     **literalized**.
 
 EBC traverses an explanation trace of the problem-solving that occurred in the
@@ -300,7 +300,7 @@ on the identity graph.
     variablization because they were tested against literal values in some
     rules.  Note that this component has two distinct mechanisms that occur at
     very different times. The first mechanism, identity propagation, occurs
-    constantly while problem- solving in the substate. The second mechanism,
+    constantly while problem-solving in the substate. The second mechanism,
     identity graph manipulation, occurs during the learning episode.
 2.  **Relevant operator selection knowledge tracking**
     This component also occurs before the learning episode. Whenever an operator
@@ -347,7 +347,7 @@ literal constants, which variables are the same variables, what constraints must
 be met on the values of each variable and any relationships between variables.
 
 EBC uses this underlying logic to determine the identities of objects used
-during the problem- solving. Identities are not simply IDs. Each identity is a
+during the problem-solving. Identities are not simply IDs. Each identity is a
 declarative object that describes a set of variables across multiple rule
 firings and the various properties they hold.
 
@@ -551,7 +551,7 @@ Soar’s operationality analysis. In previous versions of chunking, chunking wou
 never add two conditions to a chunk that matched the same superstate working
 memory element. This made sense because chunking was based on a generalization
 of the working memory trace. More than one condition that tested the same WME
-would be redundant. Explanation-based chunk- ing, though, learns based on the
+would be redundant. Explanation-based chunking, though, learns based on the
 reasoning within the original hand-written rules. Since the reasoning behind
 each of the two conditions may be different even if they matched the same WME,
 EBC must always add both conditions. (Note that there are some exceptions. See
@@ -697,11 +697,11 @@ two conditions without losing generality.
 
 EBC polishes the conditions of the learned rule by pruning unnecessary
 constraints on literalized elements and replacing multiple disjunction
-constraints with a single simplified dis- junction.
+constraints with a single simplified disjunction.
 
 1.  Merging disjunctions: If an element in a condition has two disjunction
     tests, the constraints will be merged into a single disjunction that
-    contains only the shared val- ues. `{ << a b c >> << b c d >> <x>}` becomes `{
+    contains only the shared values. `{ << a b c >> << b c d >> <x>}` becomes `{
 <<b c >> <x> }`, because it is impossible fo `<x>` to be either a or b. This
     will also eliminate any duplicate disjunctions.
 2.  Throwing out unnecessary constraints: If an element in a condition has been
@@ -740,7 +740,7 @@ to the fewest number of partial instantiations when the chunk is matched. A
 condition that matches an object with a multi-valued attribute will lead to
 multiple partial instantiations, so it is generally more efficient to place
 these conditions later in the ordering. This is the same process that internally
-reorders the conditions in user- defined productions, as mentioned briefly in
+reorders the conditions in user-defined productions, as mentioned briefly in
 Section 2.3.1.
 
 ## Subtleties of EBC
@@ -809,7 +809,7 @@ When a problem has been decomposed into more than one substate, a single result
 can produce multiple chunks. This process is called bottom-up chunking. The
 first chunk is produced in the substate where the problem-solving that produced
 the result occurred. The next chunk is based on the implicit match of the first
-chunk in one of the higher level problem- spaces. If that match is lower than
+chunk in one of the higher level problem-spaces. If that match is lower than
 the state that the result is being returned to, Soar will backtrace through the
 chunk match and learn a second chunk (relative to the substate that the chunk
 matched in). This process continues until it learns a chunk that only creates
@@ -839,7 +839,7 @@ Chunking is intended to produce the most general rule that is also correct.
 
 Generality is a measure of the space of similar situations that a rule can apply
 to. A more general rule can be applied to a larger space of similar situations.
-A rule is considered over- general if it can apply to situations in which the
+A rule is considered over-general if it can apply to situations in which the
 original problem-solving would have never occurred.
 
 Correctness is a requirement that the learned rule produces the exact same
@@ -855,13 +855,13 @@ rules are over-general.
 ### Over-specialization and Over-generalization
 
 Explanation-based chunking was pursued to address the main limitation of
-traditional chunk- ing:over-specialized rules that were very specific and could
+traditional chunking: over-specialized rules that were very specific and could
 not be applied to many other situations. Specifically, EBC’s identity-based
 variablization and constraint tracking/enforcement has eliminated the core
 source of this issue.
 
 The nature of EBC’s algorithm does add two new situations in which rules may
-become over- specialized. Section 4.6.16 discusses how variables used in certain
+become over-specialized. Section 4.6.16 discusses how variables used in certain
 RHS functions need to be literalized to maintain correctness, which can cause
 overspecialization. Section 4.6.7 discusses how testing or augmenting a previous
 result creates non-operational rules that require repair, a process which may
@@ -988,7 +988,7 @@ may consist of exhaustively applying all the operators in the problem space. If
 so, then a convenient way to recognize that all operators have applied and
 processing is complete is to wait for a state no-change impasse to occur. When
 the impasse occurs, a production can test for the resulting substate and create
-a result for the original subgoal. This form of state test builds over- general
+a result for the original subgoal. This form of state test builds over-general
 chunks because no pre-existing structure is relevant to the result that
 terminates the subgoal. The result is dependent only on the existence of the
 substate within a substate.
@@ -1026,7 +1026,7 @@ create its own distinct result in the superstate. Since this is different
 behavior than the original substate, this rule would be considered incorrect.
 
 If it were possible, EBC should learn a disjunctive conjunctive condition, with
-each dis- junction being the superstate conditions tested by each substate rule
+each disjunction being the superstate conditions tested by each substate rule
 that had previously created the substate WME that was repeatedly asserted. This
 is why this potential source of incorrect rules is called disjunctive context
 conflation.
@@ -1230,7 +1230,7 @@ conditions is true:
     from being formed if the problem-solving that led to the result was
     dependent on a condition that tested whether a subgoal WME doesn’t exist.
     Since there is no practical way to determine why a piece of knowledge
-    doesn’t exist, testing a local negation can result in an over- general and
+    doesn’t exist, testing a local negation can result in an over-general and
     incorrect chunk, cf. [prohibiting known sources for correctness issues](04_ProceduralKnowledgeLearning.md#prohibiting-known-sources-of-correctness-issues)
     for more information. Note that correctness filters have not yet been
     implemented for all the identified potential sources of correctness issues.
@@ -1737,7 +1737,7 @@ transitive constraints were added to a particular chunk.
 ### explain identity
 
 explain identity will show the mappings from variable identities to identity
-sets. If avail- able, the variable in a chunk that an identity set maps to will
+sets. If available, the variable in a chunk that an identity set maps to will
 also be displayed.
 
 By default, only identity sets that appear in the chunk will be displayed in the
@@ -1828,7 +1828,7 @@ The `visualize` command can generate two graphical representations of the
 analysis that chunking performed to learn a rule. While the explainer provides
 more date, these images are the easiest and most effective ways to quickly
 understand how a chunk was formed, especially for particularly complex chunks.
-The visualizer can create two types of chunking- related images:
+The visualizer can create two types of chunking-related images:
 
 1.  An image that shows the entire instantiation graph at once and how it
     contributed to the learned rule. Use the command visualize ebc analysis to

docs/soar_manual/05_ReinforcementLearning.md

@@ -345,7 +345,7 @@ for that operator are only affected by the rewards collected on the `reward-link
 for Sand the $Q$-values of subsequent RL operators selected in `S`.
 
 The only exception to this independence is when a selected RL operator forces an
-operator- no-change impasse. When this occurs, the number of decision cycles the
+operator-no-change impasse. When this occurs, the number of decision cycles the
 RL operator at the superstate remains selected is dependent upon the processing
 in the impasse state. Consider the operator trace in the following figure:
 
@@ -442,7 +442,7 @@ determines how operators are selected based on their
 numeric-indifferent preferences. Although all the indifferent selection
 settings are valid regardless of how the numeric-indifferent preferences were
 arrived at, the `epsilon-greedy` and `boltzmann` settings are specifically designed
-for use with RL and cor- respond to the two most common exploration strategies.
+for use with RL and correspond to the two most common exploration strategies.
 In an effort to maintain backwards compatibility, the default exploration
 policy is `softmax`. As a result, one should change to `epsilon-greedy` or
 `boltzmann` when the reinforcement learning mechanism is enabled.

docs/soar_manual/06_SemanticMemory.md

@@ -4,7 +4,7 @@
 # Semantic Memory
 
 Soar’s semantic memory is a repository for long-term declarative knowledge,
-supplement- ing what is contained in short-term working memory (and production
+supplementing what is contained in short-term working memory (and production
 memory). Episodic memory, which contains memories of the agent’s experiences,
 is described in [Chapter 7](./07_EpisodicMemory.md). The knowledge encoded in
 episodic memory is organized temporally, and specific information is embedded
@@ -200,7 +200,7 @@ and querying of knowledge. The semantic store can be maintained in memory or on
 disk (per the database and path parameters; see
 [`smem` command](../reference/cli/cmd_smem.md)). If the store is located on
 disk, users can use any standard SQLite programs/components to access/query its
-contents. However, using a disk- based semantic store is very costly
+contents. However, using a disk-based semantic store is very costly
 (performance is discussed in greater detail in Section
 [Performance](#performance)), and running in memory is recommended for most
 runs.
@@ -354,7 +354,7 @@ augmentations include other LTIs in smem, they too are instantiated into new
 short-term identifiers in working memory.
 
 It is possible that multiple long-term identifiers match the cue equally well.
-In this case, se- mantic memory will retrieve the long-term identifier that was
+In this case, semantic memory will retrieve the long-term identifier that was
 most recently stored/retrieved. (More accurately, it will retrieve the LTI with
 the greatest activation value. See below.)
 
@@ -472,8 +472,8 @@ Spreading activation values are updated each decision cycle only as needed for
 specific smem retrievals. For efficiency, two limits exist for the amount of
 spread calculated. The `spreading-limit` parameter limits how many LTIs can
 receive spread from a given spreading source LTI. By default, this value is
-(300). Spread is distributed in a magnitude- first manner to all descendants of
-a source. (Without edge-weights, this simplifies to breadth- first.) Once the
+(300). Spread is distributed in a magnitude-first manner to all descendants of
+a source. (Without edge-weights, this simplifies to breadth-first.) Once the
 number of LTIs that have been given spread from a given source reaches the max
 value indicated by `spreading-limit`, no more is calculated for that source that
 update cycle, and the next spreading source’s contributions are calculated. The
@@ -614,7 +614,7 @@ suggests to SQLite how many pages are available for the cache. Total cache size
 is the product of these two parameter settings. The cache memory is not pre-
 allocated, so short/small runs will not necessarily make use of this space.
 Generally speaking, a greater number of cache pages will benefit query time, as
-SQLite can keep necessary meta- data in memory. However, some documented
+SQLite can keep necessary meta-data in memory. However, some documented
 situations have shown improved performance from decreasing cache pages to
 increase memory locality. This is of greater concern when dealing with
 file-based databases, versus in-memory. The size of each page, however, may be
@@ -636,7 +636,7 @@ for writes to complete before continuing execution. Second, transaction
 journaling is turned off (journalmode pragma), thus groups of modifications to
 the semantic store are not atomic (and thus interruptions due to
 application/os/hardware failure could lead to inconsistent database state).
-Finally, upon initialization, semantic mem- ory maintains a continuous exclusive
+Finally, upon initialization, semantic memory maintains a continuous exclusive
 lock to the database (locking mode pragma), thus other applications/agents
 cannot make simultaneous read/write calls to the database (thereby reducing the
 need for potentially expensive system calls to secure/release file locks).