Fix math tags

Author: bnmnetp

pretext/Advanced/DictionariesRevisited.ptx

@@ -54,11 +54,11 @@
  set of keys and a hash function, we could place the keys in a collection
  that allowed us to search and retrieve the associated data value. Our
  analysis showed that this technique could potentially yield an
- <math>O(1)</math> search. However, performance degraded due to issues such as
+ <m>O(1)</m> search. However, performance degraded due to issues such as
  table size, collisions, and collision resolution strategy.</p>
  <p>In Chapter&#xA0;<url href="#trees" visual="#trees">[trees]</url> we considered a binary search tree as a
  way to store such a collection. In this case the keys were placed in the
- tree such that searching could be done in <math>O(\log n)</math>. However,
+ tree such that searching could be done in <m>O(\log n)</m>. However,
  this was only true if the tree was balanced; that is, the left and the
  right subtrees were all of similar size. Unfortunately, depending on the
  order of insertion, the keys could end up being skewed to the right or
@@ -411,39 +411,39 @@
  <subsubsection xml:id="advanced_analysis-of-a-skip-list">
  <title>Analysis of a Skip List</title>
  <p>If we had simply stored the key-value pairs in an ordered linked list,
- we know that the search method would be <math>O(n)</math>. Can we expect
+ we know that the search method would be <m>O(n)</m>. Can we expect
  better performance from the skip list? Recall that the skip list is a
  probabilistic data structure. This means that the analysis will be
  dependent upon the probability of some event, in this case, the flip of
  a coin. Although a rigorous analysis of this structure is beyond the
  scope of this text, we can make a strong informal argument.</p>
- <p>Assume that we are building a skip list for <math>n</math> keys. We know that
+ <p>Assume that we are building a skip list for <m>n</m> keys. We know that
  each tower starts off with a height of 1. As we add data nodes to the
  tower, assuming the probability of getting heads is
- <math>\frac{1}{2}</math>, we can say that <math>\frac{n}{2}</math> of the keys
- have towers of height 2. As we flip the coin again, <math>\frac{n}{4}</math>
+ <m>\frac{1}{2}</m>, we can say that <m>\frac{n}{2}</m> of the keys
+ have towers of height 2. As we flip the coin again, <m>\frac{n}{4}</m>
  of the keys have a tower of height 3. This corresponds to the
  probability of flipping two heads in a row. Continuing this argument
- shows <math>\frac{n}{8}</math> keys have a tower of height 4 and so on. This
+ shows <m>\frac{n}{8}</m> keys have a tower of height 4 and so on. This
  means that we expect the height of the tallest tower to be
- <math>\log_{2}(n) + 1</math>. Using our Big-O notation, we would say that
- the height of the skip list is <math>O(\log (n))</math>.</p>
+ <m>\log_{2}(n) + 1</m>. Using our Big-O notation, we would say that
+ the height of the skip list is <m>O(\log (n))</m>.</p>
  <p>To analyze the <c>search</c> method, recall that there are two scans that
  need to be considered as we look for a given key. The first is the down
  direction. The previous result suggests that in the worst case we will
- expect to consider <math>O(\log (n))</math> levels to find a key. In
+ expect to consider <m>O(\log (n))</m> levels to find a key. In
  addition, we need to include the number of forward links that need to be
  scanned on each level. We drop down a level when one of two events
  occurs. Either we find a data node with a key that is greater than the
  key we are looking for or we find the end of a level. If we are
  currently looking at some data node, the probability that one of those
- two events will happen in the next link is <math>\frac{1}{2}</math>. This
+ two events will happen in the next link is <m>\frac{1}{2}</m>. This
  means that after looking at two links, we would expect to drop to the next
  lower level (we expect to get heads after two coin flips). In any case,
  the number of nodes that we need to look at on any given level is
- constant. The entire result then becomes <math>O(\log (n))</math>. Since
+ constant. The entire result then becomes <m>O(\log (n))</m>. Since
  inserting a new node is dominated by searching for its location, the
- <c>insert</c> operation will also have <math>O(\log(n))</math> performance.</p>
+ <c>insert</c> operation will also have <m>O(\log(n))</m> performance.</p>
  </subsubsection>
  </subsection>
 </section>

pretext/Advanced/GraphsRevisited.ptx

@@ -97,18 +97,18 @@
  Line&#xA0;<url href="#lst_simplematcher:line_patternended" visual="#lst_simplematcher:line_patternended">[lst_simplematcher:line_patternended]</url>
  checks to see if every character in the pattern has been processed. If
  so, a match has been found and we return its starting index.</p>
- <p>If we assume that the length of the text is <math>n</math> characters and the
- length of the pattern is <math>m</math> characters, then it is easy to see
- that the complexity of this approach is <math>O(nm)</math>. For each of the
- <math>n</math> characters we may have to compare against almost all <math>m</math>
- of the pattern characters. This is not so bad if the size of <math>n</math>
- and <math>m</math> are small. However, if we are considering thousands (or
+ <p>If we assume that the length of the text is <m>n</m> characters and the
+ length of the pattern is <m>m</m> characters, then it is easy to see
+ that the complexity of this approach is <m>O(nm)</m>. For each of the
+ <m>n</m> characters we may have to compare against almost all <m>m</m>
+ of the pattern characters. This is not so bad if the size of <m>n</m>
+ and <m>m</m> are small. However, if we are considering thousands (or
  perhaps millions) of characters in our text in addition a large
  pattern, it will be necessary to look for a better approach.</p>
  </subsection>
  <subsection xml:id="advanced_using-graphs-finite-state-automata">
  <title>Using Graphs: Finite State Automata</title>
- <p>It is possible to create an <math>O(n)</math> pattern matcher if we are
+ <p>It is possible to create an <m>O(n)</m> pattern matcher if we are
  willing to do some preprocessing with the pattern. One approach is to
  build what is known as a <term>deterministic finite automaton</term>, or <term>DFA</term>,
  that represents the pattern as a graph. Each vertex of the <term>DFA graph</term>
@@ -154,7 +154,7 @@
  <image source="Advanced/Figures/steptable.png" width="50%" alt="A Trace of the DFA Pattern Matcher" height="2.75in"/>
  </figure>
  <p>Since every character from the text is used once as input to the DFA
- graph, the complexity of this approach is <math>O(n)</math>. However, we need
+ graph, the complexity of this approach is <m>O(n)</m>. However, we need
  to take into account the preprocessing step that builds the DFA. There
  are many well-known algorithms for producing a DFA graph from a pattern.
  Unfortunately, all of them are quite complex mostly due to the fact that
@@ -261,8 +261,8 @@
  The method begins by augmenting the pattern so that the indices on the
  characters match the vertex labels in the KMP graph. Since the initial
  state is state 0, we have used the <c>'0'</c> symbol as a placeholder. Now the
- characters 1 to <math>m</math> in the augmented pattern correspond directly
- with the states 1 to <math>m</math> in the graph.</p>
+ characters 1 to <m>m</m> in the augmented pattern correspond directly
+ with the states 1 to <m>m</m> in the graph.</p>
  <p>Line&#xA0;<url href="#lst_mismatchedlinks:line_initdict" visual="#lst_mismatchedlinks:line_initdict">[lst_mismatchedlinks:line_initdict]</url>
  creates the first dictionary entry, which is always a transition from
  vertex 1 back to the initial state where a new character is
@@ -288,7 +288,7 @@
  <image source="Advanced/Figures/steptable2.png" width="50%" alt="A Trace of the KMP Pattern Matcher" height="3in"/>
  </figure>
  <p>As with the DFA graph from the previous section, KMP pattern matching is
- <math>O(n)</math> since we process each character of the text string.
+ <m>O(n)</m> since we process each character of the text string.
  However, the KMP graph is much easier to construct and requires much
  less storage as there are only two transitions from every vertex.</p>
  </subsection>

pretext/Advanced/PythonListsRevisited.ptx

@@ -22,8 +22,8 @@
  array. The array only supports two operations: indexing and assignment
  to an array index.</p>
  <p>The best way to think about an array is that it is one continuous block
- of bytes in the computer's memory. This block is divided up into <math>n</math>-byte
- chunks where <math>n</math> is based on the data type that is stored in the array.
+ of bytes in the computer's memory. This block is divided up into <m>n</m>-byte
+ chunks where <m>n</m> is based on the data type that is stored in the array.
  Figure&#xA0;<url href="#fig_array" visual="#fig_array">1</url> illustrates the idea of an array that is sized
  to hold six floating point values.</p>
  <figure align="" xml:id="fig-array">
@@ -42,8 +42,8 @@
  <p>For example, suppose that our array starts at location <c>0x000040</c>,
  which is 64 in decimal. To calculate the location of the object at
  position 4 in the array we simply do the arithmetic:
- <math>64 + 4 \cdot 8 = 96</math>. Clearly this kind of calculation is
- <math>O(1)</math>. Of course this comes with some risks. First, since
+ <m>64 + 4 \cdot 8 = 96</m>. Clearly this kind of calculation is
+ <m>O(1)</m>. Of course this comes with some risks. First, since
  the size of an array is fixed, one cannot just add things on to the end of
  the array indefinitely without some serious consequences. Second, in
  some languages, like C, the bounds of the array are not even checked, so
@@ -77,20 +77,20 @@
  <p>
  <ul>
  <li>
- <p>Accessing an itema at a specific location is <math>O(1)</math>.</p>
+ <p>Accessing an itema at a specific location is <m>O(1)</m>.</p>
  </li>
  <li>
- <p>Appending to the list is <math>O(1)</math> on average, but <math>O(n)</math> in
+ <p>Appending to the list is <m>O(1)</m> on average, but <m>O(n)</m> in
  the worst case.</p>
  </li>
  <li>
- <p>Popping from the end of the list is <math>O(1)</math>.</p>
+ <p>Popping from the end of the list is <m>O(1)</m>.</p>
  </li>
  <li>
- <p>Deleting an item from the list is <math>O(n)</math>.</p>
+ <p>Deleting an item from the list is <m>O(n)</m>.</p>
  </li>
  <li>
- <p>Inserting an item into an arbitrary position is <math>O(n)</math>.</p>
+ <p>Inserting an item into an arbitrary position is <m>O(n)</m>.</p>
  </li>
  </ul>
  </p>
@@ -142,13 +142,13 @@
  the new value is added to the list at <c>last_index</c>, and <c>last_index</c>
  is incremented by one.</p>
  <p>The <c>resize</c> method calculates a new size for the array using
- <math>2 ^ {size\_exponent}</math>. There are many methods that could be used
+ <m>2 ^ {size\_exponent}</m>. There are many methods that could be used
  for resizing the array. Some implementations double the size of the
  array every time as we do here, some use a multiplier of 1.5, and some
  use powers of two. Python uses a multiplier of 1.125 plus a constant.
  The Python developers designed this strategy as a good tradeoff for
  computers of varying CPU and memory speeds. The Python strategy leads to
- a sequence of array sizes of <math>0, 4, 8, 16, 24, 32, 40, 52, 64, 76\ldots</math> .
+ a sequence of array sizes of <m>0, 4, 8, 16, 24, 32, 40, 52, 64, 76\ldots</m> .
  Doubling the array size leads to a bit more wasted space at any
  one time, but is much easier to analyze. Once a new array has been
  allocated, the values from the old list must be copied into the new
@@ -161,45 +161,45 @@
  that in Python objects that are no longer referenced are automatically
  cleaned up by the garbage collection algorithm.</p>
  <p>Before we move on let's analyze why this strategy gives us an average
- <math>O(1)</math> performance for <c>append</c>. The key is to notice that most
- of the time the cost to append an item <math>c_i</math> is 1. The only time
+ <m>O(1)</m> performance for <c>append</c>. The key is to notice that most
+ of the time the cost to append an item <m>c_i</m> is 1. The only time
  that the operation is more expensive is when <c>last_index</c> is a power
  of 2. When <c>last_index</c> is a power of 2 then the cost to append an
- item is <math>O(last\_index)</math>. We can summarize the cost to insert the
- <math>i_{th}</math> item as follows:</p>
- <math_block docname="Advanced/PythonListsRevisited" label="True" nowrap="False" number="True" xml:space="preserve">c_i =
+ item is <m>O(last\_index)</m>. We can summarize the cost to insert the
+ <m>i_{th}</m> item as follows:</p>
+ <math_block docname="Advanced/PythonListsRevisited" nowrap="False" number="True" xml:space="preserve">c_i =
 \begin{cases}
  i \text{ if } i \text{ is a power of 2} \\
  1 \text{ otherwise}
 \end{cases}</math_block>
  <p>Since the expensive cost of copying <c>last_index</c> items occurs
  relatively infrequently we spread the cost out, or <em>amortize</em>, the
  cost of insertion over all of the appends. When we do this the cost of
- any one insertion averages out to <math>O(1)</math>. For example, consider
+ any one insertion averages out to <m>O(1)</m>. For example, consider
  the case where you have already appended four items. Each of these four
  appends costs you just one operation to store in the array that was
  already allocated to hold four items. When the fifth item is added a new
  array of size 8 is allocated and the four old items are copied. But now
  you have room in the array for four additional low cost appends.
  Mathematically we can show this as follows:</p>
- <math_block docname="Advanced/PythonListsRevisited" label="True" nowrap="False" number="True" xml:space="preserve">\begin{aligned}
+ <math_block docname="Advanced/PythonListsRevisited" nowrap="False" number="True" xml:space="preserve">\begin{aligned}
  cost_{total} &amp;= n + \sum_{j=0}^{\log_2{n}}{2^j} \\
  &amp;= n + 2n \\
  &amp;= 3n\end{aligned}</math_block>
  <p>The summation in the previous equation may not be obvious to you, so
- let's think about that a bit more. The sum goes from zero to <math>\log_2{n}</math>.
+ let's think about that a bit more. The sum goes from zero to <m>\log_2{n}</m>.
  The upper bound on the summation tells us how many times we
- need to double the size of the array. The term <math>2^j</math> accounts for
+ need to double the size of the array. The term <m>2^j</m> accounts for
  the copies that we need to do when the array is doubled. Since the total
- cost to append n items is <math>3n</math>, the cost for a single item is
- <math>3n/n = 3</math>. Because the cost is a constant we say that it is
- <math>O(1)</math>. This kind of analysis is called <term>amortized analysis</term> and
+ cost to append n items is <m>3n</m>, the cost for a single item is
+ <m>3n/n = 3</m>. Because the cost is a constant we say that it is
+ <m>O(1)</m>. This kind of analysis is called <term>amortized analysis</term> and
  is very useful in analyzing more advanced algorithms.</p>
  <p>Next, let us turn to the index operators.
  Listing&#xA0;<url href="#lst_arrindex" visual="#lst_arrindex">[lst_arrindex]</url> shows our Python
  implementation for index and assignment to an array location. Recall
  that we discussed above that the calculation required to find the memory
- location of the <math>i_{th}</math> item in an array is a simple <math>O(1)</math>
+ location of the <m>i_{th}</m> item in an array is a simple <m>O(1)</m>
  arithmetic expression. Even languages like C hide that calculation
  behind a nice array index operator, so in this case the C and the Python
  look very much the same. In fact, in Python it is very difficult to get
@@ -245,10 +245,10 @@ def __setitem__(self, idx, val):
  self.my_array[i + 1] = self.my_array[i]
  self.last_index += 1
  self.my_array[idx] = val</pre>
- <p>The performance of the insert is <math>O(n)</math> since in the worst case we
+ <p>The performance of the insert is <m>O(n)</m> since in the worst case we
  want to insert something at index 0 and we have to shift the entire
  array forward by one. On average we will only need to shift half of the
- array, but this is still <math>O(n)</math>. You may want to go back to
+ array, but this is still <m>O(n)</m>. You may want to go back to
  Chapter&#xA0;<url href="#basicds" visual="#basicds">[basicds]</url> and remind yourself how all of these
  list operations are done using nodes and references. Neither
  implementation is right or wrong; they just have different performance