Merge pull request #59 from jaredhoberock/issue-56

Fix typos reported by Alisdair

Author: jaredhoberock

algorithms.html

@@ -127,7 +127,7 @@ <h1>Header <code>&lt;experimental/algorithm&gt;</code> synopsis</h1>
 
 // Exposition only: Suppress template argument deduction.
 template&lt;class T&gt; struct no_deduce { using type = T; };
-template&lt;class T&gt; struct no_dedu<ins>c</ins><del>d</del>e_t = typename no_deduce&lt;T&gt;::type;
+template&lt;class T&gt; using no_deduce_t = typename no_deduce&lt;T&gt;::type;
 
 <cxx-ref insynopsis="" to="parallel.alg.reductions"></cxx-ref> Support for reductions
 template&lt;class T, class BinaryOperation&gt;
@@ -465,7 +465,7 @@ <h1>No vec</h1>
 auto no_vec(F&amp;&amp; f) noexcept -&gt; decltype(std::forward&lt;F&gt;(f)());</cxx-signature>
 
         <cxx-effects>
-          Evaluates <code>std::forward&gt;F&lt;(f)()</code>. When invoked within an element access function
+          Evaluates <code>std::forward&lt;F&gt;(f)()</code>. When invoked within an element access function
           in a parallel algorithm using <code>vector_policy</code>, if two calls to <code>no_vec</code> are
           horizontally matched within a wavefront application of an element access function over input
           sequence S, then the execution of <code>f</code> in the application for one element in S is
@@ -502,6 +502,7 @@ <h1>No vec</h1>
       <h1>Ordered update class</h1>
 
 <pre>
+template&lt;class T&gt;
 class ordered_update_t {
   T&amp; ref_; // exposition only
 public:

execution_policies.html

@@ -50,9 +50,9 @@ <h1>Vector execution policy</h1>
 class vector_policy{ <i>unspecified</i> };
 </pre>
 
-    <p>The class <code>vector_policy</code> is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be vectorized. Additionally, such vectorization will result in an execution that respects the sequencing constraints of wavefront application ([parallel.alg.general.wavefront]). <cxx-note>The implementation thus makes stronger guarantees than for <code>unsequenced_policy</code>, for example.</cxx-note></p>
+    <p>The class <code>vector_policy</code> is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be vectorized. Additionally, such vectorization will result in an execution that respects the sequencing constraints of wavefront application (<a href="#parallel.alg.general.wavefront">[parallel.alg.general.wavefront]</a>). <cxx-note>The implementation thus makes stronger guarantees than for <code>unsequenced_policy</code>, for example.</cxx-note></p>
 
-    <p>The invocations of element access functions in parallel algorithms invoked with an execution policy of type <code>vector_policy</code> are permitted to execute in unordered fashion in the calling thread, unsequenced with respect to one another within the calling thread, subject to the sequencing constraints of wavefront application (<cxx-ref to="parallel.alg.general.wavefront"></cxx-ref>) for the last argument to <code>for_loop</code>, <code>for_loop_n</code>, <code>for_loop_strided</code>, or <code>for_loop_strided_n</code>.</p>
+    <p>The invocations of element access functions in parallel algorithms invoked with an execution policy of type <code>vector_policy</code> are permitted to execute in unordered fashion in the calling thread, unsequenced with respect to one another within the calling thread, subject to the sequencing constraints of wavefront application (<a href="#parallel.alg.general.wavefront">[parallel.alg.general.wavefront]</a>) for the last argument to <code>for_loop</code>, <code>for_loop_n</code>, <code>for_loop_strided</code>, or <code>for_loop_strided_n</code>.</p>
 
     <p>During the execution of a parallel algorithm with the <code>experimental::execution::vector_policy</code> policy, if the invocation of an element access function exits via an uncaught exception, <code>terminate()</code> will be called.</p>