Apply editorial corrections

Fixes #53

Author: jaredhoberock

algorithms.html

@@ -83,7 +83,7 @@ <h1>Wavefront Application</h1>
     <p>
       Let <i>f</i> be a function called for each argument list in a sequence of argument lists.
       <i>Wavefront application</i> of <i>f</i> requires that evaluation A<sub>i</sub> be sequenced
-      before evaluation B<sub>i</sub> if i &lt; j and and:
+      before evaluation B<sub><ins>j</ins><del>i</del></sub> if i &lt; j and and:
 
       <ul>
         <li>A<sub>i</sub> is sequenced before some evaluation B<sub>i</sub> and B<sub>i</sub> is horizontally matched with B<sub>j</sub>, or</li>
@@ -128,7 +128,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_dedude_t = typename no_deduce&lt;T&gt;::type;
+template&lt;class T&gt; struct no_dedu<ins>c</ins><del>d</del>e_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;
@@ -288,7 +288,7 @@ <h1>Reductions</h1>
           </thead>
         </table>
 
-        <cxx-example>The following code updates each element of <code>y</code> and sets <code>s</code> ot the sum of the squares.
+        <cxx-example>The following code updates each element of <code>y</code> and sets <code>s</code> <ins>to</ins><del>ot</del> the sum of the squares.
 <pre>
 extern int n;
 extern float x[], y[], a;
@@ -333,7 +333,7 @@ <h1>Inductions</h1>
 <em>unspecified</em> induction(T&amp;&amp; var, S stride);</cxx-signature>
 
         <cxx-returns>
-          an induction object with induction value type <code>remove_cv_t&gt;remove_reference_t&gt;T&lt;&lt;</code>,
+          an induction object with induction value type <code>remove_cv_t<ins>&lt;</ins><del>&gt;</del>remove_reference_t<ins>&lt;</ins><del>&gt;</del>T<ins>&gt;&gt;</ins><del>&lt;&lt;</del></code>,
           initial value <code>var</code>, and (if specified) stride <code>stride</code>. If <code>T</code> is an lvalue reference
           to non-<code>const</code> type, then the object referenced by <code>var</code> becomes the live-out object for the
           induction object; otherwise there is no live-out object.
@@ -425,13 +425,13 @@ <h1>For loop</h1>
           The first element in the input sequence is <code>start</code>. Each subsequent element is generated by adding
           <code>stride</code> to the previous element, if <code>stride</code> is specified, otherwise by incrementing
           the previous element. <cxx-note>As described in the C++ standard, section [algorithms.general], arithmetic
-          on non-random-access iterators is performed using advance and distance.</cxx-note> <cxx-note>The order of the
+          on non-random-access iterators is performed using <ins><code>advance</code></ins><del>advance</del> and <ins><code>distance</code></ins><del>distance</del>.</cxx-note> <cxx-note>The order of the
           elements of the input sequence is important for determining ordinal position of an application of <em>f</em>,
           even though the applications themselves may be unordered.</cxx-note></p>
 
           The first argument to <em>f</em> is an element from the input sequence. <cxx-note>if <code>I</code> is an
           iterator type, the iterators in the input sequence are not dereferenced before
-          being passed to <em>f</em>.</cxx-note> For each member of the rest parameter pack
+          being passed to <em>f</em>.</cxx-note> For each member of the <ins><code>rest</code></ins><del>rest</del> parameter pack
           excluding <em>f</em>, an additional argument is passed to each application of <em>f</em> as follows:
 
           <ul>

exceptions.html

@@ -27,7 +27,7 @@ <h1>Header <code>&lt;experimental/exception_list&gt;</code> synopsis</h1>
       </p>
 
       <p>
-        The type <code>exception_list::iterator</code> shall fulfill the requirements of
+        The type <code>exception_list::iterator</code> <ins>fulfills</ins><del>shall fulfill</del> the requirements of
         <code>ForwardIterator</code>.
       </p>
 

execution_policies.html

@@ -18,7 +18,7 @@ <h1>Header <code>&lt;experimental/execution&gt;</code> synopsis</h1>
 
   <cxx-ref insynopsis="" to="parallel.execpol.objects"></cxx-ref>
   inline constexpr unsequenced_policy unseq{ <i>unspecified</i> };
-  inline constexpr parallel_policy par{ <i>unspecified</i> };
+  inline constexpr <ins>vector_policy vec</ins><del>parallel_policy par</del>{ <i>unspecified</i> };
 }
 }
 }
@@ -39,7 +39,7 @@ <h1>Unsequenced execution policy</h1>
 
     <p><cxx-note>This overrides the usual guarantee from the C++ Standard, <cxx-ref in="cxx" to="intro.execution"></cxx-ref> [intro.execution] that function executions do not overlap with one another.</cxx-note></p>
 
-    <p>During the execution of a parallel algorithm with the <code>experimental::execution::unsequenced_policy</code> policy, if the invocation of an element access function exits via an uncaught exception, <code>terminate()</code> shall be called.</p>
+    <p>During the execution of a parallel algorithm with the <code>experimental::execution::unsequenced_policy</code> policy, if the invocation of an element access function exits via an uncaught exception, <code>terminate()</code> <ins>will</ins><del>shall</del> be called.</p>
 
   </cxx-section>
 
@@ -52,9 +52,9 @@ <h1>Vector execution policy</h1>
 
     <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 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> or <code>for_loop_strided</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 (<cxx-ref to="parallel.alg.general.wavefront"></cxx-ref>) for the last argument to <code>for_loop</code><ins>, for_loop_n,</ins> <del>or </del><code>for_loop_strided</code><ins>, 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> shall be called.</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> <ins>will</ins><del>shall</del> be called.</p>
 
   </cxx-section>