.
authorThomas Walker Lynch <eknp9n@reasoningtechnology.com>
Mon, 3 Aug 2026 08:12:09 +0000 (08:12 +0000)
committerThomas Walker Lynch <eknp9n@reasoningtechnology.com>
Mon, 3 Aug 2026 08:12:09 +0000 (08:12 +0000)
document/book/Arabic number fig 1.png [deleted file]
document/book/Arabic number fig 2.png [deleted file]
document/book/Arabic number fig 3.png [deleted file]
document/book/Arabic number fig 4.png [deleted file]
document/book/Hindu-Arabic number fig 1.png [new file with mode: 0644]
document/book/Hindu-Arabic number fig 2.png [new file with mode: 0644]
document/book/Hindu-Arabic number fig 3.png [new file with mode: 0644]
document/book/Hindu-Arabic number fig 4.png [new file with mode: 0644]
document/book/TM-2026.html

diff --git a/document/book/Arabic number fig 1.png b/document/book/Arabic number fig 1.png
deleted file mode 100644 (file)
index ea8cc48..0000000
Binary files a/document/book/Arabic number fig 1.png and /dev/null differ
diff --git a/document/book/Arabic number fig 2.png b/document/book/Arabic number fig 2.png
deleted file mode 100644 (file)
index 17fa599..0000000
Binary files a/document/book/Arabic number fig 2.png and /dev/null differ
diff --git a/document/book/Arabic number fig 3.png b/document/book/Arabic number fig 3.png
deleted file mode 100644 (file)
index 1f1935a..0000000
Binary files a/document/book/Arabic number fig 3.png and /dev/null differ
diff --git a/document/book/Arabic number fig 4.png b/document/book/Arabic number fig 4.png
deleted file mode 100644 (file)
index c2004e6..0000000
Binary files a/document/book/Arabic number fig 4.png and /dev/null differ
diff --git a/document/book/Hindu-Arabic number fig 1.png b/document/book/Hindu-Arabic number fig 1.png
new file mode 100644 (file)
index 0000000..ea8cc48
Binary files /dev/null and b/document/book/Hindu-Arabic number fig 1.png differ
diff --git a/document/book/Hindu-Arabic number fig 2.png b/document/book/Hindu-Arabic number fig 2.png
new file mode 100644 (file)
index 0000000..17fa599
Binary files /dev/null and b/document/book/Hindu-Arabic number fig 2.png differ
diff --git a/document/book/Hindu-Arabic number fig 3.png b/document/book/Hindu-Arabic number fig 3.png
new file mode 100644 (file)
index 0000000..1f1935a
Binary files /dev/null and b/document/book/Hindu-Arabic number fig 3.png differ
diff --git a/document/book/Hindu-Arabic number fig 4.png b/document/book/Hindu-Arabic number fig 4.png
new file mode 100644 (file)
index 0000000..c2004e6
Binary files /dev/null and b/document/book/Hindu-Arabic number fig 4.png differ
index a24a6c4..f169f17 100644 (file)
@@ -1775,11 +1775,165 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos
 
       <p>Consider the case of a partitioned tape. Then consider that we write a gasket, such that we have a higher level Turing Machine that considers each of the areas of the partition as a cell. So then, initially the Turing machine starts with its head on the leftmost area, stepping right steps to the right neighbor area etc. In this manner we abstract the concept of a cell to areas. A length then becomes a count of areas; however the <RT·term>size</RT·term> remains a count of the cells. Something similar is done in the C language, where the length of an array is a count of the elements in the array, but the size of the array is a count of bytes. A byte being an addressable unit in physical memory, and thus the underlying <em>cell</em> that everything is built up from.</p>
 
-      <RT·chapter>Hindu-Arabic representation</RT·chapter>
+      <RT·chapter>Natural Number</RT·chapter>
+
+
+      <h2>Unary representation</h2>
+
+      <p>
+        A person can define a Turing Machine that is identical to the recursive definition of Natural Numbers as given by Peano. <RT·endnote>Giuseppe Peano, <em>Arithmetices principia, nova methodo exposita</em> (Turin: Fratres Bocca, 1889).</RT·endnote> If a person were to run the Natural Number Machine and observe as it writes to the tape, that person would watch as the Natural Numbers are printed one after another: '·s·ss·sss·ssss· ...'. Here '·' represents zero, and 's·' represents one, etc. Because the Natural Number Machine never halts, the machine cannot be used to initialize a tape, but an analyzer can evaluate the machine to make conclusions about what it would write if it were run.
+      </p>
+
+      <p>
+        In contrast, a function extension version of the Natural Number sequence generator can be run. The function extension machine would be given as input a prior function extension result, or an initial empty tape. It would then modify the tape to contain the next Natural Number, as per the sequence that the Natural Number machine would write, if it could be run. This is accomplished through two subroutine calls: <RT·code>find_empty</RT·code> and <RT·code>increment</RT·code>. The <RT·code>find_empty</RT·code> machine checks the symbol under the head. Upon finding it is not the empty symbol, the machine steps right and checks the next cell, repeating until it finds the empty symbol, whereupon it halts. The <RT·code>increment</RT·code> machine then writes an 's' onto the tape and halts. Recurrent calls to the Natural Number extender then produce a sequence of result tapes: <RT·code>[], [s], [ss], …</RT·code>. Similarly, a programmer can write a machine called <RT·code>decrement</RT·code>, though the programmer must note that decrementing can return the <RT·code>left-of-leftmost</RT·code> symbol.
+      </p>
+
+      <p>
+        To say that Natural Number A is smaller than Natural Number B is to say that A would occur on the Natural Number Machine tape to the left of B, if the machine were run. Conversely, if B were said to be greater than A, that would mean B occurs further to the right. It is a simple matter for a programmer to write a decider machine for this. The decider is given two input tapes for the two numbers to compare, and it keeps a head on each. It then steps forward until neither head has an 's' under it. If empty symbols are found simultaneously on both tapes, then the two numbers are equal; otherwise, the number with an empty symbol under the head is the lesser number.
+      </p>
+
+      <p>
+        As such, a person can assign a Natural Number to each cell of a given tape by using a mechanical procedure. Given a machine, say <RT·code>P</RT·code>, and an address machine, say <RT·code>A_P</RT·code>, each time <RT·code>P</RT·code> is stepped right, a call is made to run <RT·code>increment</RT·code> on <RT·code>A_P</RT·code>. Similarly, each time <RT·code>P</RT·code> is stepped left, a call is made to run <RT·code>decrement</RT·code> on <RT·code>A_P</RT·code>. In this manner the tape on <RT·code>A_P</RT·code> will always hold the address that machine <RT·code>P</RT·code>'s head is on.
+      </p>
+
+      <p>
+        The Natural Number found on <RT·code>A_P</RT·code> is then called the address for the cell that machine <RT·code>P</RT·code>'s head is on. As each increment and decrement of the address is a constant time operation, keeping the address of the cell the head is on is computationally inconsequential.
+      </p>
+
+      <p>
+        An <RT·term>address space</RT·term> is a set of addresses for contiguous cells. The tape's address space is the set of addresses for all the cells on the tape. Typically the address of 0 is given to the leftmost among the contiguous cells.
+      </p>
+
+      <h2>Hindu-Arabic representation</h2>
 
       <p>Charles Burnett published a very interesting book about the translation of Hindu-Arabic mathematics in Europe during the Middle Ages <RT·endnote>Charles Burnett, <em>Numerals and Arithmetic in the Middle Ages</em> (Farnham: Ashgate Variorum, 2010). DOI: 10.33137/aestimatio.v9i0.25990.</RT·endnote>. He describes a 9th-century treatise on Hindu-Arabic arithmetic authored by Muḥammad ibn Mūsā al-Khwārizmī, where "al-Khwārizmī" indicated he was from Khwarazm in Central Asia. When this manuscript was translated into Latin in the 12th century, European translators approximated his name as Algoritmi or Algorismi, thus giving us the word algorithm. He notes that the Arabs called such numbers "Indian Numbers". Another chapter, "Why we read Arabic numerals backwards," shows that the <RT·term>little-endian</RT·term> and <RT·term>big-endian</RT·term> debate that has plagued programmers for decades has its origin in the Middle Ages <RT·endnote>Danny Cohen, "On Holy Wars and a Plea for Peace," <em>IEEE Computer</em> 14, no. 10 (October 1981): 48-54. DOI: 10.1109/C-M.1981.220208</RT·endnote>.</p>
 
-      <p>The information about ENIAC in this chapter is found in a 1947 IRE article, "Electronic Computing Circuits of the ENIAC" by Arthur W. Burks <RT·endnote>Arthur W. Burks, "Electronic Computing Circuits of the ENIAC," <em>Proceedings of the IRE</em> 35, no. 8 (August 1947): 756-767. DOI: 10.1109/JRPROC.1947.234265</RT·endnote>. I found it interesting that some of the design issues for flip-flops made of vacuum tubes resemble those of designing static RAM cells in CMOS. Although ENIAC's implementation is electronic, its architecture is fundamentally that of a mechanical machine.</p>
+
+      <p>The topological structure of a Hindue-Arabic representation is found embodied in a simple gear based machine called an odometer. Multiple geared wheels occur in a reticulated structure. Pushing a toggle advances the least significant digit wheel by 36 degrees of rotation. The wheel has a peg in it, such that if it rolls past 9 back to 0, it pushes the toggle on the next wheel in the reticulation sequence. The peg of the last wheel rotates through a toggle that raises the overflow error flag.  By its very construction, this process establishes a one-to-one correspondence between each Natural Number and a sequence of symbols in Arabic Representation.</p>
+
+
+      <p>
+        For this discussion, the Hindu-Arabic representation address is variable precision, so it will grow as the count becomes larger. The empty symbol will serve as the terminator.
+      </p>
+
+      <p>
+        For <RT·code>Hindu-Arabic_increment</RT·code>, the machine reads the cell under the head; upon finding a 0 or the terminator, it writes a 1 and halts. Upon finding a 1, it writes a 0, steps right, and repeats the procedure.
+      </p>
+
+      <RT·code>
+        increment:
+          a = TTU.read()
+          if a == 0 or a == □:
+            TTU.write(1)
+            halt
+          TTU.write(0)
+          TTU.step()
+          goto increment
+      </RT·code>
+
+      <p>Here <RT·code>TTU</RT·code> is the tape transport unit. It has the number to be incremented mounted on it. This number is either zero, which would mean the leftmost cell is empty, or it is of the same form as a result from a Natural Number extension machine. A <RT·code>TTU.read</RT·code> places a copy of the symbol instance found in the cell under the head into the read buffer automatically when the machine enters a new state on the programmed controller, so it is not counted as a step. In contrast, the other actions are associated with the state of the programmed controller, so when the machine arrives at a <RT·code>write</RT·code>, <RT·code>step</RT·code>, or <RT·code>halt</RT·code> node, it means that the programmed state controller has taken a step. Sequential instructions mean unconditional next state choices, whereas an <RT·code>if</RT·code> signals a conditional next state choice. The <RT·code>if</RT·code> condition is a logical proposition based on the read symbol.</p>
+
+      <p>The loop form here is worth taking note of, as it will come up again. The controller executes a first action, that of a <RT·code>read</RT·code>, followed by a middle break test, and then the recursive form actions.</p>
+
+      <p>
+        Each row shows an input tape, and actions taken to write the result tape. For any given row, the result tape is the same as the input tape on the next row down. The table lists 7 increments, which is sufficient to reach the maximum count that can be held by a 3 bit counter.
+      </p>
+
+      <table>
+        <tr>
+          <th>input</th>
+          <th>action</th>
+          <th>cost (steps)</th>
+        </tr>
+        <tr>
+          <td>0</td>
+          <td>write 1, halt (result is maximum 1 bit count)</td>
+          <td>2</td>
+        </tr>
+        <tr>
+          <td>1 </td>
+          <td>write 0, step, write 1, halt</td>
+          <td>4</td>
+        </tr>
+        <tr>
+          <td>01</td>
+          <td>write 1, halt (result is maximum 2 bit count)</td>
+          <td>2</td>
+        </tr>
+        <tr>
+          <td>11</td>
+          <td>write 0, step, write 0, step, write 1, halt</td>
+          <td>6</td>
+        </tr>
+        <tr>
+          <td>001</td>
+          <td>write 1, halt</td>
+          <td>2</td>
+        </tr>
+        <tr>
+          <td>101</td>
+          <td>write 0, step right, write 1, halt</td>
+          <td>4</td>
+        </tr>
+        <tr>
+          <td>011</td>
+          <td>write 1, halt (result is maximum 3 bit count)</td>
+          <td>2</td>
+        </tr>
+        <tr>
+          <td>111</td>
+          <td></td>
+          <td></td>
+        </tr>
+      </table>
+
+      <p>
+        The number of programmable controller state transition steps required to reach a maximum 1 bit, 2 bit, and 3 bit count are: <RT·math>[2, 8, 22]</RT·math>. Note these are cumulative. The three bit maximum count cost includes that of the two bit maximum count cost, etc. Each maximum count is exponentially larger, so a better measure is the average cost per step: <RT·math>[2/1, 8/3, 22/7] = [2, 2.667, 3.143]</RT·math>
+      </p>
+
+      <p>
+        For an <RT·math>n</RT·math> bit counter, the sequence of costs follows a pattern. Half of the increments evaluate one bit (costing 2 steps), a quarter evaluate two bits (costing 4 steps), an eighth evaluate three bits (costing 6 steps), and so forth, over the <RT·math>2^n - 1</RT·math> increments required to reach the maximum <RT·math>n</RT·math> bit count:
+      </p>
+
+      <RT·math> \sum_{k=1}^{n} 2k · 2^{n-k} = 2^{n+2} - 2n - 4</RT·math>
+
+      <p>
+        To find the average cost per increment to reach each maximum, an analyst divides by the total number of increments, which is <RT·math>2^n - 1</RT·math>:
+      </p>
+
+      <RT·math> \text{Average Cost} = \frac{2^{n+2} - 2n - 4}{2^n - 1} = \frac{4(2^n-1)+4-2n-4}{2^n-1}</RT·math>
+
+      <p>
+        This simplifies algebraically to:
+      </p>
+
+      <RT·math> \text{Average Cost} = 4 - \frac{2n}{2^n - 1} </RT·math>
+
+      <p>
+        As the address space grows, the bit width <RT·math>n</RT·math> increases. The polynomial term <RT·math>2n</RT·math> is outpaced by the exponential denominator <RT·math>2^n - 1</RT·math>, causing the fractional terms to converge to zero. The average work done by the machine head converges to exactly four tape actions per increment. Constant time, same as for unary. This is a surprising counter intuitive result.
+      </p>
+
+      <p>
+        Consequently, maintaining an Hindu-Arabic address on a secondary Address Machine remains a constant time operation in the amortized sense, making it computationally inconsequential to the complexity class of the base machine. However, if a problem were to increment and decrement repeatedly around a binary power count, the behavior would be the limiting logarithmic time due to the length of the counter. An unlucky situation like this is called <RT·term>aliasing</RT·term>.
+      </p>
+
+      <h2>The Computability of Length and Unbounded Zeros</h2>
+      <p>Consider the proposition of representing Natural Numbers with an unbounded sequence of leftward-trailing zero symbols, extending from the leftmost nonzero digit. If a Turing Machine attempts to evaluate the length of this number, or append a digit to the left of its most significant digit, the machine encounters a structural failure. Any algorithm that starts at the right of the sequence (the least significant digit) and scans leftward in search of the last non-zero digit can never be sure at any step that there isn't another non-zero digit further to the left, as those members of the sequence have not yet been examined.</p>
+
+      <p>Thus, an append function can never know where to write the appended digit, and a length function can never know when to end the count. Because these functions cannot be computed locally on a tape initialized with unbounded zeros, the viable Arabic Representation must strictly be a finite, growing sequence rather than an unbounded string of zeros. If an algorithm attempts to access an index greater than the extent of this finite sequence, the access function fails. This failure is itself a form of meta-information—information about the structure of the representation rather than the number it encodes.</p>
+
+      <h2>The Representation of Zero and Structural Emptiness</h2>
+      <p>In the growing Arabic representation, counting acts as a mechanical mechanism. In the case of zero, before the first increment, the mechanism has not yet encountered a carry-in. At this stage, no digits have materialized in the representation. Any attempt to retrieve a digit in this state results in an access violation.</p>
+
+      <p>This reveals a fundamental property of Arabic Representation: it encodes both the sequence of digit symbols (which map to a natural number) and the sequence's length (which exists at a meta level, governing computational operations). The representation of zero exposes a limitation. At zero, the representation retains length information necessary for computation but lacks an explicit numerical mapping to zero itself.</p>
+
+      <p>Structurally, this forces a design choice between two options:</p>
+      <ul>
+        <li>Using an empty sequence <RT·code>[]</RT·code> and arbitrarily mapping it to zero. This allows a length function to return zero naturally, as the empty sequence is never scanned.</li>
+        <li>Using a lone zero symbol <RT·code>[0]</RT·code>, which introduces an effective length concept where <RT·code>[0]</RT·code> must be treated as though it has zero length in algorithmic operations.</li>
+      </ul>
+
+      <p>Without explicit brackets, the empty sequence collapses into an empty space, conveying no meaning when written in conventional notation. To maintain visual clarity and avoid empty spaces where zero should appear, conventional architectures adopt the standard <RT·code>0</RT·code>. However, the length function must still return zero for <RT·code>[0]</RT·code>, despite its apparent length of one.</p>
 
       <h2>Numeric value</h2>
 
@@ -1799,6 +1953,8 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos
 
       <h2>Meaning of the word digital</h2>
 
+      <p>The information about ENIAC in this chapter is found in a 1947 IRE article, "Electronic Computing Circuits of the ENIAC" by Arthur W. Burks <RT·endnote>Arthur W. Burks, "Electronic Computing Circuits of the ENIAC," <em>Proceedings of the IRE</em> 35, no. 8 (August 1947): 756-767. DOI: 10.1109/JRPROC.1947.234265</RT·endnote>. I found it interesting that some of the design issues for flip-flops made of vacuum tubes resemble those of designing static RAM cells in CMOS. Although ENIAC's implementation is electronic, its architecture is fundamentally that of a mechanical machine.</p>
+
       <p>The first computing machines which performed discrete state computation made use of ten symbols for a digit’s potential values while mimicking how humans perform manual arithmetic. Examples include Pascal’s calculator, Babbage’s machine, the mechanical calculators that came after, Aiken’s Mark computers, and ENIAC.</p>
 
       <p>Mechanical machines used physical gears with ten positions, each being 36 degrees apart. An index, such as a metal pointer, pointed at one of the marks, indicating which digit value had been registered on the gear. To change which digit value was registered, the gear turned until the index pointed at the mark corresponding to the desired digit value. Instead of gears, the electronic computer ENIAC used circular shift registers of ten vacuum tube flip-flops. These were called ring counters or decade counters. ENIAC operated on ten-digit signed numbers, so there were ten such ring counters plus a flip-flop for each number. It is structurally important that a person does not conflate the number of available digit values with the length of the digit sequence.</p>
@@ -1865,53 +2021,37 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos
 
       <p>Writing such long strings is inefficient, so programmers group bits. When bits are grouped in threes, the base is eight instead of two. This is called octal notation, using one of the symbols 0, 1, 2, 3, 4, 5, 6, or 7 for the octal digit values.</p>
 
-      <table>
-        <thead>
-          <tr>
-            <th>octal</th>
-            <th>binary</th>
-          </tr>
-        </thead>
-        <tbody>
-          <tr><td>0</td><td>000</td></tr>
-          <tr><td>1</td><td>001</td></tr>
-          <tr><td>2</td><td>010</td></tr>
-          <tr><td>3</td><td>011</td></tr>
-          <tr><td>4</td><td>100</td></tr>
-          <tr><td>5</td><td>101</td></tr>
-          <tr><td>6</td><td>110</td></tr>
-          <tr><td>7</td><td>111</td></tr>
-        </tbody>
-      </table>
+      <RT·dictionary key="octal" definition="binary">
+        <RT·entry key="0">000</RT·entry>
+        <RT·entry key="1">001</RT·entry>
+        <RT·entry key="2">010</RT·entry>
+        <RT·entry key="3">011</RT·entry>
+        <RT·entry key="4">100</RT·entry>
+        <RT·entry key="5">101</RT·entry>
+        <RT·entry key="6">110</RT·entry>
+        <RT·entry key="7">111</RT·entry>
+      </RT·dictionary>
 
       <p>In the 1960s, computer panels featured switches and lights organized in threes, and coding forms were filled out in octal. Today, documents showing bit strings universally use groups of fours. Such a digit has 16 values, utilizing 0 through 9, and continuing with the letters a, b, c, d, e, and f. This is known as the hexadecimal system, often shortened to hex.</p>
 
-      <table>
-        <thead>
-          <tr>
-            <th>hex</th>
-            <th>binary</th>
-          </tr>
-        </thead>
-        <tbody>
-          <tr><td>0</td><td>0000</td></tr>
-          <tr><td>1</td><td>0001</td></tr>
-          <tr><td>2</td><td>0010</td></tr>
-          <tr><td>3</td><td>0011</td></tr>
-          <tr><td>4</td><td>0100</td></tr>
-          <tr><td>5</td><td>0101</td></tr>
-          <tr><td>6</td><td>0110</td></tr>
-          <tr><td>7</td><td>0111</td></tr>
-          <tr><td>8</td><td>1000</td></tr>
-          <tr><td>9</td><td>1001</td></tr>
-          <tr><td>a</td><td>1010</td></tr>
-          <tr><td>b</td><td>1011</td></tr>
-          <tr><td>c</td><td>1100</td></tr>
-          <tr><td>d</td><td>1101</td></tr>
-          <tr><td>e</td><td>1110</td></tr>
-          <tr><td>f</td><td>1111</td></tr>
-        </tbody>
-      </table>
+      <RT·dictionary key="hex" definition="binary">
+        <RT·entry key="0">0000</RT·entry>
+        <RT·entry key="1">0001</RT·entry>
+        <RT·entry key="2">0010</RT·entry>
+        <RT·entry key="3">0011</RT·entry>
+        <RT·entry key="4">0100</RT·entry>
+        <RT·entry key="5">0101</RT·entry>
+        <RT·entry key="6">0110</RT·entry>
+        <RT·entry key="7">0111</RT·entry>
+        <RT·entry key="8">1000</RT·entry>
+        <RT·entry key="9">1001</RT·entry>
+        <RT·entry key="a">1010</RT·entry>
+        <RT·entry key="b">1011</RT·entry>
+        <RT·entry key="c">1100</RT·entry>
+        <RT·entry key="d">1101</RT·entry>             8
+        <RT·entry key="e">1110</RT·entry>
+        <RT·entry key="f">1111</RT·entry>
+      </RT·dictionary>
 
       <p>The table of hexadecimal digits is twice as long as the table of octal digits because each added bit doubles the table size.</p>
 
@@ -1923,26 +2063,18 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos
 
       <p>Bits are also grouped to construct numbers with bases that are not powers of two. In the BCD code, bits are grouped in fours to form decimal digits.</p>
 
-      <table>
-        <thead>
-          <tr>
-            <th>BCD</th>
-            <th>binary</th>
-          </tr>
-        </thead>
-        <tbody>
-          <tr><td>0</td><td>0000</td></tr>
-          <tr><td>1</td><td>0001</td></tr>
-          <tr><td>2</td><td>0010</td></tr>
-          <tr><td>3</td><td>0011</td></tr>
-          <tr><td>4</td><td>0100</td></tr>
-          <tr><td>5</td><td>0101</td></tr>
-          <tr><td>6</td><td>0110</td></tr>
-          <tr><td>7</td><td>0111</td></tr>
-          <tr><td>8</td><td>1000</td></tr>
-          <tr><td>9</td><td>1001</td></tr>
-        </tbody>
-      </table>
+      <RT·dictionary key="BCD" definition="binary">
+        <RT·entry key="0">0000</RT·entry>
+        <RT·entry key="1">0001</RT·entry>
+        <RT·entry key="2">0010</RT·entry>
+        <RT·entry key="3">0011</RT·entry>
+        <RT·entry key="4">0100</RT·entry>
+        <RT·entry key="5">0101</RT·entry>
+        <RT·entry key="6">0110</RT·entry>
+        <RT·entry key="7">0111</RT·entry>
+        <RT·entry key="8">1000</RT·entry>
+        <RT·entry key="9">1001</RT·entry>
+      </RT·dictionary>
 
       <p>In BCD, some possible bit value combinations are unused. This is an unavoidable consequence of emulating a number base in binary switch logic when that base is not a power of 2.</p>
 
@@ -2046,143 +2178,10 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos
       <RT·chapter>Address</RT·chapter>
 
 
-      <h2>Unary Representation address</h2>
-
-      <p>
-        A person can define a Turing Machine that is identical to the recursive definition of Natural Numbers as given by Peano. <RT·endnote>Giuseppe Peano, <em>Arithmetices principia, nova methodo exposita</em> (Turin: Fratres Bocca, 1889).</RT·endnote> If a person were to run the Natural Number Machine and observe as it writes to the tape, that person would watch as the Natural Numbers are printed one after another: '·s·ss·sss·ssss· ...'. Here '·' represents zero, and 's·' represents one, etc. Because the Natural Number Machine never halts, the machine cannot be used to initialize a tape, but an analyzer can evaluate the machine to make conclusions about what it would write if it were run.
-      </p>
-
-      <p>
-        In contrast, a function extension version of the Natural Number sequence generator can be run. The function extension machine would be given as input a prior function extension result, or an initial empty tape. It would then modify the tape to contain the next Natural Number, as per the sequence that the Natural Number machine would write, if it could be run. This is accomplished through two subroutine calls: <RT·code>find_empty</RT·code> and <RT·code>increment</RT·code>. The <RT·code>find_empty</RT·code> machine checks the symbol under the head. Upon finding it is not the empty symbol, the machine steps right and checks the next cell, repeating until it finds the empty symbol, whereupon it halts. The <RT·code>increment</RT·code> machine then writes an 's' onto the tape and halts. Recurrent calls to the Natural Number extender then produce a sequence of result tapes: <RT·code>[], [s], [ss], …</RT·code>. Similarly, a programmer can write a machine called <RT·code>decrement</RT·code>, though the programmer must note that decrementing can return the <RT·code>left-of-leftmost</RT·code> symbol.
-      </p>
-
-      <p>
-        To say that Natural Number A is smaller than Natural Number B is to say that A would occur on the Natural Number Machine tape to the left of B, if the machine were run. Conversely, if B were said to be greater than A, that would mean B occurs further to the right. It is a simple matter for a programmer to write a decider machine for this. The decider is given two input tapes for the two numbers to compare, and it keeps a head on each. It then steps forward until neither head has an 's' under it. If empty symbols are found simultaneously on both tapes, then the two numbers are equal; otherwise, the number with an empty symbol under the head is the lesser number.
-      </p>
-
-      <p>
-        As such, a person can assign a Natural Number to each cell of a given tape by using a mechanical procedure. Given a machine, say <RT·code>P</RT·code>, and an address machine, say <RT·code>A_P</RT·code>, each time <RT·code>P</RT·code> is stepped right, a call is made to run <RT·code>increment</RT·code> on <RT·code>A_P</RT·code>. Similarly, each time <RT·code>P</RT·code> is stepped left, a call is made to run <RT·code>decrement</RT·code> on <RT·code>A_P</RT·code>. In this manner the tape on <RT·code>A_P</RT·code> will always hold the address that machine <RT·code>P</RT·code>'s head is on.
-      </p>
-
-      <p>
-        The Natural Number found on <RT·code>A_P</RT·code> is then called the address for the cell that machine <RT·code>P</RT·code>'s head is on. As each increment and decrement of the address is a constant time operation, keeping the address of the cell the head is on is computationally inconsequential.
-      </p>
-
-      <p>
-        An <RT·term>address space</RT·term> is a set of addresses for contiguous cells. The tape's address space is the set of addresses for all the cells on the tape. Typically the address of 0 is given to the leftmost among the contiguous cells.
-      </p>
-
-
-      <h2>Binary Hindu-Arabic representation address</h2>
-
       <p>
         Would it be computationally consequential if binary Hindu-Arabic representation were used instead of unary for addresses? For unary representation each increment was constant time, but with Hindu-Arabic addresses, increments have a carry. Would the carry cause stepping to the right, combined with calling the address machine, to become slower and slower as the machine steps further and further?
       </p>
 
-      <p>
-        For this discussion, the Hindu-Arabic representation address is variable precision, so it will grow as the count becomes larger. The empty symbol will serve as the terminator.
-      </p>
-
-      <p>
-        For <RT·code>Hindu-Arabic_increment</RT·code>, the machine reads the cell under the head; upon finding a 0 or the terminator, it writes a 1 and halts. Upon finding a 1, it writes a 0, steps right, and repeats the procedure.
-      </p>
-
-      <RT·code>
-        increment:
-          a = TTU.read()
-          if a == 0 or a == □:
-            TTU.write(1)
-            halt
-          TTU.write(0)
-          TTU.step()
-          goto increment
-      </RT·code>
-
-      <p>Here <RT·code>TTU</RT·code> is the tape transport unit. It has the number to be incremented mounted on it. This number is either zero, which would mean the leftmost cell is empty, or it is of the same form as a result from a Natural Number extension machine. A <RT·code>TTU.read</RT·code> places a copy of the symbol instance found in the cell under the head into the read buffer automatically when the machine enters a new state on the programmed controller, so it is not counted as a step. In contrast, the other actions are associated with the state of the programmed controller, so when the machine arrives at a <RT·code>write</RT·code>, <RT·code>step</RT·code>, or <RT·code>halt</RT·code> node, it means that the programmed state controller has taken a step. Sequential instructions mean unconditional next state choices, whereas an <RT·code>if</RT·code> signals a conditional next state choice. The <RT·code>if</RT·code> condition is a logical proposition based on the read symbol.</p>
-
-      <p>The loop form here is worth taking note of, as it will come up again. The controller executes a first action, that of a <RT·code>read</RT·code>, followed by a middle break test, and then the recursive form actions.</p>
-
-      <p>
-        Each row shows an input tape, and actions taken to write the result tape. For any given row, the result tape is the same as the input tape on the next row down. The table lists 7 increments, which is sufficient to reach the maximum count that can be held by a 3 bit counter.
-      </p>
-
-      <table>
-        <tr>
-          <th>input</th>
-          <th>action</th>
-          <th>cost (steps)</th>
-        </tr>
-        <tr>
-          <td>0</td>
-          <td>write 1, halt (result is maximum 1 bit count)</td>
-          <td>2</td>
-        </tr>
-        <tr>
-          <td>1 </td>
-          <td>write 0, step, write 1, halt</td>
-          <td>4</td>
-        </tr>
-        <tr>
-          <td>01</td>
-          <td>write 1, halt (result is maximum 2 bit count)</td>
-          <td>2</td>
-        </tr>
-        <tr>
-          <td>11</td>
-          <td>write 0, step, write 0, step, write 1, halt</td>
-          <td>6</td>
-        </tr>
-        <tr>
-          <td>001</td>
-          <td>write 1, halt</td>
-          <td>2</td>
-        </tr>
-        <tr>
-          <td>101</td>
-          <td>write 0, step right, write 1, halt</td>
-          <td>4</td>
-        </tr>
-        <tr>
-          <td>011</td>
-          <td>write 1, halt (result is maximum 3 bit count)</td>
-          <td>2</td>
-        </tr>
-        <tr>
-          <td>111</td>
-          <td></td>
-          <td></td>
-        </tr>
-      </table>
-
-      <p>
-        The number of programmable controller state transition steps required to reach a maximum 1 bit, 2 bit, and 3 bit count are: <RT·math>[2, 8, 22]</RT·math>. Note these are cumulative. The three bit maximum count cost includes that of the two bit maximum count cost, etc. Each maximum count is exponentially larger, so a better measure is the average cost per step: <RT·math>[2/1, 8/3, 22/7] = [2, 2.667, 3.143]</RT·math>
-      </p>
-
-      <p>
-        For an <RT·math>n</RT·math> bit counter, the sequence of costs follows a pattern. Half of the increments evaluate one bit (costing 2 steps), a quarter evaluate two bits (costing 4 steps), an eighth evaluate three bits (costing 6 steps), and so forth, over the <RT·math>2^n - 1</RT·math> increments required to reach the maximum <RT·math>n</RT·math> bit count:
-      </p>
-
-      <RT·math> \sum_{k=1}^{n} 2k · 2^{n-k} = 2^{n+2} - 2n - 4</RT·math>
-
-      <p>
-        To find the average cost per increment to reach each maximum, an analyst divides by the total number of increments, which is <RT·math>2^n - 1</RT·math>:
-      </p>
-
-      <RT·math> \text{Average Cost} = \frac{2^{n+2} - 2n - 4}{2^n - 1} = \frac{4(2^n-1)+4-2n-4}{2^n-1}</RT·math>
-
-      <p>
-        This simplifies algebraically to:
-      </p>
-
-      <RT·math> \text{Average Cost} = 4 - \frac{2n}{2^n - 1} </RT·math>
-
-      <p>
-        As the address space grows, the bit width <RT·math>n</RT·math> increases. The polynomial term <RT·math>2n</RT·math> is outpaced by the exponential denominator <RT·math>2^n - 1</RT·math>, causing the fractional terms to converge to zero. The average work done by the machine head converges to exactly four tape actions per increment. Constant time, same as for unary. This is a surprising counter intuitive result.
-      </p>
-
-      <p>
-        Consequently, maintaining an Hindu-Arabic address on a secondary Address Machine remains a constant time operation in the amortized sense, making it computationally inconsequential to the complexity class of the base machine. However, if a problem were to increment and decrement repeatedly around a binary power count, the behavior would be the limiting logarithmic time due to the length of the counter. An unlucky situation like this is called <RT·term>aliasing</RT·term>.
-      </p>
 
       <p>
         The model used here to define an address is analogous to keeping a pointer into memory. Each step then increments or decrements the pointer. Conventional processors do the converse of the Turing Machine model presented here. For a processor, the <em>address</em> is the base object, while the <em>head location</em> is what is implied by the address. On processors, pointers will be one word in width. In small geometries where computation element delay dominates, two operand adders tend towards logarithmic complexity evaluation times against bit width, and the constants are small. Because of this, it is practical to perform word width addition operations atomically in one machine cycle. In fact, for some machines, the adder time likely sets the clock period. Such an adder will be used for address arithmetic; consequently, a programmer cannot arrange a program to expose aliasing in the address increment time to the real world. It remains a theoretical observation.
@@ -2345,7 +2344,7 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos
       <p>By separating the control path from the data path, utilizing an integrated symbol alphabet, replacing states with sequential instructions, and introducing an explicit addressable instruction pointer, the theoretical machine has physically crossed the bridge to conventional computing. The resulting architecture is a stored-program, von Neumann-style machine organization.</p>
 
       <p>Some of the default cases for the jump table unnecessarily jump to the instruction at the next sequential address. This code lacks the regularity to use a computed jump table, so this style of jump table becomes a Lisp <RT·code>cond</RT·code> statement, i.e. sequential conditional tests. So then by using the instructions <RT·code>test</RT·code>, <RT·code>beq</RT·code> (for branch on equal), and <RT·code>jump</RT·code> as control instructions, and rearranging to favor sequential execution, this code becomes:</p>
-      
+
       <RT·code>
       # Phase 1: Both heads scan right to the EOM pivot
       L·initial:
@@ -3888,5 +3887,3 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos
 <!--  LocalWords:  computable cardinality uniquifier namespace
  -->
  -->
-
-