Fixed typos and phrasing.

CONTRIBUTING.rst

@@ -19,7 +19,7 @@ Making pull requests
 If you want to fix a bug or add a feature to Nengo SPA, we welcome pull
 requests.  We try to maintain 100% test coverage, so any new features should
 also include unit tests to cover that change.  If you fix a bug it's also a good
-idea to add a unit test, so that the bug doesn't get un-fixed in the future!
+idea to add a unit test, so the bug doesn't get un-fixed in the future!
 
 Contributor agreement
 ---------------------

docs/dev_syntax.rst

@@ -90,7 +90,7 @@ networks. For this, `nengo_spa.Network` derives from `.SpaOperatorMixin` which:
 
 Furthermore, the operators need to be overloaded for the input and outputs of
 a SPA network. These will be basic Nengo objects and should continue to be
-useable as such. Thus, the `.Network.declare_input` and
+usable as such. Thus, the `.Network.declare_input` and
 `.Network.declare_output` methods will dynamically insert `.SpaOperatorMixin`
 into the inheritance list of a single instance. They also register the
 associated vocabulary for the type checking.

docs/examples/intro.ipynb

@@ -478,7 +478,7 @@
      "source": [
       "## Vocabularies\n",
       "\n",
-      "Sometimes you will have sets of unrelated Semantic Pointers. It can be useful to keep them in distinct groups called *vocabularies*. You can create a vocabulary by instantiating a `spa.Vocabulary` object with the desired dimensionality. To fill it with Semantic Pointers, you can use the `populate` method which takes a string of Semantic Pointer names separeted with semicolons. The vocabulary object will try to keep the maximum similarity between all pointers below a certain threshold (0.1 by default)."
+      "Sometimes you will have sets of unrelated Semantic Pointers. It can be useful to keep them in distinct groups called *vocabularies*. You can create a vocabulary by instantiating a `spa.Vocabulary` object with the desired dimensionality. To fill it with Semantic Pointers, you can use the `populate` method which takes a string of Semantic Pointer names separated with semicolons. The vocabulary object will try to keep the maximum similarity between all pointers below a certain threshold (0.1 by default)."
      ]
     },
     {
@@ -710,7 +710,7 @@
      "cell_type": "markdown",
      "metadata": {},
      "source": [
-      "The default vocabularies in Nengo SPA that are being used whenever you just specifiy the dimensionality for a module will be in non-strict mode."
+      "The default vocabularies in Nengo SPA that are being used whenever you just specify the dimensionality for a module will be in non-strict mode."
      ]
     },
     {
@@ -786,7 +786,7 @@
       "\n",
       "An associative memory needs to be provided with a vocabulary of all potential vectors that it could clean up to. In this example it is the colors `BLUE` and `RED`, but not `CIRCLE` and `SQUARE`. How to create vocabularies has been shown in the previous section. Here we use a slight variation on this. We acquire the *d*-dimension default vocabulary with `model.vocabs[d]` and create subset with the desired vectors from it.\n",
       "\n",
-      "Note that this subset is considered to be a different vocabulary than the default vocabulary itself. That means a simple `result >> am` will not work. But we know that both vocabularies use exactly the same vectors (because we created one as subset from the other) and thus can reinterpret the Semantic Pointer from `result` in the subset vocabulary. This is done with `spa.reinterpret(result) >> am`. In this case we do not need to provide the vocabulary as argument to `spa.reinterpret` because it can be determined from the context. Keep in mind that this might not work in all cases and give an exception. Then you have to explicitely add the vocabulary as argument to `spa.reinterpret`."
+      "Note that this subset is considered to be a different vocabulary than the default vocabulary itself. That means a simple `result >> am` will not work. But we know that both vocabularies use exactly the same vectors (because we created one as subset from the other) and thus can reinterpret the Semantic Pointer from `result` in the subset vocabulary. This is done with `spa.reinterpret(result) >> am`. In this case we do not need to provide the vocabulary as argument to `spa.reinterpret` because it can be determined from the context. Keep in mind that this might not work in all cases and give an exception. Then you have to explicitly add the vocabulary as argument to `spa.reinterpret`."
      ]
     },
     {

docs/examples/intro_coming_from_legacy_spa.ipynb

@@ -817,7 +817,7 @@
      "source": [
       "## Vocabularies\n",
       "\n",
-      "Nengo_spa behaves a lot like legacy SPA when providing dimensionalities only. Vocabularies will implicitely be created according to the specified dimensions and Semantic Pointers will be automatically added. When creating a vocabulary explicitely, things are a little bit different. In that case the vocabulary will be in strict-mode by default. That means an exception will be raised when trying to parse a Semantic Pointer that is not in the vocabulary. This is to prevent accidentally adding new Semantic Pointers (something that tendend to happen with the associative memmory in legacy SPA) and can make it easier to notice typing errors."
+      "Nengo_spa behaves a lot like legacy SPA when providing dimensionalities only. Vocabularies will implicitly be created according to the specified dimensions and Semantic Pointers will be automatically added. When creating a vocabulary explicitly, things are a little bit different. In that case the vocabulary will be in strict-mode by default. That means an exception will be raised when trying to parse a Semantic Pointer that is not in the vocabulary. This is to prevent accidentally adding new Semantic Pointers (something that tendend to happen with the associative memmory in legacy SPA) and can make it easier to notice typing errors."
      ]
     },
     {
@@ -880,7 +880,7 @@
      "cell_type": "markdown",
      "metadata": {},
      "source": [
-      "The new `populate` method is much more powerful than adding pointers with `parse`. For example you can use existing Semantic pointers to construct new ones and you can use transforms as `normalized()` and `unitary()` to make vectors unit length or normalized. Note that a simple Semantic Pointer will be normalized, but you need to explicitely do this when constructing a pointer out of others.\n",
+      "The new `populate` method is much more powerful than adding pointers with `parse`. For example you can use existing Semantic pointers to construct new ones and you can use transforms as `normalized()` and `unitary()` to make vectors unit length or normalized. Note that a simple Semantic Pointer will be normalized, but you need to explicitly do this when constructing a pointer out of others.\n",
       "\n",
       "In the following example we create a vocabulary with four pointers *A*, *B*, *C*, and *D*. *A* is made unitary, D is constructed from other vectors and normalized."
      ]
@@ -901,7 +901,7 @@
      "cell_type": "markdown",
      "metadata": {},
      "source": [
-      "Another new and sometimes useful method is `parse_n` which allows to parse multiple Semantic Pointer expressions at once. This can be useful for programatically constructing a list of pointers for plotting. The following example demonstrates that for all convolution pairs. It also shows that when using a predefined vocabulary, the modules will obtain their dimensionality from that vocabulary. No need to pass dimensionality and vocabulary anymore!"
+      "Another new and sometimes useful method is `parse_n` which allows to parse multiple Semantic Pointer expressions at once. This can be useful for programmatically constructing a list of pointers for plotting. The following example demonstrates that for all convolution pairs. It also shows that when using a predefined vocabulary, the modules will obtain their dimensionality from that vocabulary. No need to pass dimensionality and vocabulary anymore!"
      ]
     },
     {

docs/examples/spa_sequence_routed.ipynb

@@ -36,7 +36,7 @@
      "cell_type": "markdown",
      "metadata": {},
      "source": [
-      "This demo uses the basal ganglia model to cycle through a 5 element sequence, where an arbitrary start can be presented to the model. The addition of routing allows the system to choose between two different actions: whether to go through the sequence, or be driven by the visual input. If the visual input has its value set to 0.8*START+D (for instance), it will begin cycling through at D$\\rightarrow$E, etc. The 0.8 scaling helps ensure start is unlikely to accidently match other SPAs (which can be a problem in low dimensional examples like this one)."
+      "This demo uses the basal ganglia model to cycle through a 5 element sequence, where an arbitrary start can be presented to the model. The addition of routing allows the system to choose between two different actions: whether to go through the sequence, or be driven by the visual input. If the visual input has its value set to 0.8*START+D (for instance), it will begin cycling through at D$\\rightarrow$E, etc. The 0.8 scaling helps ensure start is unlikely to accidentally match other SPAs (which can be a problem in low dimensional examples like this one)."
      ]
     },
     {

docs/getting_started.rst

@@ -15,7 +15,7 @@ nengo_spa`` again.
 
 Nengo SPA only depends on `core Nengo
 <https://pythonhosted.org/nengo/index.html>`_ (which depends on `NumPy
-<http://www.numpy.org/>`_). Please check the `Nengo documenation
+<http://www.numpy.org/>`_). Please check the `Nengo documentation
 <https://pythonhosted.org/nengo/getting_started.html#installation>`_ for
 instructions on how to install Nengo or NumPy.
 

docs/user_guide/spa_intro.rst

@@ -126,8 +126,8 @@ Matrix <https://en.wikipedia.org/wiki/Raven's_Progressive_Matrices>`_ task,
 which requires people to figure out a pattern in the input, and apply that
 pattern to new input to produce novel output. For instance given the following
 input ``[1] [11] [111] [2n [22] [222] [3] [33] ?`` the expected answer is
-``333``. The input to the model first indicates which task it is going to
-preform by presenting it with an ``A`` followed by the task number (e.g. ``A 7``
+``333``. The input to the model first indicates which task it will
+perform by presenting it with an ``A`` followed by the task number (e.g. ``A 7``
 for this task). Then it is shown a series of letters and brackets and it has to
 draw the correct answer with its arm. The processing for such a task goes
 something like this:
@@ -164,7 +164,7 @@ something like this:
 .. figure:: spa_2.png
    :alt: Example input and output from Spaun.
 
-   Exapmle input and output from Spaun. a) Handwritten numbers used as input.
+   Example input and output from Spaun. a) Handwritten numbers used as input.
    b) Numbers drawn by Spaun using its arm.
 
 All of the control-like steps (e.g. “compared with”, “inferred”, and routing

nengo_spa/ast/base.py

@@ -38,7 +38,7 @@ def connect_to(self, sink, **kwargs):
         sink : NengoObject
             Nengo object to connect to and transmit the result to.
         kwargs : dict
-            Additional keyword arguments to pass to `nengo.Conenction`.
+            Additional keyword arguments to pass to `nengo.Connection`.
         """
         raise NotImplementedError()