<RT·article>
+ <RT·counter·make counter="RT·Figure·counter" style="CountingNumber" mode="scoped"></RT·counter·make>
+ <RT·counter·make counter="RT·Table·counter" style="CountingNumber" mode="scoped"></RT·counter·make>
+ <RT·counter·make counter="RT·List·counter" style="CountingNumber" mode="scoped"></RT·counter·make>
+ <RT·counter·make counter="RT·Equation·counter" style="CountingNumber" mode="scoped"></RT·counter·make>
+ <RT·counter·make counter="RT·Code·counter" style="CountingNumber" mode="scoped"></RT·counter·make>
+
<RT·title
title="Computational Naturalism"
author="Thomas Walker Lynch"
<RT·TOC level="1-2"></RT·TOC>
-
<!--------------------------------------------------------------------------------->
- <RT·section>
- <RT·name>Preface</RT·name>
+ <RT·section id="Section·terminology">
+ <RT·name>Terminology</RT·name>
<p>All communication is founded upon common knowledge, so here are some notes on the conventions used in this book.</p>
<p>Generally in this book, containers such as sequences and sets are capital letters, even when in Greek. Mathematical objects that are not containers are represented with lower case letters. Character pairs or full symbol names can also be used to represent mathematical objects. The context will make it clear if a non-letter unicode character is used to represent a container or a non-container.
</p>
- <p>The unicode middle dot, ·, is used as an ad hoc namespace operator in identifiers. Hence, <RT·code>N·x</RT·code>, would be the variable <RT·code>x</RT·code> from the <RT·code>N</RT·code> namespace. This is a typography symbol. It can be seen for example when words are broken into symbols, e.g. 'op·er·a·tor', and sometimes in names, such a 'Leonardo da·Vinci', and 'Vincent van·Gogh'. It is accepted in identifiers by modern C compilers, and it is part of the RT·gcc compiler mods for gcc.</p>
+ <p>The unicode middle dot, ·, is used as an ad hoc namespace operator in identifiers. Hence, <RT·code>N·x</RT·code>, would be the variable <RT·code>x</RT·code> from the <RT·code>N</RT·code> namespace. This is a typography symbol. It can be seen for example when words are broken into symbols, e.g. 'op·er·a·tor', and sometimes in names, such as 'Leonardo da·Vinci', and 'Vincent van·Gogh'. It is accepted in identifiers by modern C compilers, and it is part of the RT·gcc compiler mods for gcc.</p>
<p>I have experimented with modern gender forms in technical language in past writings. For example, I used the plural-as-singular style in one piece, and was applauded by some, though categorized as illiterate by others. Since then, I have evolved a writing style that emphasizes using roles as subjects: the mathematician, the author, the programmer. Such subjects are singular, so for grammatical agreement, I use the <em>inclusive he</em>. It is structurally much cleaner to use <em>he</em> as inclusive of all people than it is to gray out an entire category of plural agreement pronouns by forcing words such as "they" to take on a singular form. I use "a person" when the subject is an unknown third party, potentially even being an AI. I prefer this over the 'one' of 'One does this, or one does that.' so that 'one' can be reserved to unambiguously refer to the natural number.</p>
- <p>In the prior edition of this book, the preface included a discussion on the meaning of the word "may" according to RFC 2119, the guidelines for specification writing. There is an important distinction between the 'may' of options or permission, and the more colloquial 'may' of probability. However, distinguishing between the two was too much of an ask of readers, most of whom skip the preface anyway. So in this edition, I avoid the temptation to use 'may' and replace it with a direct statement of what I mean. "It is of high probability that..." or "There are options for...". Directly saying what is meant, who would have thought of it? The RFC 2119 authors have apparently struggled with this as well, as they now require the MAY and other words that appear in RFC 2119 to be capitalized so as to dodge the grammar debate.</p>
+ <p>In the prior edition of this book, the preface included a discussion on the meaning of the word "may" according to RFC 2119, the guidelines for specification writing. There is an important distinction between the 'may' of options or permission, and the more colloquial 'may' of probability. However, distinguishing between the two was too much of an ask of readers, most of whom skip the preface anyway. So in this edition, I avoid the temptation to use 'may' and replace it with a direct statement of what I mean. "It is of high probability that..." or "There are options for...". Directly saying what is meant, who would have thought of it? The RFC 2119 authors have apparently struggled with this as well, as they now require the MAY and the other words that appear in RFC 2119 to be capitalized so as to dodge the grammar debate.</p>
<p>Code examples in this text follow the distinctive RT code format conventions.<RT·endnote>For the complete specification, refer to RT-code-format.html and RT-code-format-Lisp.html located at https://github.com/Thomas-Walker-Lynch/RT-Style/tree/core-developer_branch/developer/document.</RT·endnote> For example, horizontal comma-separated lists apply a space before the comma to bind the punctuation to the item being appended to the list:</p>
- <RT·code>
- int x ,y ,z;
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·comma-list_example">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·comma-list_example"></RT·counter·snapshot>
+ <RT·code>
+ int x ,y ,z;
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·comma-list_example"></RT·counter·read>. <RT·name>A horizontal comma separated list</RT·name>
+ </RT·counter·step>
<p>Multi-level enclosures receive a single space of padding only on the outermost boundary:</p>
- <RT·code>
- if( f(g(x)) ){
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·enclosure-padding_example">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·enclosure-padding_example"></RT·counter·snapshot>
+ <RT·code>
+ if( f(g(x)) ){
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·enclosure-padding_example"></RT·counter·read>. <RT·name>Padding applied to the outermost enclosure only</RT·name>
+ </RT·counter·step>
<p>Furthermore, identifier naming leverages both hyphens and underscores, when available, to establish semantic binding precedence. An example of this is:</p>
- <RT·code>
- rounded_x-coordinate
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·identifier-separator_example">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·identifier-separator_example"></RT·counter·snapshot>
+ <RT·code>
+ rounded_x-coordinate
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·identifier-separator_example"></RT·counter·read>. <RT·name>A hyphen binding tighter than an underscore within an identifier</RT·name>
+ </RT·counter·step>
- <p>Furthermore, in this coding culture, we say that arguments values are <em>given</em> to a function. Functions do not <em>take</em> arguments, as a call stack cannot reach into memory and grab values. A function is only said to <em>accept</em> or <em>reject</em> a value in the context of guard code evaluating its validity. Similarly, machines, factories, and software <em>make</em> objects by assembling components; they do not <em>create</em> them, as creation implies a fundamental synthesis outside the scope of engineering.</p>
+ <p>Furthermore, in this coding culture, we say that argument values are <em>given</em> to a function. Functions do not <em>take</em> arguments, as data is flowing from the caller to the function. A function is only said to <em>accept</em> or <em>reject</em> a value in the context of guard code evaluating argument validity. Similarly, machines, factories, and software <em>make</em> objects by assembling components; they do not <em>create</em> them, thus leaving 'creation' to imply a more fundamental synthesis outside the scope of engineering, perhaps done by artists and supernatural beings.</p>
<p>Whenever standard mathematical or Greek symbols are required, this text utilizes native Unicode characters rather than relying on escape sequences. For example, the text uses 'δ' directly instead of, say, "\delta"; this might lead to some small typesetting variations.</p>
<p>Dates and times are given in the ISO 8601 format. The components run from the most significant to the least significant, year, then month, then day, in the same order the digits of a Hindu-Arabic numeral run. Two consequences follow from that ordering, and both are the reason for choosing it. A lexicographic comparison of two such dates agrees with their chronological comparison, so a list of them sorts correctly with no collation rules particular to dates. And the format is unambiguous, whereas a date such as 03/04/2026 is read as the third of April by some readers and the fourth of March by others. A time of day, when one is given, follows the date, and a trailing <RT·code>Z</RT·code> marks the time as UTC. Hence <RT·code>2026-06-01 08:28:00Z</RT·code>. Where a date appears without a time, the date alone is intended, e.g. <RT·code>2026-06-01</RT·code>.</p>
+ </RT·section>
+
+ <!--------------------------------------------------------------------------------->
+ <RT·section id="Section·preface">
+ <RT·name>Preface</RT·name>
+
+ <p>One afternoon I was fortunate to have lunch in Berkeley with Bill Kahan, a pioneer in applied number theory, and our conversation turned to errors in numeric computation. I observed that an error is merely an opportunity to do more computing. Bill seemed to like the remark; he repeated it in a <em>Dr. Dobb's</em> interview, where it was credited to him. When we met again, I asked him about it. He apologized, explaining that the interviewer had created something rather than reporting it, and that he was surprised himself by what he read. The apology was unnecessary. I had intended to summarize Kahan's own work. He was instrumental in creating IEEE Std. 754, where an exceptional condition, more informally an "error", need not end computation but can serve as a gateway to a higher symbolic algebra. I found that architecture inspiring, and my comment had been intended to acknowledge his inspiration.</p>
+
+ <p>In practical computing the symbol algebra of the IEEE Std. 754 quickly devolves into the catch all indeterminate value, the so called <em>NaN</em>, which tends to leave programmers wishing to extend the system. Kulisch and Miranker attempted to formalize computer arithmetic, and started by reasoning about a screen that laid out over the real number space. Boehm and Cartwright introduced a concept of Constructive Real Numbers, where precision of computation was extended upon demand. And through Stephen Wolfram's vision, Mathematica provides a complete symbolic math manipulation package, where a symbolic expression can be reduced before being evaluated. For evaluation they then track loss of precision through significance arithmetic. In my own work, I have suggested an analysis step first, where required precision is derived, followed by computation. However, among these there is still missing a formalism of passing through the gateway upon an error, so to speak. Mathematica comes the closest.</p>
+
+ <p>John Gustafson also brought up the topic of the nature of error shortly before publishing "The End of Error". He now has another proposal based on variable precision arithmetic known as "posits". There was so much I wanted to say when we spoke, but I could not formulate the thoughts. I had learned a great deal while doing formal analysis of the algorithms I had put on the Am29050, Am486, and K5 processors at AMD, but when I tried to articulate this, I only stammered. I feel that I fell short, as all I could do is point at my already published work at that time on high radix online arithmetic. So this volume is my answer to John's question. Albeit it is a little late, well years late, but I hope it will still have some value.</p>
+
+ <p>There is a first edition of this book. The same concepts are described in those pages, but the story is not as well told, and no one has come full circle to say it made any sense to them. Well, one colleague, after reviewing the first edition, admitted he was bewildered by it and asked if I was proposing that we build Turing Machines. After all we are the music makers, in the music business, so to speak; only instead of being written in notes, our music is written in transistors and layout. So then, he rightfully asks, what is the proposal here? I could only point him at Mitch Alsup's book, and ponder how I could tell this story differently.</p>
+
+ <p>There is not a hardware specification for a new proposed machine in this book. This book is not proposing to build in hardware a Turing Machine. This is an absolute. Building a TTCA machine might be interesting, and the organization for it is described in this book, but that is certainly not the proposal here. Rather this book lays the foundation for a proposal for another machine. It explains and justifies that other machine's features. But the details, the architecture, of this other machine are not found in these pages.</p>
+
+ <p>There is a practical aspect to this work. A software library that is of general usefulness can be found in these pages, and downloaded from GitHub. The library was first articulated in the Lisp language in the first edition of the book and released on Quicklisp. Lisp is in a sense pure, and formal statements can be made with it. Using it for the library made the library a natural small step away from the formal discussion that came before it was presented. Since that time I have written parts of the library in other languages and found it very useful. This volume presents the Python API.</p>
+
+ <p>While reaching to say something of value, I reach into foundational mathematics, a bit of number theory, and computation theory. Familiarity with those subjects will help readers read this volume, though it might not be absolutely necessary. In a sense computation theory is post Turing-Church et al. number theory. Number theory is conventionally thought of as the analysis of structures related to Natural Numbers. However, those structures are themselves entities, and a person must ask what a number is, if a number itself is not merely the structure described by Peano. It follows that when computer scientists or engineers focus their attention on numeric algorithms and circuits, they are practicing applied number theory. This in turn is a specialization of the study of algorithms in general, one where the structures are said to be numbers, and thus is part of computation theory, completing the circle.</p>
+
+ </RT·section>
+
+ <!--------------------------------------------------------------------------------->
+ <RT·section id="Section·introduction">
+ <RT·name>Introduction</RT·name>
+
+ <p>Kleene's <em>Introduction to Metamathematics</em> opens with, "A flock of four sheep and a grove of four trees are related to each other in a way in which neither is related to a pile of three stones or a grove of seven trees. ... Without counting the sheep or the trees, one can pair them with each other, for example by tethering the sheep to the trees, so that each sheep and each tree belongs to exactly one of the pairs."<RT·endnote>Stephen Cole Kleene, <em>Introduction to Metamathematics</em> (Amsterdam: North-Holland, 1952), 3.</RT·endnote></p>
+
+ <p>Kleene's words are more than an introduction to Cantor's transfinite numbers. They appeal to Naturalism as a foundation. They leverage the reader's intuition, while succinctly making the implicit point that mathematics has purpose.</p>
+
+ <p>In his foundational paper Alan Turing asks us to think of a clerk sitting at a desk writing on paper while following some rules, and to imagine what can be written. Turing's own founding image is thus an observation of the world rather than an independently standing abstract form.</p>
+
+ <p>Here the Naturalist runs into a problem. The Turing Machine is not practical to build. The infinite tape is of course an issue, but it is perhaps not the most serious obstacle to realizing a Turing Machine. As I will formalize later in this book, the Turing Machine head must always read and react, and this will force the author of the controller to build memory into the control. In turn this causes the controller to explode in size with machine word width.</p>
+
+ <p>However, this situation is recoverable. This volume presents modifications that lead to an alternative computation theoretic object that is equally expressive as a Turing Machine, and yet is practical to build. This then restores the validity of the Naturalist interpretation.</p>
+
+ <p>For a question to be resolved by a Turing Machine, the question must be formed as a program that when run produces a result in a finite number of steps. <RT·term>Practicality</RT·term> is an even stronger constraint than being computational. For running a program to be practical, finishing in a finite number of steps is not sufficient; it must also complete before a given deadline. In the natural world, we all operate under the constraints of being practical. However, that does not prevent us from having a practical discussion about what is theoretically possible to compute, and such discussion is found in the pages of this book.</p>
+
+ <p>It is commonly thought that Turing Machines, and thus observations of nature, are limited to discrete computation, and thus there is a large domain of continuous mathematics that they can not speak about. However, the very concept of the continuous is described in discrete terms. Consider the simple function <RT·math>x^2</RT·math> over a real field. It is considered to be a continuous function, yet it consists of discrete symbols. To take its derivative is to follow the steps of an algorithm, i.e. a program, which brings the 2 down as a multiplier and replaces the exponent with a 1, or leaves it out altogether. These are discrete steps resulting in another discrete formula, <RT·math>2 x</RT·math>. In that the word <em>continuous</em> is given meaning, it becomes discrete.</p>
+
+ <p>Analysis is the bridge that leads from the natural world to the world of forms. Here analysis is the activity of asking about the properties of a program instead of running it. The program being analyzed then becomes the input data for the program doing the analysis. Turing's original paper introduced the naturalist interpretation of mathematics via the clerk at the desk, described a machine for automating the clerk's work, introduced the idea of a stored program, described analysis, and pointed out that it was possible to analyze an analyzer. And as though that was not enough, he provided a general analysis applicable to halting analyzers that proved that no universal halting analyzer can exist. (A halting analyzer is an analyzer, i.e. a program, that analyzes a given program to decide if that given program halts or not.) This does not mean that a halting analyzer can not ever be practical. For a large class of programs a halting analyzer can give an answer, and do so before a deadline. However, the proof result means that for any halting analyzer, there will be programs for which it will not be able to decide whether they halt or not, even when there is no deadline apart from 'finite number of steps'.</p>
+
+ <p>Here then, is an interesting thing about some Turing Machine programs that do not halt. Though they can not be run to completion, they can be analyzed. Say a program prints the 's' character, then loops back, and thus prints the 's' character again and again. Such a program can not be run to completion as it never halts. However, the program can be analyzed and talked about, as of course we already know, as we are doing this very thing right now. Thus the holes in the lower level language kick the problem up to a higher level where questions are asked as to how the program behaves and what an exceptional condition means.</p>
+
+ <p>Accordingly the world of forms is not a separate realm. It is the tower of languages standing above the machine, each layer of it there to speak of the holes in the layer beneath. Those languages become separated from the machine that gave rise to them, so the base machine never need be run. At each moment, we reach the limit of what can happen in that moment, then a new moment arrives, both in stepping through programs, and in layers of abstraction.</p>
</RT·section>
+
<!--------------------------------------------------------------------------------->
<RT·section>
<RT·name>The search that led to the Turing Machine</RT·name>
<p>
- In 1893 Gottlob Frege published an axiomatic construction of mathematics from set theory. Frege's grand objective was something he called <RT·term>Logicism</RT·term>, the philosophical thesis that all of mathematics can be derived entirely from pure logic. To bridge set theory and logic, Frege defined sets using a method known as <RT·term>set comprehension</RT·term>. Under this approach, a mathematician states a logical rule or property, and any object satisfying that logical statement automatically becomes a member of the set. Because the membership of a set is determined entirely by logical rules, the resulting sets, and the mathematics built upon them, are derived directly from logic. To implement this, his specific machinery relied upon unrestricted set comprehension, formalized as Basic Law V <RT·endnote>Gottlob Frege, <em>Grundgesetze der Arithmetik</em>, Vol. 2 (Jena: Hermann Pohle, 1903), Appendix (Nachwort), 253.</RT·endnote>.
+ In 1893 Gottlob Frege published an axiomatic construction of mathematics from set theory. Frege's grand objective was something he called <RT·term>Logicism</RT·term>, the philosophical thesis that all of mathematics can be derived entirely from pure logic. To bridge set theory and logic, Frege defined sets using a method known as <RT·term>set comprehension</RT·term>. Under this approach, a mathematician states a logical rule or property, and any object satisfying that logical statement automatically becomes a member of the set. Because the membership of a set is determined entirely by logical rules, the resulting sets, and the mathematics built upon them, are derived directly from logic. To implement this, his specific machinery relied upon unrestricted set comprehension, formalized as Basic Law V <RT·endnote>Gottlob Frege, <em>Grundgesetze der Arithmetik</em>, Vol. 1 (Jena: Hermann Pohle, 1893), §20.</RT·endnote>.
</p>
<p>
At a conference in Paris in 1900, David Hilbert presented a list of pressing unsolved problems in mathematics.
- Second on his list was "The Compatibility of the Arithmetical Axioms." Hilbert challenged mathematicians to find a means to demonstrate that "a finite number of logical steps based upon them [axioms] can never lead to contradictory results" <RT·endnote>F. N. Cole et al., eds., <em>Bulletin of the American Mathematical Society</em>, Vol. 8 (New York: Macmillan, 1902). This can be found at https://www.gutenberg.org/cache/epub/71655/pg71655-images.html. The MathWorld article on this subject, https://mathworld.wolfram.com/HilbertsProblems.html, explains that Hilbert presented 10 problems at the conference, though the publication shows 23 problems, and shortly later a 24th problem was added. Based on the notes of this citation, it appears the second problem is the same on all of these lists. Also note, Hilbert discusses <em>completeness</em> specifically as an axiom for bounding on the sets, which appears to be distinct from the question of logical completeness for an axiomatic system.</RT·endnote>.
+ Second on his list was "The Compatibility of the Arithmetical Axioms." Hilbert challenged mathematicians to find a means to demonstrate that "a finite number of logical steps based upon them [axioms] can never lead to contradictory results" <RT·endnote>David Hilbert, "Mathematical Problems," trans. Mary Winston Newson, <em>Bulletin of the American Mathematical Society</em> 8 (1902): 437–479. This can be found at https://www.gutenberg.org/cache/epub/71655/pg71655-images.html. The MathWorld article on this subject, https://mathworld.wolfram.com/HilbertsProblems.html, explains that Hilbert presented 10 problems at the conference, though the publication shows 23 problems, and a 24th problem was later discovered among Hilbert's unpublished notes. Based on the notes of this citation, it appears the second problem is the same on all of these lists. Also note, Hilbert discusses <em>completeness</em> specifically as an axiom for bounding on the sets, which appears to be distinct from the question of logical completeness for an axiomatic system.</RT·endnote>.
</p>
<p>
- In 1901 Bertrand Russell found a well-formed set formulation using Frege's set theory that did not correspond to a set. As Frege's work was based on this set theory, this called into question his entire work. Russell pointed out that it was possible to define a set of all sets that do not contain themselves. However this was a paradox, because if said set contained itself, it shouldn't, and if it didn't it should. Thus the formulation failed to define a set because the logical condition cannot be satisfied <RT·endnote>Bertrand Russell, <em>The Principles of Mathematics</em> (Cambridge: Cambridge University Press, 1903), Chapter X, 'The Contradiction'.</RT·endnote>. Russell communicated this to Frege in a letter dated 1902 06 16, shortly before his second volume was going to print <RT·endnote>Bertrand Russell to Gottlob Frege, June 16, 1902, reprinted in Jean van Heijenoort, <em>From Frege to Gödel: A Source Book in Mathematical Logic</em> (Cambridge: Harvard University Press, 1967), 124 125.</RT·endnote> <RT·endnote>Gottlob Frege, <em>Grundgesetze der Arithmetik</em>, Vol. 2 (Jena: Hermann Pohle, 1903), Appendix (Nachwort), 253. Frege writes: 'Hardly anything more unfortunate can befall a scientific writer than to have one of the foundations of his edifice shaken after the work is finished.'</RT·endnote>. Frege hurriedly authored an appendix (the Nachwort) admitting his system was compromised <RT·endnote>Frege was a quiet, rigid man who had spent decades building his logical fortress in almost total academic obscurity. Frege was personally devastated by Russell's letter. Shortly after, he suffered the loss of his wife, fell into severe depression, and his academic output almost entirely ceased. In 1924, a year before his death, he wrote unpublished diaries explicitly surrendering his life's work, declaring that logicism was a mistake and that mathematics must actually be derived from geometry. Note I. Grattan Guinness, <em>The Search for Mathematical Roots, 1870 1940</em> (Princeton: Princeton University Press, 2000). For an analysis of Frege's intellectual decline, personal tragedies, and his unpublished 1924 1925 diaries where he formally surrenders the logicist program, see Chapter 7.</RT·endnote>.
+ In 1901 Bertrand Russell found a well-formed set formulation using Frege's set theory that did not correspond to a set. As Frege's work was based on this set theory, this called into question his entire work. Russell pointed out that it was possible to define a set of all sets that do not contain themselves. However this was a paradox, because if said set contained itself, it shouldn't, and if it didn't it should. Thus the formulation fails to define a set because the logical condition cannot be satisfied <RT·endnote>Bertrand Russell, <em>The Principles of Mathematics</em> (Cambridge: Cambridge University Press, 1903), Chapter X, 'The Contradiction'.</RT·endnote>. Russell communicated this to Frege in a letter dated 1902-06-16, shortly before Frege's second volume was going to print <RT·endnote>Bertrand Russell to Gottlob Frege, June 16, 1902, reprinted in Jean van Heijenoort, <em>From Frege to Gödel: A Source Book in Mathematical Logic</em> (Cambridge: Harvard University Press, 1967), 124–125.</RT·endnote> <RT·endnote>Gottlob Frege, <em>Grundgesetze der Arithmetik</em>, Vol. 2 (Jena: Hermann Pohle, 1903), Appendix (Nachwort), 253. Frege writes: 'Hardly anything more unfortunate can befall a scientific writer than to have one of the foundations of his edifice shaken after the work is finished.'</RT·endnote>. Frege hurriedly authored an appendix (the Nachwort) admitting his system was compromised <RT·endnote>Frege was a quiet, rigid man who had spent decades building his logical fortress in almost total academic obscurity. Frege was personally devastated by Russell's letter. Shortly after, he suffered the loss of his wife, fell into severe depression, and his academic output almost entirely ceased. In 1924, a year before his death, he wrote unpublished diaries explicitly surrendering his life's work, declaring that logicism was a mistake and that mathematics must actually be derived from geometry. Note I. Grattan-Guinness, <em>The Search for Mathematical Roots, 1870–1940</em> (Princeton: Princeton University Press, 2000). For an analysis of Frege's intellectual decline, personal tragedies, and his unpublished 1924–1925 diaries where he formally surrenders the logicist program, see Chapter 7.</RT·endnote>.
</p>
<p>
- In 1903 Russell proposed a hierarchy of types to repair this foundational vulnerability. At the base were sets of individuals, then sets based on individuals or sets of individuals, etc. This looks a lot like how types work in modern software <RT·endnote>Bertrand Russell, <em>The Principles of Mathematics</em> (Cambridge: Cambridge University Press, 1903), Appendix B: The Doctrine of Types.</RT·endnote>. In this manner, it is not possible to write a paradoxical set definition. Russell and Alfred North Whitehead then engineered an entirely new, massive scaffolding utilizing this type system to pursue Frege's original objective of deriving mathematics from logic, publishing their results in three volumes between 1910 and 1913 <RT·endnote>Alfred North Whitehead and Bertrand Russell, <em>Principia Mathematica</em> (Cambridge: Cambridge University Press, 1910 1913).</RT·endnote>. Russell's system can be cumbersome due to requiring a large construction to be assembled in place of what otherwise might have been a simple rule.
+ In 1903 Russell proposed a hierarchy of types to repair this foundational vulnerability. At the base were sets of individuals, then sets based on individuals or sets of individuals, etc. This looks a lot like how types work in modern software <RT·endnote>Bertrand Russell, <em>The Principles of Mathematics</em> (Cambridge: Cambridge University Press, 1903), Appendix B: The Doctrine of Types.</RT·endnote>. In this manner, it is not possible to write a paradoxical set definition. Russell and Alfred North Whitehead then engineered an entirely new, massive scaffolding utilizing this type system to pursue Frege's original objective of deriving mathematics from logic, publishing their results in three volumes between 1910 and 1913 <RT·endnote>Alfred North Whitehead and Bertrand Russell, <em>Principia Mathematica</em> (Cambridge: Cambridge University Press, 1910–1913).</RT·endnote>. Russell's system can be cumbersome due to requiring a large construction to be assembled in place of what otherwise might have been a simple rule.
</p>
<p>
- In 1908 Ernst Zermelo published an alternative system designed to avoid the known paradoxical statements of the time, even though absolute consistency remained unproven. In Zermelo's set theory, a mathematician first starts with an existing set, and then applies the Axiom of Separation using definite properties to partition out subsets <RT·endnote>Ernst Zermelo, "Untersuchungen über die Grundlagen der Mengenlehre I," <em>Mathematische Annalen</em> 65 (1908): 261 281.</RT·endnote>. To see how this works, consider the expression <RT·math>\{x \mid P(x)\}</RT·math>. Under unrestricted comprehension, a logician is permitted to define the predicate <RT·math>P(x)</RT·math> as <RT·math>x ∉ x</RT·math>. This produces Russell's Paradox, so the set fails to be defined. In contrast, consider the same predicate, though restricted by Zermelo's Axiom of Separation over a predefined set <RT·math>S</RT·math>, written as <RT·math>\dot{R} = \{x \mid x ∈ S ∧ x ∉ x\}</RT·math>. The only thing a person needs to know about <RT·math>S</RT·math> here is that it has already been successfully defined. So let us ask, is <RT·math>\dot{R}</RT·math> in <RT·math>\dot{R}</RT·math>? If we assume <RT·math>\dot{R}</RT·math> is a member of <RT·math>S</RT·math>, evaluating the second term forces the familiar fatal loop: if <RT·math>\dot{R}</RT·math> is in <RT·math>\dot{R}</RT·math>, it shouldn't be, and if it isn't, it should be. Thus if we assume that <RT·math>\dot{R}</RT·math> is in <RT·math>S</RT·math>, then <RT·math>\dot{R}</RT·math> can not be defined, but by definition, <RT·math>S</RT·math> is defined, and thus its members are defined. As we arrived at a contradiction, the original assumption must be false, i.e. it is wrong to assume that <RT·math>\dot{R}</RT·math> is in <RT·math>S</RT·math>. As <RT·math>\dot{R}</RT·math> is definitively not a member of <RT·math>\dot{R}</RT·math>, the first term of the set comprehension rule, <RT·math>x ∈ S</RT·math> is false, and the paradox vanishes.
+ In 1908 Ernst Zermelo published an alternative system designed to avoid the known paradoxical statements of the time, even though absolute consistency remained unproven. In Zermelo's set theory, a mathematician first starts with an existing set, and then applies the Axiom of Separation using definite properties to partition out subsets <RT·endnote>Ernst Zermelo, "Untersuchungen über die Grundlagen der Mengenlehre I," <em>Mathematische Annalen</em> 65 (1908): 261–281.</RT·endnote>. To see how this works, consider the expression <RT·math>\{x \mid P(x)\}</RT·math>. Under unrestricted comprehension, a logician is permitted to define the predicate <RT·math>P(x)</RT·math> as <RT·math>x ∉ x</RT·math>. This produces Russell's Paradox, so the set fails to be defined. In contrast, consider the same predicate, though restricted by Zermelo's Axiom of Separation over a predefined set <RT·math>S</RT·math>, written as <RT·math>\dot{R} = \{x \mid x ∈ S ∧ x ∉ x\}</RT·math>. The only thing a person needs to know about <RT·math>S</RT·math> here is that it has already been successfully defined. So let us ask, is <RT·math>\dot{R}</RT·math> in <RT·math>\dot{R}</RT·math>? If we assume <RT·math>\dot{R}</RT·math> is a member of <RT·math>S</RT·math>, evaluating the second term forces the familiar fatal loop: if <RT·math>\dot{R}</RT·math> is in <RT·math>\dot{R}</RT·math>, it shouldn't be, and if it isn't, it should be. Thus if we assume that <RT·math>\dot{R}</RT·math> is in <RT·math>S</RT·math>, then <RT·math>\dot{R}</RT·math> can not be defined, but by definition, <RT·math>S</RT·math> is defined, and thus its members are defined. As we arrived at a contradiction, the original assumption must be false, i.e. it is wrong to assume that <RT·math>\dot{R}</RT·math> is in <RT·math>S</RT·math>. As <RT·math>\dot{R}</RT·math> is definitively not a member of <RT·math>S</RT·math>, the first term of the set comprehension rule, <RT·math>x ∈ S</RT·math>, is false, and the paradox vanishes.
</p>
<p>
- A person might suggest defining <RT·math>S</RT·math> as the set of all definable mathematical objects, forming a universal set. However, if such a universal set <RT·math>S</RT·math> existed, the Axiom of Separation could be applied using the previous predicate to isolate <RT·math>\dot{R}</RT·math>. Because <RT·math>\dot{R}</RT·math> is a valid, definable set, it must reside within <RT·math>S</RT·math> by the very definition of a universal set. But notice that the logic evaluated earlier proved definitively that <RT·math>\dot{R}</RT·math> cannot be a member of <RT·math>S</RT·math>. Yet the existence of a definable set <RT·math>\dot{R}</RT·math> that sits strictly outside of <RT·math>S</RT·math> contradicts the premise that <RT·math>S</RT·math> contains everything. Therefore, within any system governed by the Axiom of Separation, a universal set cannot exist.
+ A person might suggest defining <RT·math>S</RT·math> as the set of all definable mathematical objects, forming a universal set. However, if such a universal set <RT·math>S</RT·math> existed, the Axiom of Separation could be applied as per the proof in the prior paragraph to show <RT·math>\dot{R}</RT·math> is not in <RT·math>S</RT·math>. However, as <RT·math>\dot{R}</RT·math> is a valid, definable set, it must reside within <RT·math>S</RT·math> by the very definition of a universal set. This contradicts the premise that <RT·math>S</RT·math> contains everything. Therefore, within any system governed by the Axiom of Separation, a universal set cannot exist.
</p>
<p>
- The authority to remove the Russell's Paradox set formulation comes from the set <RT·math>S</RT·math>. If we know its definition, then the authority comes through that definition. However, if we merely stipulate that <RT·math>S</RT·math> must be defined, then we are expressing our authority through <RT·math>S</RT·math> by declaring, "Undefined sets are not allowed." In the explanation above, it is only after discovering a set is undefined that we conclude it is not a member of <RT·math>S</RT·math>. I sometimes wonder how mathematics might have evolved had Frege simply taken that approach. We take this question up again in the chapter Computational Naturalism, and discover there is a deeper issue.
+ The authority to remove Russell's Paradox set formulation comes from the set <RT·math>S</RT·math>. If we know its definition, then the authority comes through that definition. However, if we merely stipulate that <RT·math>S</RT·math> must be defined, then we are expressing our authority through <RT·math>S</RT·math> by declaring, "Undefined sets are not allowed." In the explanation above, it is only after discovering a set is undefined that we conclude it is not a member of <RT·math>S</RT·math>. I sometimes wonder how mathematics might have evolved had Frege simply taken that approach. We take this question up again in chapter <RT·counter·read snapshot="Section·computational-naturalism"></RT·counter·read>, Computational Naturalism, and discover there is a deeper issue.
</p>
<p>
- Stepping back from the mechanics of set definition, a person can observe two competing approaches to establishing mathematical foundations. The first approach is constructive, building complex systems by assembling them upward from fundamental primitives. The second approach relies on islands of meaning, carving out valid spaces from the abstract void using precise rules and axioms, exactly as Zermelo did. Because both methodologies rely entirely upon a rigorous framework of deduction to function, logic itself serves as the essential substrate. Consequently, a complete foundational study requires the examination of three distinct subjects: the primitives used for construction, the rules that bound the theoretical islands, and the underlying logic that evaluates them both.
+ Stepping back from the mechanics of set definition, a person can observe two competing approaches to establishing mathematical foundations. The first approach is constructive, building complex systems by assembling them upward from fundamental primitives. The second approach relies on islands of meaning, carving out valid spaces from the abstract void using precise rules and axioms, exactly as Zermelo did. Because both methodologies rely entirely upon a rigorous framework of deduction, logic itself serves as the essential substrate. Consequently, a complete study of the foundation of mathematics requires the examination of three distinct subjects: the primitives used for construction, the rules that bound the theoretical islands, and the underlying logic that evaluates them both.
</p>
<p>
- In 1928 David Hilbert and Wilhelm Ackermann published a textbook on mathematical logic, Grundzüge der theoretischen Logik <RT·endnote>David Hilbert and Wilhelm Ackermann, <em>Grundzüge der theoretischen Logik</em> (Berlin: Springer, 1928). This first edition has not been translated into English.</RT·endnote>. A feature of this book is its attention to procedures to follow for mechanically determining truth of statements. They called the problem solved by such a procedure the Entscheidungsproblem. In the first chapter they review the procedure for solving the Entscheidungsproblem in the propositional logic. For the first order predicate calculus they define the problem as, "Universal validity concerns the following question: How can one determine, for any given logical expression that contains no individual signs [constants], whether the expression represents a true assertion for arbitrary substitutions for the occurring variables, or not?" <RT·endnote>Ibid., 72 73.</RT·endnote>. They review some special cases with solutions, including one published earlier by Ackermann, but then throw down the gauntlet by saying,
+ In 1928 David Hilbert and Wilhelm Ackermann published a textbook on mathematical logic, <em>Grundzüge der theoretischen Logik</em> <RT·endnote>David Hilbert and Wilhelm Ackermann, <em>Grundzüge der theoretischen Logik</em> (Berlin: Springer, 1928). This first edition has not been translated into English.</RT·endnote>. A feature of this book is its attention to procedures to follow for mechanically determining truth of statements. They called the problem solved by such a procedure the Entscheidungsproblem. In the first chapter they review the procedure for solving the Entscheidungsproblem in the propositional logic. For the first order predicate calculus they define the problem as, "Universal validity concerns the following question: How can one determine, for any given logical expression that contains no individual signs [constants], whether the expression represents a true assertion for arbitrary substitutions for the occurring variables, or not?" <RT·endnote>Ibid., 72–73.</RT·endnote>. They review some special cases with solutions, including one published earlier by Ackermann, but then throw down the gauntlet by saying,
"A general solution to the Entscheidungsproblem, regardless of whether a person considers the first or the second formulation, is not yet available." <RT·endnote>Ibid., 81. "Eine allgemeine Lösung des Entscheidungsproblems, mag man nun die erste oder die zweite Fassung nehmen, liegt bis jetzt noch nicht vor."</RT·endnote> <RT·endnote>The term Entscheidungsproblem literally translates to 'decision problem'. However, there are many types of decision problems, and later we will meet a class of Turing Machine programs called deciders, so it appears to be best to keep the original German. As we will see later Alan Turing also did this.</RT·endnote>.
</p>
<p>
- In 1931 Kurt Gödel published his incompleteness theorems <RT·endnote>Kurt Gödel, "Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I," <em>Monatshefte für Mathematik und Physik</em> 38 (1931): 173 198.</RT·endnote>. By mapping formal logic into arithmetic, he demonstrated that any consistent formal system sufficiently powerful to perform basic arithmetic, let us call it system <RT·math>S</RT·math>, will inevitably contain well-formed formulas that are mathematically true yet cannot be proven within the system itself <RT·endnote>For the definitive English translation, see Jean van Heijenoort, <em>From Frege to Gödel: A Source Book in Mathematical Logic, 1879 1931</em> (Cambridge: Harvard University Press, 1967), 596 616.</RT·endnote>. Gödel achieved this by engineering a specific formula that evaluates to the claim: "<RT·math>G</RT·math>: There exists no sequence of valid logical steps within system <RT·math>S</RT·math> that proves <RT·math>G</RT·math>." If system <RT·math>S</RT·math> is consistent, it cannot output a proof for <RT·math>G</RT·math>; thus, the claim <RT·math>G</RT·math> makes is factually accurate, rendering it true but mechanically unprovable. Furthermore, Gödel demonstrated that system <RT·math>S</RT·math> cannot output a proof of its own consistency. This result fractured David Hilbert's 1900 vision of utilizing a weaker, strictly "finitistic" logical subsystem to definitively prove that the axioms of arithmetic are entirely free of contradictions <RT·endnote>David Hilbert, "Mathematical Problems," <em>Bulletin of the American Mathematical Society</em> 8 (1902): 437 479.</RT·endnote>. If the full, powerful system <RT·math>S</RT·math> physically lacks the mechanical capacity to verify its own consistency, Hilbert's weaker finitistic subsystem is definitively incapable of accomplishing the task. Gödel's work established a hard mechanical boundary, asserting that truth and provability are distinct concepts in classical mathematics.
+ In 1931 Kurt Gödel published his incompleteness theorems <RT·endnote>Kurt Gödel, "Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I," <em>Monatshefte für Mathematik und Physik</em> 38 (1931): 173–198.</RT·endnote>. By mapping formal logic into arithmetic, he demonstrated that any consistent formal system sufficiently powerful to perform basic arithmetic, let us call it system <RT·math>F</RT·math>, will inevitably contain well-formed formulas that are mathematically true yet cannot be proven within the system itself <RT·endnote>For the definitive English translation, see Jean van Heijenoort, <em>From Frege to Gödel: A Source Book in Mathematical Logic, 1879–1931</em> (Cambridge: Harvard University Press, 1967), 596–616.</RT·endnote>. Gödel achieved this by engineering a specific formula that evaluates to the claim: "<RT·math>G</RT·math>: There exists no sequence of valid logical steps within system <RT·math>F</RT·math> that proves <RT·math>G</RT·math>." If system <RT·math>F</RT·math> is consistent, it cannot output a proof for <RT·math>G</RT·math>; thus, the claim <RT·math>G</RT·math> makes is factually accurate, rendering it true but mechanically unprovable. Furthermore, Gödel demonstrated that system <RT·math>F</RT·math> cannot output a proof of its own consistency. This result fractured David Hilbert's 1900 vision of utilizing a weaker, strictly "finitistic" logical subsystem to definitively prove that the axioms of arithmetic are entirely free of contradictions <RT·endnote>David Hilbert, "Mathematical Problems," <em>Bulletin of the American Mathematical Society</em> 8 (1902): 437–479.</RT·endnote>. If the full, powerful system <RT·math>F</RT·math> lacks the mechanical capacity to verify its own consistency, Hilbert's weaker finitistic subsystem is definitively incapable of accomplishing the task. Gödel's work established a hard mechanical boundary, asserting that truth and provability are distinct concepts in classical mathematics.
</p>
<p>
- In April 1936, Alonzo Church leveraged Gödel's foundational papers to directly answer the Entscheidungsproblem <RT·endnote>Alonzo Church, "An Unsolvable Problem of Elementary Number Theory," <em>American Journal of Mathematics</em> 58, no. 2 (April 1936): 345 363.</RT·endnote>. Working independently, Alan Turing had arrived at his own mechanical solution, and upon seeing Church's April publication, Turing rushed to submit his manuscript on 28 May 1936, appending a proof that his mechanical architecture was mathematically equivalent to Church's lambda calculus <RT·endnote>Alan M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem," <em>Proceedings of the London Mathematical Society</em> s2 42, no. 1 (1936): 230 265. Received May 28, 1936, published November 30, 1936.</RT·endnote>. As Hilbert and Ackermann concede in the 1938 second edition of their textbook, Church's results demonstrated that "the quest for a general solution of the decision problem must be regarded as hopeless" <RT·endnote>David Hilbert and Wilhelm Ackermann, <em>Principles of Mathematical Logic</em>, 2nd ed. (New York: Chelsea Publishing Company, 1950), 124.</RT·endnote>. By giving the "somewhat vague intuitive concept of recursion a certain precise formalization," Church proved the "non-existence of such a recursive procedure" that could mechanically yield a value of truth or falsehood for every individual formula <RT·endnote>Ibid., 124.</RT·endnote>.
+ In 1936-03, Alonzo Church leveraged Gödel's foundational papers to directly answer the Entscheidungsproblem <RT·endnote>Alonzo Church, "A Note on the Entscheidungsproblem," <em>The Journal of Symbolic Logic</em> 1, no. 1 (March 1936): 40–41; correction, <em>The Journal of Symbolic Logic</em> 1, no. 3 (September 1936): 101–102.</RT·endnote>, resting that argument on the unsolvability result he published the following month <RT·endnote>Alonzo Church, "An Unsolvable Problem of Elementary Number Theory," <em>American Journal of Mathematics</em> 58, no. 2 (April 1936): 345–363.</RT·endnote>. Working independently, Alan Turing had arrived at his own mechanical solution, and upon seeing Church's work, Turing rushed to submit his manuscript, which was received on 1936-05-28 <RT·endnote>Alan M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem," <em>Proceedings of the London Mathematical Society</em> s2 42, no. 1 (1936): 230–265. Received May 28, 1936, read November 12, 1936.</RT·endnote>. On 1936-08-28 he appended a proof that his mechanical architecture was mathematically equivalent to Church's lambda calculus.
</p>
-
<p>
- Alan Turing used an abstraction of a computing machine, also described as a clerk working at a desk with pen and squares on paper while following a procedure, to prove that no primary 'analyzer' program can universally decide whether a second 'studied' program will halt when it is run <RT·endnote>Alan M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem," <em>Proceedings of the London Mathematical Society</em> s2 42, no. 1 (1936): 230 265.</RT·endnote>. An answer to this <RT·term>halting problem</RT·term> (specifically asserting "The studied machine halts" or "The studied machine does not halt") would indeed be a statement in first order logic. Thus, by showing no analyzer can universally make such a determination, Turing proved that no decider could exist for the Entscheidungsproblem.
+ Alan Turing used an abstraction of a computing machine, also described as a clerk working at a desk with pen and squares on paper while following a procedure, to prove that no primary 'analyzer' program can universally decide whether a second 'studied' program will halt when it is run <RT·endnote>Ibid.</RT·endnote>. An answer to this <RT·term>halting problem</RT·term> (specifically asserting "The studied machine halts" or "The studied machine does not halt") would indeed be a statement in first order logic. Thus, by showing no analyzer can universally make such a determination, Turing proved that no decider could exist for the Entscheidungsproblem.
</p>
Turing employed an enumerative diagonal argument to establish this result. A simpler proof by contradiction that is commonly used today was first published by Christopher Strachey in 1965 <RT·endnote>Christopher Strachey, "An Impossible Program," <em>The Computer Journal</em> 7, no. 4 (January 1965): 313. In his letter, Strachey explicitly attributed the distilled logic to an existing "well known piece of folklore among programmers."</RT·endnote>. To begin the proof, assume a person builds a perfect decider program, <RT·math>H(p, i)</RT·math>, that evaluates any given program <RT·math>p</RT·math> executing with input <RT·math>i</RT·math>, then outputs 'Y' if <RT·math>p(i)</RT·math> halts, and 'N' if it does not halt. Next, a person writes a malicious program, <RT·math>M(x)</RT·math>, that incorporates <RT·math>H</RT·math> as a subroutine. When <RT·math>M</RT·math> receives an input program <RT·math>x</RT·math>, it evaluates <RT·math>H(x, x)</RT·math> to determine how program <RT·math>x</RT·math> behaves when given itself as input. If <RT·math>H(x, x)</RT·math> outputs 'Y', <RT·math>M</RT·math> enters an infinite loop; if <RT·math>H(x, x)</RT·math> outputs 'N', <RT·math>M</RT·math> immediately halts.
</p>
- <RT·code>
- M(x){
- if(H(x ,x) == 'Y') while(true);
- else if(H(x ,x) == 'N') return;
- }
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·halting_diagonal-machine">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·halting_diagonal-machine"></RT·counter·snapshot>
+ <RT·code>
+ M( x ){
+ if( H(x ,x) == 'Y' ) while( true );
+ else if( H(x ,x) == 'N' ) return;
+ }
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·halting_diagonal-machine"></RT·counter·read>. <RT·name>The diagonal machine that defeats a supposed halting decider</RT·name>
+ </RT·counter·step>
<p>
The evil part occurs when we give program <RT·math>M(x)</RT·math> itself as input, <RT·math>M(M)</RT·math>. Program <RT·math>M</RT·math> calls its subroutine and asks <RT·math>H(M, M)</RT·math> what <RT·math>M</RT·math> will do. If <RT·math>H</RT·math> outputs 'Y', it is wrong, because <RT·math>M</RT·math> loops infinitely. If <RT·math>H</RT·math> outputs 'N', then it is wrong, because <RT·math>M</RT·math> halts. The decider <RT·math>H</RT·math> is forced into an inescapable failure, proving that no universal decider can exist.
</p>
<p>
- While Gödel, Church, and Turing established the primary boundaries of computation, they did not work in a vacuum. During this period, the broader academic community worked to synthesize the definitive mechanics of effective calculability. Jacques Herbrand and Gödel formalized general recursive functions between 1931 and 1934 <RT·endnote>Kurt Gödel, "On Undecidable Propositions of Formal Mathematical Systems," mimeographed lecture notes, Institute for Advanced Study, Princeton, 1934.</RT·endnote>. Emil Post independently defined "Finite Combinatory Processes" in 1936, outlining a theoretical architecture functionally identical to Turing's model <RT·endnote>Emil L. Post, "Finite Combinatory Processes Formulation 1," <em>The Journal of Symbolic Logic</em> 1, no. 3 (September 1936): 103 105.</RT·endnote>. Stephen Kleene subsequently unified these disparate threads, proving the strict mathematical equivalence of Church's lambda calculus, Herbrand-Gödel recursive functions, and Turing's mechanical architectures <RT·endnote>Stephen C. Kleene, "General Recursive Functions of Natural Numbers," <em>Mathematische Annalen</em> 112 (1936): 727 742.</RT·endnote>.
+ While Gödel, Church, and Turing established the primary boundaries of computation, they did not work in a vacuum. During this period, the broader academic community worked to synthesize the definitive mechanics of effective calculability. Jacques Herbrand and Gödel formalized general recursive functions between 1931 and 1934 <RT·endnote>Kurt Gödel, "On Undecidable Propositions of Formal Mathematical Systems," mimeographed lecture notes, Institute for Advanced Study, Princeton, 1934.</RT·endnote>. Emil Post independently defined "Finite Combinatory Processes" in 1936, outlining a theoretical architecture functionally identical to Turing's model <RT·endnote>Emil L. Post, "Finite Combinatory Processes—Formulation 1," <em>The Journal of Symbolic Logic</em> 1, no. 3 (September 1936): 103–105.</RT·endnote>. Stephen Kleene subsequently unified these disparate threads, proving the strict mathematical equivalence of Church's lambda calculus and Herbrand-Gödel recursive functions <RT·endnote>Stephen C. Kleene, "General Recursive Functions of Natural Numbers," <em>Mathematische Annalen</em> 112 (1936): 727–742.</RT·endnote>. Turing supplied the remaining leg himself, showing his machines equivalent to the lambda calculus <RT·endnote>Alan M. Turing, "Computability and λ-definability," <em>The Journal of Symbolic Logic</em> 2, no. 4 (December 1937): 153–163.</RT·endnote>.
</p>
<p>
- The academic community was thus equipped with three mathematically equivalent foundations for computation theory: recursive functions, the lambda calculus, and the Turing Machine. While all three frameworks remain active subjects of study, Turing's model is unique in providing practical intuition through the abstraction of physical machines and programs. This made it the foundation of choice for computation theory textbooks by Stephen Kleene <RT·endnote>Stephen C. Kleene, <em>Introduction to Metamathematics</em> (Amsterdam: North Holland, 1952).</RT·endnote>, Martin Davis <RT·endnote>Martin Davis, <em>Computability and Unsolvability</em> (New York: McGraw Hill, 1958).</RT·endnote>, and Marvin Minsky <RT·endnote>Marvin L. Minsky, <em>Computation: Finite and Infinite Machines</em> (Englewood Cliffs: Prentice Hall, 1967).</RT·endnote>, leading to the modern standard presentations by authors such as John Hopcroft and Jeffrey Ullman <RT·endnote>John E. Hopcroft and Jeffrey D. Ullman, <em>Introduction to Automata Theory, Languages, and Computation</em> (Reading: Addison Wesley, 1979).</RT·endnote>, as well as Harry Lewis and Christos Papadimitriou <RT·endnote>Harry R. Lewis and Christos H. Papadimitriou, <em>Elements of the Theory of Computation</em> (Englewood Cliffs: Prentice Hall, 1981).</RT·endnote>.
+ The academic community was thus equipped with three mathematically equivalent foundations for computation theory: recursive functions, the lambda calculus, and the Turing Machine. While all three frameworks remain active subjects of study, Turing's model is unique in providing practical intuition through the abstraction of physical machines and programs. This made it the foundation of choice for computation theory textbooks by Stephen Kleene <RT·endnote>Stephen C. Kleene, <em>Introduction to Metamathematics</em> (Amsterdam: North-Holland, 1952).</RT·endnote>, Martin Davis <RT·endnote>Martin Davis, <em>Computability and Unsolvability</em> (New York: McGraw-Hill, 1958).</RT·endnote>, and Marvin Minsky <RT·endnote>Marvin L. Minsky, <em>Computation: Finite and Infinite Machines</em> (Englewood Cliffs: Prentice-Hall, 1967).</RT·endnote>, leading to the modern standard presentations by authors such as John Hopcroft and Jeffrey Ullman <RT·endnote>John E. Hopcroft and Jeffrey D. Ullman, <em>Introduction to Automata Theory, Languages, and Computation</em> (Reading: Addison-Wesley, 1979).</RT·endnote>, as well as Harry Lewis and Christos Papadimitriou <RT·endnote>Harry R. Lewis and Christos H. Papadimitriou, <em>Elements of the Theory of Computation</em> (Englewood Cliffs: Prentice-Hall, 1981).</RT·endnote>.
</p>
</RT·section>
</p>
<p>
- In reading Alan Turing's 1936 paper, it is striking how modern the text feels, specifically because he discusses algorithms, stored programs, and the mechanical limits of computation.
- While his contemporaries largely built purely mathematical and logical frameworks, Turing uniquely tied computation theory directly to the abstraction of machines executing stored programs. Because physical hardware capable of executing stored memory programs had not yet been invented, this explicit architectural grounding makes Turing's work remarkably prescient. Still, Turing could not formally connect the Turing Machine to modern architectures, simply because those architectures did not yet exist. Here, by <em>modern</em>, I refer to architectures utilizing random access system memory, dedicated instruction fetch streams with dynamic branching, and discrete processing units. Though Charles Babbage's 1842 Analytical Engine touched on these concepts, they would wait until the 1940s to reemerge. The practical engineering context of 1936 was limited to calculating machines programmed via patch panels. Hence, for example, there is no explanation in his paper as to why a von Neumann architecture machine (1945) running a program would exhibit the computation theoretic results derived from a computation theory based on the Turing Machine (1936).
+ In reading Alan Turing's 1936 paper, it is striking how modern the text feels, specifically because he discusses algorithms, stored programs, and the mechanical limits of computation. While his contemporaries largely built purely mathematical and logical frameworks, Turing uniquely tied computation theory directly to the abstraction of machines executing stored programs. Because physical hardware capable of executing stored memory programs had not yet been invented, this explicit architectural grounding makes Turing's work remarkably prescient. Still, Turing could not formally connect the Turing Machine to modern architectures, simply because those architectures did not yet exist. Here, by <em>modern</em>, I refer to architectures utilizing random access system memory, dedicated instruction fetch streams with dynamic branching, and discrete processing units. Though Charles Babbage's 1842 Analytical Engine touched on these concepts, they would wait until the 1940s to reemerge. The practical engineering context of 1936 was limited to calculating machines programmed via patch panels. Hence, for example, there is no explanation in his paper as to why a von Neumann architecture machine (1945) running a program would exhibit the computation theoretic results derived from a computation theory based on the Turing Machine (1936).
</p>
<p>
These are the discernible levels of the computer design abstraction stack:
</p>
- <ol>
- <li><RT·term>mathematical logic</RT·term></li>
- <li><RT·term>computation theory</RT·term></li>
- <li><RT·term>architecture</RT·term></li>
- <li><RT·term>organization</RT·term></li>
- <li><RT·term>implementation</RT·term></li>
- <li><RT·term>realization</RT·term></li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·abstraction-stack_levels">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·abstraction-stack_levels"></RT·counter·snapshot>
+ <ol>
+ <li><RT·term>mathematical logic</RT·term></li>
+ <li><RT·term>computation theory</RT·term></li>
+ <li><RT·term>architecture</RT·term></li>
+ <li><RT·term>organization</RT·term></li>
+ <li><RT·term>implementation</RT·term></li>
+ <li><RT·term>realization</RT·term></li>
+ </ol>
+ List <RT·counter·read snapshot="List·abstraction-stack_levels"></RT·counter·read>. <RT·name>The six levels of the computer design abstraction stack</RT·name>
+ </RT·counter·step>
<p>
Mathematical logic underpins the computation theory layer. Computation theory speaks of the time and space complexity of algorithms and the existence of solutions to decider problems, which in turn guides the goals of the architecture and organization layers.
</p>
<p>
- It is not a requirement of a computer organization, nor an architecture, that it be capable of physical realization. The abstract Turing Machine organization developed in a later section serves as an example. Instead, an abstract organization can serve other purposes, in this case as a stepping stone to another organization that can be realized.
+ It is not a requirement of a computer organization, nor an architecture, that it be capable of physical realization. The abstract Turing Machine organization developed in chapter <RT·counter·read snapshot="Section·TTCA_machine-design"></RT·counter·read> serves as an example. Instead, an abstract organization can serve other purposes, in this case as a stepping stone to another organization that can be realized.
</p>
<p>
When a transform applied to machine <RT·math>m_i</RT·math> produces machine <RT·math>m_{i.1}</RT·math>, and this latter machine gets the same results for the same computational inputs, and furthermore, if any computation theory analysis applied to <RT·math>m_{i.1}</RT·math> yields the same existence and big O results as it would when applied to <RT·math>m_i</RT·math>, we say that the transform is <RT·neologism>computation theoretic inconsequential</RT·neologism>. Otherwise, the transformation is said to be <RT·neologism>computation theoretic consequential</RT·neologism>. The remainder of this section defines these terms more precisely.
</p>
+ <RT·section id="Section·orders-of-analysis">
+ <RT·name>Orders of analysis</RT·name>
+
+ <p>
+ The definition just sketched turns on applying computation theory analysis to a
+ machine rather than running it. That is a distinction the reader will meet
+ repeatedly, in places that have nothing to do with transforms, so it is worth
+ settling here. A fuller treatment, and a system built upon it, comes in the
+ chapter on computational analysis, chapter
+ <RT·counter·read snapshot="Section·computational-analysis"></RT·counter·read>.
+ </p>
+
+ <p>
+ We call a program that examines another program so as to deduce properties of its results an <RT·term>analyzer</RT·term>. The program or machine definition being subjected to this evaluation is called the <RT·term>studied program</RT·term> or <RT·term>studied machine</RT·term>.
+ </p>
+
+ <p>
+ Turing Machines that halt in a finite number of steps for any finite input within a stipulated domain are said to be <RT·term>computational</RT·term> over that domain.
+ </p>
+
+ <p>
+ By definition, first order analysis is the running of programs, and it has its place.
+ Generally, when we want to know what output a computational machine will produce, the fastest route to this knowledge is to run the program. Most programs written to solve problems are most effectively run to solve those problems rather than analyzed to deduce what they will produce.
+ </p>
+
+ <p>
+ Now suppose we quantify the inputs to a computational machine over a domain and want to know a property of the machine. Perhaps, say, that it always produces an even number. If the quantification is over a large set, then it might be faster to study the machine than it would be to run the machine on every input in the domain while checking its output.
+ </p>
+
+ <p>
+ Further suppose that the quantification is over an infinite input space. Then the only option for answering a question about the properties of results from such a machine is to analyze it. This is second order analysis, also called simply <RT·term-em>analysis</RT·term-em>.
+ </p>
+
+ <p>
+ Famously, we know that universally an analyzer cannot determine if a machine is computational. This knowledge was derived by reasoning about the properties of a hypothetically existing analyzer machine. This is a third order analysis activity.
+ </p>
+ </RT·section>
+
<RT·section>
<RT·name>Definition of the same results transform property</RT·name>
Suppose we are interested in a given Turing Machine <RT·math>m_i</RT·math> where the machine will potentially be run after being given any one of a number of input tapes <RT·math>x_{i,j}</RT·math>, and for each of those inputs the same tape with the results written will be <RT·math>r_{i,j}</RT·math>, then we notate this as:
</p>
- <RT·math>
- m_i(x_{i,j}) = r_{i,j}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·machine_result_notation">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·machine_result_notation"></RT·counter·snapshot>
+ <RT·math>
+ m_i(x_{i,j}) = r_{i,j}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·machine_result_notation"></RT·counter·read> <RT·name>Machine m_i given input tape x_{i,j} writes result tape r_{i,j}</RT·name>
+ </RT·counter·step>
<p>
Here the subscripts of the same name set up a correspondence. <RT·math>x_{i,j}</RT·math> is the <RT·math>j</RT·math>th input to the machine <RT·math>m_i</RT·math>, etc. The free variable <RT·math>j</RT·math> runs over all the interesting distinct input tapes to be given to machine <RT·math>m_i</RT·math>. So for example, if we had a machine, say <RT·math>m_8</RT·math>, and we had a set of three inputs to be given to <RT·math>m_8</RT·math>, then:
</p>
- <RT·math>
- \begin{aligned}
- m_8(x_{8,0}) &= r_{8,0} \\
- m_8(x_{8,1}) &= r_{8,1} \\
- m_8(x_{8,2}) &= r_{8,2}
- \end{aligned}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·machine_result_example">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·machine_result_example"></RT·counter·snapshot>
+ <RT·math>
+ \begin{aligned}
+ m_8(x_{8,0}) &= r_{8,0} \\
+ m_8(x_{8,1}) &= r_{8,1} \\
+ m_8(x_{8,2}) &= r_{8,2}
+ \end{aligned}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·machine_result_example"></RT·counter·read> <RT·name>Machine m_8 over a set of three input tapes</RT·name>
+ </RT·counter·step>
<p>
Another machine, perhaps machine <RT·math>m_7</RT·math>, would have its own distinct inputs <RT·math>x_{7,j}</RT·math>, etc.
Now suppose that a machine <RT·math>m_{i.1}</RT·math> is the result of a transformation, <RT·math>T</RT·math>, applied to machine <RT·math>m_i</RT·math>.
</p>
- <RT·math>
- m_i \xrightarrow{T} m_{i.1}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·transform_notation">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·transform_notation"></RT·counter·snapshot>
+ <RT·math>
+ m_i \xrightarrow{T} m_{i.1}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·transform_notation"></RT·counter·read> <RT·name>Transform T carries machine m_i to machine m_{i.1}</RT·name>
+ </RT·counter·step>
<p>
We can then assign a property to transform <RT·math>T</RT·math> called its <RT·neologism>doesn't change results</RT·neologism> property, as follows. If and only if:
</p>
- <RT·math>
- \forall j \colon r_{i,j} = r_{i.1,j}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·same-results_single-machine">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·same-results_single-machine"></RT·counter·snapshot>
+ <RT·math>
+ \forall j \colon r_{i,j} = r_{i.1,j}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·same-results_single-machine"></RT·counter·read> <RT·name>The doesn't change results condition for one machine</RT·name>
+ </RT·counter·step>
<p>
then <RT·math>T</RT·math> doesn't change <RT·math>m_i</RT·math> results. Here we note that we are evaluating a specific machine <RT·math>m_i</RT·math>, so we must add the qualifier '<RT·math>m_i</RT·math> results'. It might be that for another machine with another corresponding set of interesting inputs, the transform would lead to a new machine that produces different results.
If, and only if, it is the case that
</p>
- <RT·math>
- \forall i, \forall j \colon r_{i,j} = r_{i.1,j}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·same-results_all-machines">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·same-results_all-machines"></RT·counter·snapshot>
+ <RT·math>
+ \forall i, \forall j \colon r_{i,j} = r_{i.1,j}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·same-results_all-machines"></RT·counter·read> <RT·name>The same results transform property, over all machines</RT·name>
+ </RT·counter·step>
<p>
then we can say without qualification that <RT·math>T</RT·math> is a <RT·neologism>same results transform</RT·neologism>. Though still implied are the sets of machines, tapes, and questions.
Suppose we also have a computation theory <RT·math>C</RT·math> that allows us to analyze some machines so as to answer some questions we find interesting. Suppose furthermore that among these questions are questions of time and space complexity, along with zero or more questions about decidability. Furthermore, we are given a machine, say <RT·math>m_i</RT·math>, for which these questions have answers. We represent this as:
</p>
- <RT·math>
- a_{i,k} = q_{i,k}(m_i, \{x_{i,j}\})
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·question_answer_notation">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·question_answer_notation"></RT·counter·snapshot>
+ <RT·math>
+ a_{i,k} = q_{i,k}(m_i, \{x_{i,j}\})
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·question_answer_notation"></RT·counter·read> <RT·name>A computation theoretic question and the answer it has for a machine</RT·name>
+ </RT·counter·step>
<p>
Here, <RT·math>\{x_{i,j}\}</RT·math> represents the entire domain of <RT·math>j</RT·math> tapes being passed as arguments to the question <RT·math>q_{i,k}</RT·math>. From this, we can observe that if there are <RT·math>n_k</RT·math> questions, then we will have <RT·math>n_k</RT·math> answers. Also, for a specific machine <RT·math>m_i</RT·math>, where there are <RT·math>n_j</RT·math> <RT·math>j</RT·math> values, the domain over which <RT·math>m_i</RT·math> will be analyzed will have <RT·math>n_j</RT·math> tapes in it.
As we had already discovered when determining <RT·math>T</RT·math> is a same results transform, <RT·math>T</RT·math> transforms machine <RT·math>m_i</RT·math> into machine <RT·math>m_{i.1}</RT·math>.
</p>
- <RT·math>
- m_i \xrightarrow{T} m_{i.1}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·transform_restated">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·transform_restated"></RT·counter·snapshot>
+ <RT·math>
+ m_i \xrightarrow{T} m_{i.1}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·transform_restated"></RT·counter·read> <RT·name>Transform T carries machine m_i to machine m_{i.1}, restated</RT·name>
+ </RT·counter·step>
<p>
For our specific machine <RT·math>m_i</RT·math>, if and only if:
</p>
- <RT·math>
- \forall k \colon a_{i,k} = a_{i.1,k}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·inconsequential_single-machine">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·inconsequential_single-machine"></RT·counter·snapshot>
+ <RT·math>
+ \forall k \colon a_{i,k} = a_{i.1,k}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·inconsequential_single-machine"></RT·counter·read> <RT·name>The inconsequential condition for one machine</RT·name>
+ </RT·counter·step>
<p>
then <RT·math>T</RT·math> is <RT·neologism>computation theoretic inconsequential for <RT·math>m_i</RT·math></RT·neologism>.
If, and only if, it is the case that:
</p>
- <RT·math>
- \forall i, \forall k \colon a_{i,k} = a_{i.1,k}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·inconsequential_all-machines">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·inconsequential_all-machines"></RT·counter·snapshot>
+ <RT·math>
+ \forall i, \forall k \colon a_{i,k} = a_{i.1,k}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·inconsequential_all-machines"></RT·counter·read> <RT·name>The computation theoretic inconsequential transform property</RT·name>
+ </RT·counter·step>
<p>
then we can say without qualification that <RT·math>T</RT·math> is <RT·neologism>computation theoretic inconsequential</RT·neologism>. Though still implied are the sets of machines and tapes.
<p>This definition comes from Hopcroft and Ullman's book with minor terminology changes to make it flow into the text here <RT·endnote>John E. Hopcroft and Jeffrey D. Ullman, <em>Introduction to Automata Theory, Languages, and Computation</em> (Reading: Addison Wesley, 1979).</RT·endnote>.
</p>
- <RT·math>
- M = (Q, Σ, Γ, δ, q_0, □, F)
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·conventional-machine_definition">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·conventional-machine_definition"></RT·counter·snapshot>
+ <RT·math>
+ M = (Q, Σ, Γ, δ, q_0, □, F)
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·conventional-machine_definition"></RT·counter·read> <RT·name>The conventional Turing Machine as a seven tuple</RT·name>
+ </RT·counter·step>
<p>Each component of the Machine, <RT·math>M</RT·math>, is defined as follows:</p>
- <ul>
- <li><RT·math>Q</RT·math>: The finite set of <em>states</em> of the programmed finite state machine controller.</li>
- <li><RT·math>Σ</RT·math>: The finite set of <em>input symbols</em>.</li>
- <li><RT·math>Γ</RT·math>: The complete set of <em>tape symbols</em>; <RT·math>Σ</RT·math> is always a subset of <RT·math>Γ</RT·math>.</li>
- <li><RT·math>□</RT·math>: The <RT·code>empty</RT·code> symbol. This symbol belongs exclusively to <RT·math>Γ</RT·math>, serving as a distinct tape marker rather than an input symbol. The empty symbol initially populates all cells except the finite number containing the input symbols.</li>
- <li><RT·math>δ</RT·math>: The next state function. The arguments of <RT·math>δ(q, X)</RT·math> are a state <RT·math>q</RT·math> and a tape symbol <RT·math>X</RT·math>. The value of <RT·math>δ(q, X)</RT·math>, if it is defined, is a triple <RT·math>(p, Y, D)</RT·math>, where:
- <ol>
- <li><RT·math>p</RT·math> is the next state in <RT·math>Q</RT·math>.</li>
- <li><RT·math>Y</RT·math> is the symbol in <RT·math>Γ</RT·math> written in the scanned cell, replacing the previous symbol.</li>
- <li><RT·math>D</RT·math> is a <em>direction</em>, either <RT·math>L</RT·math> or <RT·math>R</RT·math>, standing for "left" or "right," respectively, directing the head to move either left or right.</li>
- </ol>
- </li>
- <li><RT·math>q_0</RT·math>: The <em>initial state</em>, a member of <RT·math>Q</RT·math>, in which the finite control is found.</li>
-
- <li><RT·math>F</RT·math>: The set of <em>final</em> or <em>accepting</em> states, a subset of <RT·math>Q</RT·math>.</li>
- </ul>
+ <RT·counter·step counter="RT·List·counter" id="List·conventional-machine_components">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·conventional-machine_components"></RT·counter·snapshot>
+ <ul>
+ <li><RT·math>Q</RT·math>: The finite set of <em>states</em> of the programmed finite state machine controller.</li>
+ <li><RT·math>Σ</RT·math>: The finite set of <em>input symbols</em>.</li>
+ <li><RT·math>Γ</RT·math>: The complete set of <em>tape symbols</em>; <RT·math>Σ</RT·math> is always a subset of <RT·math>Γ</RT·math>.</li>
+ <li><RT·math>□</RT·math>: The <RT·code>empty</RT·code> symbol. This symbol belongs exclusively to <RT·math>Γ</RT·math>, serving as a distinct tape marker rather than an input symbol. The empty symbol initially populates all cells except the finite number containing the input symbols.</li>
+ <li><RT·math>δ</RT·math>: The next state function. The arguments of <RT·math>δ(q, X)</RT·math> are a state <RT·math>q</RT·math> and a tape symbol <RT·math>X</RT·math>. The value of <RT·math>δ(q, X)</RT·math>, if it is defined, is a triple <RT·math>(p, Y, D)</RT·math>, where:
+ <ol>
+ <li><RT·math>p</RT·math> is the next state in <RT·math>Q</RT·math>.</li>
+ <li><RT·math>Y</RT·math> is the symbol in <RT·math>Γ</RT·math> written in the scanned cell, replacing the previous symbol.</li>
+ <li><RT·math>D</RT·math> is a <em>direction</em>, either <RT·math>L</RT·math> or <RT·math>R</RT·math>, standing for "left" or "right," respectively, directing the head to move either left or right.</li>
+ </ol>
+ </li>
+ <li><RT·math>q_0</RT·math>: The <em>initial state</em>, a member of <RT·math>Q</RT·math>, in which the finite control is found.</li>
+
+ <li><RT·math>F</RT·math>: The set of <em>final</em> or <em>accepting</em> states, a subset of <RT·math>Q</RT·math>.</li>
+ </ul>
+ List <RT·counter·read snapshot="List·conventional-machine_components"></RT·counter·read>. <RT·name>The components of the conventional Turing Machine M</RT·name>
+ </RT·counter·step>
<p>I introduced the qualifier <em>programmed</em> in front of the <em>finite state machine controller</em> because each Turing Machine that accomplishes a different task has a different finite state machine controller. A <RT·term-em>program</RT·term-em> is then a set of assignments to the variable parts of the Turing Machine definition. Notice that additional variables are needed by the Turing Machine executor beyond those that appear in the definition, such as the current state variable. In alternative terminology, the definition above defines a Turing Machine <RT·term-em>type</RT·term-em>, and a set of assignments to the variable parts of the definition constitutes an <RT·term-em>instance</RT·term-em>. Accordingly, then, when a computer arithmetician says he has two Turing Machine<em>s</em>, he is saying that he has two distinct sets of Turing Machine variable assignments, and as these sets are distinct, each can be manipulated independently.</p>
<p>Hopcroft and Ullman explain a step of the machine by showing a representation of the tape with the state variable melded in to the left of the currently scanned symbol. Suppose <RT·math>δ(q, X_i) = (p, Y, L)</RT·math>; i.e., the next move is leftward. Then,
</p>
- <RT·math>
- X_1 X_2 ⋯ X_{i-1} q X_i X_{i+1} ⋯ X_n \underset{M}{⊢} X_1 X_2 ⋯ X_{i-2} p X_{i-1} Y X_{i+1} ⋯ X_n
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·instantaneous-description_left-move">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·instantaneous-description_left-move"></RT·counter·snapshot>
+ <RT·math>
+ X_1 X_2 ⋯ X_{i-1} q X_i X_{i+1} ⋯ X_n \underset{M}{⊢} X_1 X_2 ⋯ X_{i-2} p X_{i-1} Y X_{i+1} ⋯ X_n
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·instantaneous-description_left-move"></RT·counter·read> <RT·name>An instantaneous description rewritten by a leftward move</RT·name>
+ </RT·counter·step>
<p>So first the tape is <RT·math>X_1 X_2 ⋯ X_{i-1} X_i X_{i+1} ⋯ X_n</RT·math>, with the head over <RT·math>X_i</RT·math>, and in state <RT·math>q</RT·math>. Then after a step of the machine, the tape is <RT·math>X_1 X_2 ⋯ X_{i-1} Y X_{i+1} ⋯ X_n</RT·math>, with the head over <RT·math>X_{i-1}</RT·math>, and in state <RT·math>p</RT·math>. Thus <RT·math>X_i</RT·math> was overwritten with <RT·math>Y</RT·math>, and the head stepped left.
</p>
<p>Here is the programmed controller for a Turing Machine that reverses a binary string. Although by definition each state transition matches exactly one value under the head, as a practical matter, disjunctive selection is allowed via a comma list. A conjunctive phrasing for a state transition proposition would require stringing intermediate states in series.</p>
- <img src="HU_style_TM_reverse.png" class="RT·diagram" alt="HU reverse machine">
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·conventional_reverse-machine">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·conventional_reverse-machine"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="HU_style_TM_reverse.png" class="RT·diagram" alt="HU reverse machine">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·conventional_reverse-machine"></RT·counter·read>. <RT·name>A conventional Turing Machine that reverses a binary string</RT·name>
+ </RT·counter·step>
<p>Provided the site is still alive, the following YAML can be entered at TuringMachine.io to watch the machine run.</p>
- <RT·code>
- # YAML
- # Reverses a binary string using a single marker and an EOM terminator.
- input: ' 110'
- blank: ' '
- start state: q_init
- table:
- # Machine starts on the leftmost cell (a blank marker).
- # Then step right to the first input symbol.
- q_init:
- ' ': {R: q1}
-
- # Check for an empty string; exit if true. Otherwise, scan right.
- q1:
- ' ' : {L: done}
- [0 ,1]: {R: q_scan}
-
- # Scan to the rightmost digit and place the EOM terminator 'E'
- q_scan:
- [0 ,1]: R
- ' ' : {write: 'E' ,L: q2}
-
- # process the rightmost unmarked digit, writing the uniform marker '*'
- q2:
- 0 : {write: '*' ,R: s0}
- 1 : {write: '*' ,R: s1}
- ' ': {R: q5} # all digits processed, begin cleanup
-
- # carry '0' to the right end
- s0:
- ['*' ,'E' ,0 ,1]: R
- ' ' : {write: 0 ,L: q3}
-
- # carry '1' to the right end
- s1:
- ['*' ,'E' ,0 ,1]: R
- ' ' : {write: 1 ,L: q3}
-
- # return all the way to the left blank space
- q3:
- ['*' ,'E' ,0 ,1]: L
- ' ' : {R: q4}
-
- # step right to find the next unmarked digit
- q4:
- [0 ,1] : R
- ['*' ,'E']: {L: q2}
-
- # erase the markers and EOM terminator, leaving only the reversed string
- q5:
- ['*' ,'E'] : {write: ' ' ,R: q5}
- [0 ,1 ,' ']: {L: done}
-
- done:
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·conventional-reverse_YAML">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·conventional-reverse_YAML"></RT·counter·snapshot>
+ <RT·code>
+ # YAML
+ # Reverses a binary string using a single marker and an EOM terminator.
+ input: ' 110'
+ blank: ' '
+ start state: q_init
+ table:
+ # Machine starts on the leftmost cell (a blank marker).
+ # Then step right to the first input symbol.
+ q_init:
+ ' ': {R: q1}
+
+ # Check for an empty string; exit if true. Otherwise, scan right.
+ q1:
+ ' ' : {L: done}
+ [0 ,1]: {R: q_scan}
+
+ # Scan to the rightmost digit and place the EOM terminator 'E'
+ q_scan:
+ [0 ,1]: R
+ ' ' : {write: 'E' ,L: q2}
+
+ # process the rightmost unmarked digit, writing the uniform marker '*'
+ q2:
+ 0 : {write: '*' ,R: s0}
+ 1 : {write: '*' ,R: s1}
+ ' ': {R: q5} # all digits processed, begin cleanup
+
+ # carry '0' to the right end
+ s0:
+ ['*' ,'E' ,0 ,1]: R
+ ' ' : {write: 0 ,L: q3}
+
+ # carry '1' to the right end
+ s1:
+ ['*' ,'E' ,0 ,1]: R
+ ' ' : {write: 1 ,L: q3}
+
+ # return all the way to the left blank space
+ q3:
+ ['*' ,'E' ,0 ,1]: L
+ ' ' : {R: q4}
+
+ # step right to find the next unmarked digit
+ q4:
+ [0 ,1] : R
+ ['*' ,'E']: {L: q2}
+
+ # erase the markers and EOM terminator, leaving only the reversed string
+ q5:
+ ['*' ,'E'] : {write: ' ' ,R: q5}
+ [0 ,1 ,' ']: {L: done}
+
+ done:
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·conventional-reverse_YAML"></RT·counter·read>. <RT·name>The conventional reverse machine, as TuringMachine.io YAML</RT·name>
+ </RT·counter·step>
<p>By default a newly initialized machine always starts with the head on the leftmost tape cell. The input is specified to be placed one square past the initial blank on the tape. This allows the leftmost blank to be used as a reliable start of input marker later when it is scanning left. The machine begins by reading this initial blank and stepping right. If it immediately encounters another blank, the string is empty and the machine is done. Otherwise, it sweeps right to place an end of message marker, E, immediately after the string. It then enters a repetitive process: it walks left to locate the next unprocessed input symbol, overwrites it with an asterisk to mark it as read, and then carries that remembered value rightward to deposit it at the new end of the sequence. By executing this back and forth shuttle, the machine systematically builds the reversed string to the right of the E, finishing by sweeping through to erase its temporary markers.</p>
<p>The following trace demonstrates the reversal of the string "110" using the same head embedded in the tape diagram as was used above, with a small variation. Here the head position is indicated using a bullet character, while the current state is listed in the left column. The empty symbol prints as a space. If you align the first line at the top of your window and scroll down, the execution plays out like an animation.</p>
- <RT·code>
- q_init • 1 1 0
- q1 •1 1 0
- q_scan 1•1 0
- q_scan 1 1•0
- q_scan 1 1 0•
- q2 1 1•0 E
- s0 1 1 *•E
- s0 1 1 * E•
- q3 1 1 *•E 0
- q3 1 1•* E 0
- q3 1•1 * E 0
- q3 •1 1 * E 0
- q3 • 1 1 * E 0
- q4 •1 1 * E 0
- q4 1•1 * E 0
- q4 1 1•* E 0
- q2 1•1 * E 0
- s1 1 *•* E 0
- s1 1 * *•E 0
- s1 1 * * E•0
- s1 1 * * E 0•
- q3 1 * * E•0 1
- q3 1 * *•E 0 1
- q3 1 *•* E 0 1
- q3 1•* * E 0 1
- q3 •1 * * E 0 1
- q3 • 1 * * E 0 1
- q4 •1 * * E 0 1
- q4 1•* * E 0 1
- q2 •1 * * E 0 1
- s1 *•* * E 0 1
- s1 * *•* E 0 1
- s1 * * *•E 0 1
- s1 * * * E•0 1
- s1 * * * E 0•1
- s1 * * * E 0 1•
- q3 * * * E 0•1 1
- q3 * * * E•0 1 1
- q3 * * *•E 0 1 1
- q3 * *•* E 0 1 1
- q3 *•* * E 0 1 1
- q3 •* * * E 0 1 1
- q3 • * * * E 0 1 1
- q4 •* * * E 0 1 1
- q2 • * * * E 0 1 1
- q5 •* * * E 0 1 1
- q5 •* * E 0 1 1
- q5 •* E 0 1 1
- q5 •E 0 1 1
- q5 •0 1 1
- done • 0 1 1
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·conventional-reverse_trace">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·conventional-reverse_trace"></RT·counter·snapshot>
+ <RT·code>
+ q_init • 1 1 0
+ q1 •1 1 0
+ q_scan 1•1 0
+ q_scan 1 1•0
+ q_scan 1 1 0•
+ q2 1 1•0 E
+ s0 1 1 *•E
+ s0 1 1 * E•
+ q3 1 1 *•E 0
+ q3 1 1•* E 0
+ q3 1•1 * E 0
+ q3 •1 1 * E 0
+ q3 • 1 1 * E 0
+ q4 •1 1 * E 0
+ q4 1•1 * E 0
+ q4 1 1•* E 0
+ q2 1•1 * E 0
+ s1 1 *•* E 0
+ s1 1 * *•E 0
+ s1 1 * * E•0
+ s1 1 * * E 0•
+ q3 1 * * E•0 1
+ q3 1 * *•E 0 1
+ q3 1 *•* E 0 1
+ q3 1•* * E 0 1
+ q3 •1 * * E 0 1
+ q3 • 1 * * E 0 1
+ q4 •1 * * E 0 1
+ q4 1•* * E 0 1
+ q2 •1 * * E 0 1
+ s1 *•* * E 0 1
+ s1 * *•* E 0 1
+ s1 * * *•E 0 1
+ s1 * * * E•0 1
+ s1 * * * E 0•1
+ s1 * * * E 0 1•
+ q3 * * * E 0•1 1
+ q3 * * * E•0 1 1
+ q3 * * *•E 0 1 1
+ q3 * *•* E 0 1 1
+ q3 *•* * E 0 1 1
+ q3 •* * * E 0 1 1
+ q3 • * * * E 0 1 1
+ q4 •* * * E 0 1 1
+ q2 • * * * E 0 1 1
+ q5 •* * * E 0 1 1
+ q5 •* * E 0 1 1
+ q5 •* E 0 1 1
+ q5 •E 0 1 1
+ q5 •0 1 1
+ done • 0 1 1
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·conventional-reverse_trace"></RT·counter·read>. <RT·name>A step by step trace of the conventional reverse machine</RT·name>
+ </RT·counter·step>
</RT·section>
<p>The total number of steps for reversing an <RT·math>n</RT·math> symbol string:</p>
- <RT·math>
- \text{steps} =
- \begin{cases}
- 2 & \text{if } n = 0 \\
- 3n^2 + 6n + 5 & \text{if } n \ge 1
- \end{cases}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·conventional-reverse_step-count">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·conventional-reverse_step-count"></RT·counter·snapshot>
+ <RT·math>
+ \text{steps} =
+ \begin{cases}
+ 2 & \text{if } n = 0 \\
+ 3n^2 + 6n + 5 & \text{if } n \ge 1
+ \end{cases}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·conventional-reverse_step-count"></RT·counter·read> <RT·name>Steps taken by the conventional reverse machine</RT·name>
+ </RT·counter·step>
<p>This shows string reversal to be an <RT·math>O(n^2)</RT·math> complexity problem, which might appear to some programmers as a peculiar result, as the same problem can be solved in <RT·math>O(n)</RT·math> time with a C program. This justifies further analysis.</p>
<p>For a real machine, symbols are machine word encodings. For example, ASCII uses 7 data bits, so there are 128 symbols available. If the width of the word for encoding symbols is <RT·math>n</RT·math> bits, then the total number of states required for this string reverse machine is:</p>
- <RT·math>
- \text{states} = 2^n + 8
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·conventional-reverse_state-count">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·conventional-reverse_state-count"></RT·counter·snapshot>
+ <RT·math>
+ \text{states} = 2^n + 8
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·conventional-reverse_state-count"></RT·counter·read> <RT·name>States required by the conventional reverse machine</RT·name>
+ </RT·counter·step>
<p>The number of arcs in the machine:</p>
- <RT·math>
- \text{arcs} = 2^{2n} + 9(2^n) + 12
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·conventional-reverse_arc-count">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·conventional-reverse_arc-count"></RT·counter·snapshot>
+ <RT·math>
+ \text{arcs} = 2^{2n} + 9(2^n) + 12
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·conventional-reverse_arc-count"></RT·counter·read> <RT·name>Arcs required by the conventional reverse machine</RT·name>
+ </RT·counter·step>
<p>These equations show that the state controller size explodes with word width. It would be impractical to implement for all but the smallest of word sizes. This is one of the reasons that computation theory books use modest-sized symbol alphabets in their examples, perhaps the first few letters of the Latin alphabet, or the letter 's' for unary arithmetic. Previous sections discussed challenges transitioning the Turing Machine to a real architecture due to the tape length, and discussed how this could be mitigated. In contrast, there is no practical mediation for implementing a Turing Machine controller even for modest-sized real problems.</p>
<p>This raises a question: if the Turing machine is to instruct upon the limitations of real computation, what are the implications stemming from its state controller being impractical? As one such implication, when a Turing Machine proof shows that a number is computable, it doesn't necessarily instruct upon how it could be computed. When a reader picks up a text on <em>applied number theory</em>, also called <em>computer arithmetic</em>, he is unlikely to find a chapter on Turing Machines.</p>
+ <p>The observation runs the other way as well. There is not a single chapter dedicated to computation theory in Hennessy and Patterson's definitive textbook on computer architecture. <RT·endnote>John L. Hennessy and David A. Patterson, <em>Computer Architecture: A Quantitative Approach</em>, 6th ed. (Cambridge: Morgan Kaufmann, 2017).</RT·endnote></p>
+
+ <RT·counter·step counter="RT·Table·counter" id="Table·Hennessy-Patterson_chapters">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·Hennessy-Patterson_chapters"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <tbody>
+ <tr>
+ <td>Chapter 1</td>
+ <td>Fundamentals of Quantitative Design and Analysis</td>
+ </tr>
+ <tr>
+ <td>Chapter 2</td>
+ <td>Memory Hierarchy Design</td>
+ </tr>
+ <tr>
+ <td>Chapter 3</td>
+ <td>Instruction Level Parallelism and Its Exploitation</td>
+ </tr>
+ <tr>
+ <td>Chapter 4</td>
+ <td>Data Level Parallelism in Vector, SIMD, and GPU Architectures</td>
+ </tr>
+ <tr>
+ <td>Chapter 5</td>
+ <td>Thread Level Parallelism</td>
+ </tr>
+ <tr>
+ <td>Chapter 6</td>
+ <td>Warehouse Scale Computers</td>
+ </tr>
+ <tr>
+ <td>Chapter 7</td>
+ <td>Domain Specific Architectures</td>
+ </tr>
+ <tr>
+ <td>Chapter 8</td>
+ <td>The Future of Computing</td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·Hennessy-Patterson_chapters"></RT·counter·read>. <RT·name>The chapter list of Hennessy and Patterson, Computer Architecture: A Quantitative Approach</RT·name>
+ </RT·counter·step>
+
+
</RT·section>
<RT·section>
- <RT·name>Blank, empty, SP</RT·name>
+ <RT·name>The memory of emptiness</RT·name>
<p>Turing described a clerk writing symbols into squares, with the option to erase them. He states, "In some of the configurations in which the scanned square is blank (i.e. bears no symbol) the machine writes down a new symbol on the scanned square: in other configurations it erases the scanned symbol."<RT·endnote>Alan M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem," Proceedings of the London Mathematical Society, Series 2, Volume 42 (1936): 231.</RT·endnote> So initially Turing's original article uses <em>blank</em> to mean <em>no symbol</em>. However, later Turing says, "We also give numbers to the symbols ... in particular, blank = S₀ ." <RT·endnote>ibid: 239.</RT·endnote>.</p>
<p>Because emptiness is a property of a container, Turing's first statement can be modeled with a sequence of sets. For a Turing Machine tape, each sequence member is either an empty set or a singleton set. In the language of mathematics an empty tape can be defined as a empty sets:</p>
- <RT·math>
- T_0 = [ \{ \}, \{ \}, \{ \}, \dots ]
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·empty-tape_as_empty-sets">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·empty-tape_as_empty-sets"></RT·counter·snapshot>
+ <RT·math>
+ T_0 = [ \{ \}, \{ \}, \{ \}, \dots ]
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·empty-tape_as_empty-sets"></RT·counter·read> <RT·name>An empty tape written as a sequence of empty sets</RT·name>
+ </RT·counter·step>
<p>Here, each tape member set is called a <RT·term>cell</RT·term>. This definition for an empty tape is specific to Turing Machines, as in mathematics an empty sequence has zero length. An empty tape is not an empty sequence, rather it is an infinite sequence where every member is an empty set. In one sense this is a little peculiar that something said to be empty is infinite, in another sense it is consistent for the model that an empty Turing Machine tape keeps its defining characteristics. That is, it remains a single ended Turing Machine tape, where any cell of the tape could be written with a symbol value, while the basic form of the tape will not change.</p>
<p>So we might imagine a tape machine, say called machine A, where, upon attempting to read an empty cell, the machine head instead returns a control symbol representing that the cell was empty. To accomplish this, the head would have to do some work; it would have to be able to detect emptiness, and then choose to return the empty symbol instead of a read value. This feature would fix the problem of not having any defined next state behavior for an empty cell. Furthermore, suppose the inverse process is also special in that upon attempting to write the empty symbol, the machine takes action, emptying the cell out. This would facilitate an erase operation.</p>
- <RT·code>
- def read(c):
- if is_empty(c):
- return 'empty'
- else:
- return c.get()
- </RT·code>
-
- <RT·code>
- def write(c ,x):
- if not is_empty(c):
- c.pop() # Clear the cell if it holds something
- if x != 'empty':
- c.put(x) # Place the new symbol unless we are erasing
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·empty-cell_read">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·empty-cell_read"></RT·counter·snapshot>
+ <RT·code>
+ def read(c):
+ if is_empty(c):
+ return 'empty'
+ else:
+ return c.get()
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·empty-cell_read"></RT·counter·read>. <RT·name>Reading a cell that can be empty</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Code·counter" id="Code·empty-cell_write">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·empty-cell_write"></RT·counter·snapshot>
+ <RT·code>
+ def write(c ,x):
+ if not is_empty(c):
+ c.pop() # Clear the cell if it holds something
+ if x != 'empty':
+ c.put(x) # Place the new symbol unless we are erasing
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·empty-cell_write"></RT·counter·read>. <RT·name>Writing a cell, where writing the empty symbol erases it</RT·name>
+ </RT·counter·step>
<p>Now imagine machine B, where the concept of an empty cell is jettisoned, and what remains is the mere memory of emptiness, a symbol called <RT·code>empty</RT·code>. Then using the language of mathematics, the mathematician defines an initial empty tape as:</p>
- <RT·math>
- T_0 = [ \mathtt{empty}, \mathtt{empty}, \mathtt{empty}, \ldots ]
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·empty-tape_with_empty-symbol">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·empty-tape_with_empty-symbol"></RT·counter·snapshot>
+ <RT·math>
+ T_0 = [ \mathtt{empty}, \mathtt{empty}, \mathtt{empty}, \ldots ]
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·empty-tape_with_empty-symbol"></RT·counter·read> <RT·name>An empty tape written with the empty symbol</RT·name>
+ </RT·counter·step>
<p>For machine B, no modifications are required to the native <RT·code>read</RT·code> and <RT·code>write</RT·code> functions.</p>
<p>Going back to Turing's moniker of <RT·code>blank</RT·code> does limit the focus solely to machine B, because the original paper by Turing states the definition of <RT·code>blank</RT·code> meaning "no symbol", as was already discussed. Calling it <RT·code>blank</RT·code> is merely the same name colored by the engineering of wood pulp. However, there is a pleasing property of the blank, i.e. the <RT·code>empty</RT·code> symbol, that is valuable and unique to it. It prints as a space in diagrams given in text books and in the output of Turing Machine simulators. There is an analogous symbolic system that also has this characteristic, and is being leveraged in these situations: the ASCII hex 20, called SP. It prints as a space leaving an area of the paper it is printed on blank. Perhaps a better name for the ersatz <RT·code>empty</RT·code> symbol is <RT·code>SP</RT·code>.</p>
+ <p>We therefore keep both words, and give each one job. Emptiness is a property, and a property belongs to a container: a cell of machine A either holds a symbol or it does not. <RT·code>SP</RT·code> is a symbol, and a symbol belongs to an alphabet: a cell of machine B always holds one, and <RT·code>SP</RT·code> is what it holds where a cell of machine A would have been empty. Machine B has no empty cells at all, only cells holding <RT·code>SP</RT·code>. Where this book speaks of emptiness it means the property, and where it writes <RT·code>SP</RT·code> it means the symbol standing in for it.</p>
+
<p>There is more to consider about the former <RT·code>blank</RT·code>, former <RT·code>empty</RT·code>, now <RT·code>SP</RT·code> symbol. Computational theorists often describe a two-step process. First, a Turing Machine writes a string to be studied onto a tape initially filled with all <RT·code>SP</RT·code> symbols; second, the tape is moved to another Turing Machine whose purpose is to recognize a property of the string being studied. In this process, a tape is used as a communication medium, so it follows that communication theory can be applied to this messaging scenario. Messages sent on a channel must be formatted so they can be placed on the channel and later recovered. The specification for such structuring is called a communication <RT·term>protocol</RT·term>. The protocol implies a higher authority, as both the sender and the receiver must have knowledge of the same designed-in protocol. In a sense, a protocol is the meta-message sent before the message itself.</p>
<p>The intention of the later innovation of placing the <RT·code>SP</RT·code> symbol in <RT·math>Γ</RT·math> but not in <RT·math>Σ</RT·math> appears to be that of making the <RT·code>SP</RT·code> symbol serve additional duty: firstly as a default value for a cell that has never been written to, secondly to effect erasure, and now thirdly as a control component of a communications protocol. Accordingly then, this protocol was designed by mathematicians with a specific goal. They intended to make it impossible for programmers to send 'to be studied' string messages that cannot always be recovered by a receiving recognizer Turing Machine. In short, the <RT·code>SP</RT·code> symbol also serves as an in-band EOM (end of message) symbol.</p>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section>
+ <RT·section id="Section·TTCA_computation-theoretic">
<RT·name>The computation theoretic TTCA Machine</RT·name>
<p>This chapter presents a modified computation theoretic Turing Machine with three structural additions. First, it separates control flow from data flow, ensuring that payload symbols do not needlessly expand the control state machine. Second, it unifies the control and data symbol sets into a single alphabet to natively support explicit communications protocols even in the presence of recursion and self-recursion. Finally, it implements a cascading next-state evaluation hierarchy, permitting the programmer to formally define and handle meta-symbols while also making it more convenient to program communication protocols.</p>
<p>Like the <RT·code>empty</RT·code> symbol, <RT·code>unspecified</RT·code> is a meta-symbol. It describes the data, or lack thereof, rather than being the data. Specifically, the <RT·code>unspecified</RT·code> symbol says that another machine, a machine A, would have a singular alphabet symbol at the memory location, but our machine B is not being informed as to which symbol it is. Because the Turing Machine state transition function requires a specific symbol value, reading an <RT·code>unspecified</RT·code> symbol, and then using it to make a decision as though it were a concrete symbol, would be an error, unless that control path was for the very purpose of detecting this error.</p>
<p>Reasons that memory can be <RT·code>unspecified</RT·code> include:</p>
- <ol>
- <li>The memory was not initialized.</li>
- <li>The memory holds stale data written by an unrelated process, such as a reused memory allocation.</li>
- <li>The data is effectively unspecified because the program, by design, does not make decisions based upon its value.
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·unspecified_causes">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·unspecified_causes"></RT·counter·snapshot>
+ <ol>
+ <li>The memory was not initialized.</li>
+ <li>The memory holds stale data written by an unrelated process, such as a reused memory allocation.</li>
+ <li>The data is effectively unspecified because the program, by design, does not make decisions based upon its value.
+ </ol>
+ List <RT·counter·read snapshot="List·unspecified_causes"></RT·counter·read>. <RT·name>Reasons a memory location can hold an unspecified value</RT·name>
+ </RT·counter·step>
<p>An example of effectively unspecified data would be a program that reverses a string without looking at the values being reversed. A string reverse function need not inspect the value of the string; it only needs to recognize the structural boundaries established by the writing protocol. Yet the conventional Turing Machine is incapable of doing this, and worse, as we saw, there is an explosion in the number of states for the reverse string controller against word length.</p>
<RT·name>The modifications</RT·name>
<p>The specific architectural modifications are as follows:</p>
- <ol>
- <li>There is one unified alphabet <RT·math>Σ</RT·math> to which both status symbols and data symbols belong.</li>
- <li>The machine utilizes a Moore-style programmed state controller, with zero or one instruction specified per state, so that instructions are independent and managed separately from state transitions.</li>
- <li>The machine separates control flow from data flow:
- <ol>
- <li>Two registers exist within the machine: one for holding a symbol upon which control decisions are made, the <RT·code>s</RT·code> (status) register; and one for holding data upon which decisions are not based, the <RT·code>d</RT·code> (data) register.</li>
- <li>Write and read instructions are given an operand designating the target or source register respectively, either <RT·code>s</RT·code> or <RT·code>d</RT·code>.</li>
- </ol>
- </li>
- <li>The machine implements default state transitions that execute when no explicit transition is given in the main state transition table of triples (each triple being <RT·math>\langle q_i, σ, q_{i+1} \rangle</RT·math>):
- <ol>
- <li>state-specific transition default pairs, which have the form <RT·math>\langle q_i, q_{i+1} \rangle</RT·math></li>
- <li>status-specific transition default pairs, which have the form <RT·math>\langle σ, q_{i+1} \rangle</RT·math></li>
- <li>a global default transition, which has the form <RT·math>q_{i+1}</RT·math></li>
- </ol>
- </li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·TTCA_modifications">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·TTCA_modifications"></RT·counter·snapshot>
+ <ol>
+ <li>There is one unified alphabet <RT·math>Σ</RT·math> to which both status symbols and data symbols belong.</li>
+ <li>The machine utilizes a Moore-style programmed state controller, with zero or one instruction specified per state, so that instructions are independent and managed separately from state transitions.</li>
+ <li>The machine separates control flow from data flow:
+ <ol>
+ <li>Two registers exist within the machine: one for holding a symbol upon which control decisions are made, the <RT·code>s</RT·code> (status) register; and one for holding data upon which decisions are not based, the <RT·code>d</RT·code> (data) register.</li>
+ <li>Write and read instructions are given an operand designating the target or source register respectively, either <RT·code>s</RT·code> or <RT·code>d</RT·code>.</li>
+ </ol>
+ </li>
+ <li>The machine implements default state transitions that execute when no explicit transition is given in the main state transition table of triples (each triple being <RT·math>\langle q_i, σ, q_{i+1} \rangle</RT·math>):
+ <ol>
+ <li>state-specific transition default pairs, which have the form <RT·math>\langle q_i, q_{i+1} \rangle</RT·math></li>
+ <li>status-specific transition default pairs, which have the form <RT·math>\langle σ, q_{i+1} \rangle</RT·math></li>
+ <li>a global default transition, which has the form <RT·math>q_{i+1}</RT·math></li>
+ </ol>
+ </li>
+ </ol>
+ List <RT·counter·read snapshot="List·TTCA_modifications"></RT·counter·read>. <RT·name>The architectural modifications that distinguish the TTCA Machine</RT·name>
+ </RT·counter·step>
<p>Here the subscript <RT·math>i</RT·math> is a device used to emphasize that <RT·math>q_i</RT·math> and <RT·math>q_{i+1}</RT·math> can be any members of the total set of states, <RT·math>Q</RT·math>. State <RT·math>q_0</RT·math> refers specifically to the initial state. Also note, later the spartan <RT·math>q</RT·math> will be used to denote the contents of the <RT·code>q register</RT·code>, the current state register.</p>
<p>The Hopcroft and Ullman machine definition specified a next state function, <RT·math>δ</RT·math>. Here we instead use next state tables that cascade, and as tables are containers, we denote these using a capital letter as <RT·math>Δ_0</RT·math>, <RT·math>Δ_1</RT·math>, <RT·math>Δ_2</RT·math>, and <RT·math>Δ_3</RT·math>.
<p>The new machine evaluates next-state transitions through these four layers, in order, progressing to the next layer only when no transition is found in the prior layer:</p>
- <ol>
- <li><strong>Conditional (<RT·math>Δ_0</RT·math>):</strong> Selects the transition rule that matches the current state and the value of the status register.</li>
- <li><strong>State Default (<RT·math>Δ_1</RT·math>):</strong> Selects the default transition rule that matches the current state.</li>
- <li><strong>Status Default (<RT·math>Δ_2</RT·math>):</strong> Selects the default transition rule that matches the current machine status.</li>
- <li><strong>Global Default (<RT·math>Δ_3</RT·math>):</strong> A single table that holds the next state of last resort.</li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·transition_layers">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·transition_layers"></RT·counter·snapshot>
+ <ol>
+ <li><strong>Conditional (<RT·math>Δ_0</RT·math>):</strong> Selects the transition rule that matches the current state and the value of the status register.</li>
+ <li><strong>State Default (<RT·math>Δ_1</RT·math>):</strong> Selects the default transition rule that matches the current state.</li>
+ <li><strong>Status Default (<RT·math>Δ_2</RT·math>):</strong> Selects the default transition rule that matches the current machine status.</li>
+ <li><strong>Global Default (<RT·math>Δ_3</RT·math>):</strong> A single table that holds the next state of last resort.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·transition_layers"></RT·counter·read>. <RT·name>The four next state transition layers, in evaluation order</RT·name>
+ </RT·counter·step>
<p>Programmers will typically use the Global Default arc, <RT·math>Δ_3</RT·math>, to take the machine to an error state when they have mistakenly left the next state transition undefined. However, it is conceivable for some machines that if no other next state is defined, there is a single logical state that should be visited, and this condition is not an error. If no Global Default arc is specified, and no next state is found, the machine hangs.</p>
<RT·section>
<RT·name>The TTCA Machine fixed part</RT·name>
- <RT·math>
- \mathit{MF} = (\mathit{QF}, \mathit{ΣF}, \mathit{AF})
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_fixed-part">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_fixed-part"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{MF} = (\mathit{QF}, \mathit{ΣF}, \mathit{AF})
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_fixed-part"></RT·counter·read> <RT·name>MF, the fixed part of the TTCA Machine</RT·name>
+ </RT·counter·step>
<p>In the following, the middle dot acts as a namespace operator, <RT·math>N{·}x</RT·math>. By doing this we assure there will be no aliasing with the symbols provided by the programmer when he defines a programmed state controller.</p>
<p>The set of predefined <em>states</em>:</p>
- <RT·math>
- \mathit{QF} = \{\mathit{QF}{·}\mathtt{initial}\}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_fixed-states">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_fixed-states"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{QF} = \{\mathit{QF}{·}\mathtt{initial}\}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_fixed-states"></RT·counter·read> <RT·name>QF, the set of predefined states</RT·name>
+ </RT·counter·step>
<p>The state controller always starts in the <RT·code>QF·initial</RT·code> state. This is a symbol representing the state; it is not a register that holds a state. The 'F' values are all fixed.</p>
<p>The programmer cannot add instructions to the machine definition, so there are no symbol aliasing issues here:</p>
- <RT·math>
- \begin{aligned}
- \mathit{AF} = \{& \\
- & \mathtt{no\_op} \\
- ,& \mathtt{left} \\
- ,& \mathtt{right} \\
- ,& \mathtt{read}(\mathtt{d} \mid \mathtt{s}) \\
- ,& \mathtt{status} \\
- ,& \mathtt{write}(\mathtt{d} \mid \mathtt{s} \mid \mathtt{σ}, [σ]) \\
- \}
- \end{aligned}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_fixed-instructions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_fixed-instructions"></RT·counter·snapshot>
+ <RT·math>
+ \begin{aligned}
+ \mathit{AF} = \{& \\
+ & \mathtt{no\_op} \\
+ ,& \mathtt{left} \\
+ ,& \mathtt{right} \\
+ ,& \mathtt{read}(\mathtt{d} \mid \mathtt{s}) \\
+ ,& \mathtt{status} \\
+ ,& \mathtt{write}(\mathtt{d} \mid \mathtt{s} \mid \mathtt{σ}, [σ]) \\
+ \}
+ \end{aligned}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_fixed-instructions"></RT·counter·read> <RT·name>AF, the set of predefined instructions</RT·name>
+ </RT·counter·step>
<p>where <RT·math>σ</RT·math> must be in <RT·math>Σ</RT·math>.</p>
<p>The set of predefined symbols:</p>
- <RT·math>
- \mathit{ΣF} = \{\mathit{ΣF}{·}\mathtt{leftmost}\}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_fixed-symbols">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_fixed-symbols"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{ΣF} = \{\mathit{ΣF}{·}\mathtt{leftmost}\}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_fixed-symbols"></RT·counter·read> <RT·name>ΣF, the set of predefined symbols</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
<RT·name>Machine variables</RT·name>
- <RT·math>
- \mathit{MV} = (q, s, d)
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_machine-variables">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_machine-variables"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{MV} = (q, s, d)
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_machine-variables"></RT·counter·read> <RT·name>MV, the machine variables</RT·name>
+ </RT·counter·step>
<p><RT·code>q</RT·code>: is the current state of the machine.</p>
<RT·section>
<RT·name>Programmable part</RT·name>
- <RT·math>
- \mathit{MP} = (\mathit{QP}, \mathit{ΣP}, \mathit{ΛP}, Δ_0, Δ_1, Δ_2, Δ_3, \mathit{HP})
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_programmable-part">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_programmable-part"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{MP} = (\mathit{QP}, \mathit{ΣP}, \mathit{ΛP}, Δ_0, Δ_1, Δ_2, Δ_3, \mathit{HP})
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_programmable-part"></RT·counter·read> <RT·name>MP, the programmable part of the TTCA Machine</RT·name>
+ </RT·counter·step>
<p>A set of programmed <em>state</em> symbols:</p>
- <RT·math>
- \mathit{QP}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_programmed-states">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_programmed-states"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{QP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_programmed-states"></RT·counter·read> <RT·name>QP, the set of programmed state symbols</RT·name>
+ </RT·counter·step>
<p>A set of programmed data symbols:</p>
- <RT·math>
- \mathit{ΣP}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_programmed-symbols">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_programmed-symbols"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{ΣP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_programmed-symbols"></RT·counter·read> <RT·name>ΣP, the set of programmed data symbols</RT·name>
+ </RT·counter·step>
<p>The programmed instructions. A set of pairs of the form:</p>
- <RT·math>
- \mathit{ΛP} = \{ \langle q_i, a \rangle, \dots \}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_programmed-instructions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_programmed-instructions"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{ΛP} = \{ \langle q_i, a \rangle, \dots \}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_programmed-instructions"></RT·counter·read> <RT·name>ΛP, the programmed instructions, as state and action pairs</RT·name>
+ </RT·counter·step>
<p>where <RT·math>q_i</RT·math> is matched to the current state, and <RT·math>a</RT·math> is a member of <RT·math>\mathit{A}</RT·math>.
</p>
<p>The conditional transition table. A set of state transition triples; each triple is of the form:</p>
- <RT·math>
- Δ_0 = \{ \langle q_i, σ, q_{i+1} \rangle, \dots \}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_conditional-transitions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_conditional-transitions"></RT·counter·snapshot>
+ <RT·math>
+ Δ_0 = \{ \langle q_i, σ, q_{i+1} \rangle, \dots \}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_conditional-transitions"></RT·counter·read> <RT·name>Δ₀, the conditional transition table</RT·name>
+ </RT·counter·step>
<p>Here <RT·math>q_i</RT·math> and <RT·math>q_{i+1}</RT·math> are two states from the total set of <RT·math>Q</RT·math>. They need not be distinct. While the machine is running, state <RT·math>q_i</RT·math> is to be matched against the contents of the <RT·code>q register</RT·code>, the current state. Symbol <RT·math>σ</RT·math> is a member of the total set <RT·math>Σ</RT·math> and is to be matched against the contents of the <RT·code>s register</RT·code>, the machine status. When <RT·math>q_i</RT·math> matches the current state and <RT·math>σ</RT·math> matches the current status, then <RT·math>q_{i+1}</RT·math> becomes the next state.</p>
<p>The state default transition table. A set of state transition pairs; each pair is of the form:</p>
- <RT·math>
- Δ_1 = \{ \langle q_i, q_{i+1} \rangle, \dots \}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_state-default-transitions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_state-default-transitions"></RT·counter·snapshot>
+ <RT·math>
+ Δ_1 = \{ \langle q_i, q_{i+1} \rangle, \dots \}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_state-default-transitions"></RT·counter·read> <RT·name>Δ₁, the state default transition table</RT·name>
+ </RT·counter·step>
<p>where <RT·math>q_i</RT·math> is matched to the current state, and upon a match <RT·math>q_{i+1}</RT·math> will be taken as the next state.</p>
<p>The status default transition table. A set of state transition pairs; each pair is of the form:</p>
- <RT·math>
- Δ_2 = \{ \langle σ, q_{i+1} \rangle, \dots \}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_status-default-transitions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_status-default-transitions"></RT·counter·snapshot>
+ <RT·math>
+ Δ_2 = \{ \langle σ, q_{i+1} \rangle, \dots \}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_status-default-transitions"></RT·counter·read> <RT·name>Δ₂, the status default transition table</RT·name>
+ </RT·counter·step>
<p>where <RT·math>σ</RT·math> matches the symbol in <RT·code>s register</RT·code>, and upon a match <RT·math>q_{i+1}</RT·math> will be taken as the next state.</p>
<p>The global default next state:</p>
- <RT·math>
- Δ_3 = q_{i+1}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_global-default-transition">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_global-default-transition"></RT·counter·snapshot>
+ <RT·math>
+ Δ_3 = q_{i+1}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_global-default-transition"></RT·counter·read> <RT·name>Δ₃, the global default next state</RT·name>
+ </RT·counter·step>
<p>This is the transition of last resort. It is unconditional; the next state becomes <RT·math>q_{i+1}</RT·math>.</p>
<p>A set of programmer-defined halting states:</p>
- <RT·math>
- \mathit{HP}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_halt-states">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_halt-states"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{HP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_halt-states"></RT·counter·read> <RT·name>HP, the set of programmed halting states</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
<RT·name>The TTCA Machine definition in total</RT·name>
- <RT·math>
- M = (q, s, d, Q, Σ, A, Λ, Δ, H)
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_machine_definition">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_machine_definition"></RT·counter·snapshot>
+ <RT·math>
+ M = (q, s, d, Q, Σ, A, Λ, Δ, H)
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_machine_definition"></RT·counter·read> <RT·name>The TTCA Machine in total</RT·name>
+ </RT·counter·step>
<p>The variables used by the executor, <RT·math>\mathit{MV} = (q, s, d)</RT·math>.</p>
<p>The complete set of states, uniting the fixed predefined states and the programmed states:</p>
- <RT·math>
- Q = \mathit{QF} \cup \mathit{QP}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_state-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_state-set"></RT·counter·snapshot>
+ <RT·math>
+ Q = \mathit{QF} \cup \mathit{QP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_state-set"></RT·counter·read> <RT·name>Q, the complete state set, fixed united with programmed</RT·name>
+ </RT·counter·step>
<p>The complete set of symbols, uniting the fixed control symbols and the programmed data symbols:</p>
- <RT·math>
- Σ = \mathit{ΣF} \cup \mathit{ΣP}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_symbol-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_symbol-set"></RT·counter·snapshot>
+ <RT·math>
+ Σ = \mathit{ΣF} \cup \mathit{ΣP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_symbol-set"></RT·counter·read> <RT·name>Σ, the complete symbol set, fixed united with programmed</RT·name>
+ </RT·counter·step>
<p>All members of the set of available instructions are fixed:</p>
- <RT·math>
- A = \mathit{AF}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_instruction-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_instruction-set"></RT·counter·snapshot>
+ <RT·math>
+ A = \mathit{AF}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_instruction-set"></RT·counter·read> <RT·name>A, the instruction set, entirely fixed</RT·name>
+ </RT·counter·step>
<p>The table of state-instruction pairs is strictly programmed.</p>
- <RT·math>
- Λ = \mathit{ΛP}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_instruction-table">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_instruction-table"></RT·counter·snapshot>
+ <RT·math>
+ Λ = \mathit{ΛP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_instruction-table"></RT·counter·read> <RT·name>Λ, the instruction table, entirely programmed</RT·name>
+ </RT·counter·step>
<p>The ordered sequence of next state transition rules:</p>
- <RT·math>
- Δ = [Δ_0 \mid Δ_1 \mid Δ_2 \mid Δ_3]
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_transition-sequence">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_transition-sequence"></RT·counter·snapshot>
+ <RT·math>
+ Δ = [Δ_0 \mid Δ_1 \mid Δ_2 \mid Δ_3]
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_transition-sequence"></RT·counter·read> <RT·name>Δ, the transition rules as an ordered sequence</RT·name>
+ </RT·counter·step>
<p>The set of halt states is strictly programmed, and thus could be empty.</p>
- <RT·math>
- H = \mathit{HP}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA_halt-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA_halt-set"></RT·counter·snapshot>
+ <RT·math>
+ H = \mathit{HP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA_halt-set"></RT·counter·read> <RT·name>H, the halt state set, entirely programmed</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
<RT·name>Initialization stage</RT·name>
<p>Before the first cycle begins, a tape is selected and mounted. The read/write head is positioned over the leftmost tape cell. The machine variables are initialized as follows:</p>
- <ul>
- <li>The current state <RT·code>q</RT·code> is set to <RT·math>\mathit{QF}{·}\mathtt{initial}</RT·math>.</li>
- <li>The data register <RT·code>d</RT·code> is initialized to hold the <RT·math>\mathit{ΣF}{·}\mathtt{unspecified}</RT·math> symbol.</li>
- <li>The status register <RT·code>s</RT·code> is initialized to hold the <RT·math>\mathit{ΣF}{·}\mathtt{unspecified}</RT·math> symbol.</li>
- </ul>
+ <RT·counter·step counter="RT·List·counter" id="List·initialization_values">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·initialization_values"></RT·counter·snapshot>
+ <ul>
+ <li>The current state <RT·code>q</RT·code> is set to <RT·math>\mathit{QF}{·}\mathtt{initial}</RT·math>.</li>
+ <li>The data register <RT·code>d</RT·code> is initialized to hold the <RT·math>\mathit{ΣF}{·}\mathtt{unspecified}</RT·math> symbol.</li>
+ <li>The status register <RT·code>s</RT·code> is initialized to hold the <RT·math>\mathit{ΣF}{·}\mathtt{unspecified}</RT·math> symbol.</li>
+ </ul>
+ List <RT·counter·read snapshot="List·initialization_values"></RT·counter·read>. <RT·name>The initial values given to the machine variables</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
<RT·name>Phase 1: Instruction issue and execution</RT·name>
- <ol>
- <li>Given the current state <RT·code>q</RT·code>, lookup the instruction <RT·math>λ</RT·math>, within the instruction table <RT·math>Λ</RT·math>.</li>
- <li>Perform the instruction <RT·math>λ</RT·math>.</li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·phase-1_steps">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·phase-1_steps"></RT·counter·snapshot>
+ <ol>
+ <li>Given the current state <RT·code>q</RT·code>, lookup the instruction <RT·math>λ</RT·math>, within the instruction table <RT·math>Λ</RT·math>.</li>
+ <li>Perform the instruction <RT·math>λ</RT·math>.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·phase-1_steps"></RT·counter·read>. <RT·name>The two steps of instruction issue and execution</RT·name>
+ </RT·counter·step>
<p>If the instruction is <RT·code>left</RT·code> and the machine walks off the tape, the machine hangs.</p>
</RT·section>
<p>Because the TTCA Machine separates the data path from the control path, it is possible to reverse a string without inspecting the payload. The programmed controller only needs to recognize the structural boundaries of the data protocol. When a payload symbol is encountered, the controller executes a <RT·code>read(d)</RT·code> instruction, placing the value into the data register, which is not examined for decision-making purposes. When a value is used to base a decision upon, the controller executes a <RT·code>read(s)</RT·code>, placing the value into the status register. Because instructions are bound to states rather than transitions, reading and stepping are distinct states. This combination of features results in a controller that has threads of serialized execution.</p>
- <RT·code>
- # TTCA Machine String Reverse
- # Domains:
- # ΣP = {0 ,1 ,EOM ,EOR ,SP}
- # Σ_data = ΣP \ {EOM ,EOR ,SP}
- # input: (σ ∈ Σ_data)* EOM (starting on the leftmost cell)
- # output: SP* EOM (σ ∈ Σ_data in reverse)* EOR
-
- halt: Q·Done
-
- table:
- # Phase 1: Scan right to EOM and initialize the EOR marker.
- Q·initial:
- λ: read(s)
- δ:
- (EOM: Q·Setup_EOR)
- Q·Search_EOM_0
-
- Q·Search_EOM_0:
- λ: right
- δ:
- Q·initial
-
- Q·Setup_EOR:
- λ: right
- δ:
- Q·Write_EOR
-
- Q·Write_EOR:
- λ: write(σ ,EOR)
- δ:
- Q·Fetch_0
-
- # Phase 2: Fetch the next unprocessed symbol and check boundaries.
- Q·Fetch_0:
- λ: left
- δ:
- Q·Fetch_1
-
- Q·Fetch_1:
- λ: read(s)
- δ:
- (EOM: Q·Check_Boundary)
- (SP: Q·Check_Boundary)
- Q·Read_Data
-
- Q·Check_Boundary:
- λ: status
- δ:
- (leftmost: Q·Done)
- Q·Fetch_0
-
- Q·Read_Data:
- λ: read(d)
- δ:
- Q·Check_Last_Char
-
- Q·Check_Last_Char:
- λ: status
- δ:
- (leftmost: Q·Place_Last)
- Q·Place_SP
-
- # Phase 3: Mark the location and carry the opaque data rightward.
- Q·Place_SP:
- λ: write(σ ,SP)
- δ:
- Q·Carry_0
-
- Q·Carry_0:
- λ: right
- δ:
- Q·Carry_1
-
- Q·Carry_1:
- λ: read(s)
- δ:
- (EOR: Q·Drop)
- Q·Carry_0
-
- # Phase 4: Deposit the data and advance the EOR boundary.
- Q·Drop:
- λ: write(d)
- δ:
- Q·Advance_EOR_0
-
- Q·Advance_EOR_0:
- λ: right
- δ:
- Q·Advance_EOR_1
-
- Q·Advance_EOR_1:
- λ: write(σ ,EOR)
- δ:
- Q·Return_0
-
- # Phase 5: Return left to the EOM to begin the next fetch cycle.
- Q·Return_0:
- λ: left
- δ:
- Q·Return_1
-
- Q·Return_1:
- λ: read(s)
- δ:
- (EOM: Q·Fetch_0)
- Q·Return_0
-
- # Phase 6: Final symbol carry and clean halt.
- Q·Place_Last:
- λ: write(σ ,SP)
- δ:
- Q·Carry_Last_0
-
- Q·Carry_Last_0:
- λ: right
- δ:
- Q·Carry_Last_1
-
- Q·Carry_Last_1:
- λ: read(s)
- δ:
- (EOR: Q·Drop_Last)
- Q·Carry_Last_0
-
- Q·Drop_Last:
- λ: write(d)
- δ:
- Q·Advance_EOR_Last_0
-
- Q·Advance_EOR_Last_0:
- λ: right
- δ:
- Q·Advance_EOR_Last_1
-
- Q·Advance_EOR_Last_1:
- λ: write(σ ,EOR)
- δ:
- Q·Done
- </RT·code>
-
- <img src="TTCA_style_TM_reverse.png" class="RT·diagram" alt="TTCAM reverse machine">
+ <RT·counter·step counter="RT·Code·counter" id="Code·TTCA-reverse_controller">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·TTCA-reverse_controller"></RT·counter·snapshot>
+ <RT·code>
+ # TTCA Machine String Reverse
+ # Domains:
+ # ΣP = {0 ,1 ,EOM ,EOR ,SP}
+ # Σ_data = ΣP \ {EOM ,EOR ,SP}
+ # input: (σ ∈ Σ_data)* EOM (starting on the leftmost cell)
+ # output: SP* EOM (σ ∈ Σ_data in reverse)* EOR
+
+ halt: Q·Done
+
+ table:
+ # Phase 1: Scan right to EOM and initialize the EOR marker.
+ Q·initial:
+ λ: read(s)
+ δ:
+ (EOM: Q·Setup_EOR)
+ Q·Search_EOM_0
+
+ Q·Search_EOM_0:
+ λ: right
+ δ:
+ Q·initial
+
+ Q·Setup_EOR:
+ λ: right
+ δ:
+ Q·Write_EOR
+
+ Q·Write_EOR:
+ λ: write(σ ,EOR)
+ δ:
+ Q·Fetch_0
+
+ # Phase 2: Fetch the next unprocessed symbol and check boundaries.
+ Q·Fetch_0:
+ λ: left
+ δ:
+ Q·Fetch_1
+
+ Q·Fetch_1:
+ λ: read(s)
+ δ:
+ (EOM: Q·Check_Boundary)
+ (SP: Q·Check_Boundary)
+ Q·Read_Data
+
+ Q·Check_Boundary:
+ λ: status
+ δ:
+ (leftmost: Q·Done)
+ Q·Fetch_0
+
+ Q·Read_Data:
+ λ: read(d)
+ δ:
+ Q·Check_Last_Char
+
+ Q·Check_Last_Char:
+ λ: status
+ δ:
+ (leftmost: Q·Place_Last)
+ Q·Place_SP
+
+ # Phase 3: Mark the location and carry the opaque data rightward.
+ Q·Place_SP:
+ λ: write(σ ,SP)
+ δ:
+ Q·Carry_0
+
+ Q·Carry_0:
+ λ: right
+ δ:
+ Q·Carry_1
+
+ Q·Carry_1:
+ λ: read(s)
+ δ:
+ (EOR: Q·Drop)
+ Q·Carry_0
+
+ # Phase 4: Deposit the data and advance the EOR boundary.
+ Q·Drop:
+ λ: write(d)
+ δ:
+ Q·Advance_EOR_0
+
+ Q·Advance_EOR_0:
+ λ: right
+ δ:
+ Q·Advance_EOR_1
+
+ Q·Advance_EOR_1:
+ λ: write(σ ,EOR)
+ δ:
+ Q·Return_0
+
+ # Phase 5: Return left to the EOM to begin the next fetch cycle.
+ Q·Return_0:
+ λ: left
+ δ:
+ Q·Return_1
+
+ Q·Return_1:
+ λ: read(s)
+ δ:
+ (EOM: Q·Fetch_0)
+ Q·Return_0
+
+ # Phase 6: Final symbol carry and clean halt.
+ Q·Place_Last:
+ λ: write(σ ,SP)
+ δ:
+ Q·Carry_Last_0
+
+ Q·Carry_Last_0:
+ λ: right
+ δ:
+ Q·Carry_Last_1
+
+ Q·Carry_Last_1:
+ λ: read(s)
+ δ:
+ (EOR: Q·Drop_Last)
+ Q·Carry_Last_0
+
+ Q·Drop_Last:
+ λ: write(d)
+ δ:
+ Q·Advance_EOR_Last_0
+
+ Q·Advance_EOR_Last_0:
+ λ: right
+ δ:
+ Q·Advance_EOR_Last_1
+
+ Q·Advance_EOR_Last_1:
+ λ: write(σ ,EOR)
+ δ:
+ Q·Done
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·TTCA-reverse_controller"></RT·counter·read>. <RT·name>The TTCA Machine string reverse controller</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·TTCA_reverse-machine">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·TTCA_reverse-machine"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="TTCA_style_TM_reverse.png" class="RT·diagram" alt="TTCAM reverse machine">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·TTCA_reverse-machine"></RT·counter·read>. <RT·name>The TTCA Machine that reverses a binary string</RT·name>
+ </RT·counter·step>
</RT·section>
<p>The form of this diagram shows a lead-in, a long loop, and a tail leading to done. This is suggestive of code followed by a while loop that breaks out, with further code completing the program.</p>
- <RT·code>
- void TTCA·reverse_string() {
- // Initialization: Scan to EOM and setup the EOR boundary
- read('s');
- while(s != EOM){right(); read('s');}
- right();
- write('σ' ,EOR);
-
- while(true){
- // The Fetch Pivot: Locate the next unprocessed symbol
- left();
+ <RT·counter·step counter="RT·Code·counter" id="Code·TTCA-reverse_in_C">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·TTCA-reverse_in_C"></RT·counter·snapshot>
+ <RT·code>
+ void TTCA·reverse_string() {
+ // Initialization: Scan to EOM and setup the EOR boundary
read('s');
- while(s == EOM || s == SP){
- status();
- // Termination: Short-circuit for empty string
- if(s == leftmost) return;
+ while(s != EOM){right(); read('s');}
+ right();
+ write('σ' ,EOR);
+
+ while(true){
+ // The Fetch Pivot: Locate the next unprocessed symbol
left();
read('s');
- }
+ while(s == EOM || s == SP){
+ status();
+ // Termination: Short-circuit for empty string
+ if(s == leftmost) return;
+ left();
+ read('s');
+ }
+
+ read('d');
+ status();
+
+ // Center Break: Q·Check_Last_Char routes to the final chain
+ if(s == leftmost) break;
- read('d');
- status();
+ // Main Carry Loop: Mark, carry, drop, and return to pivot
+ write('σ' ,SP);
+ right();
+ read('s');
+ while(s != EOR){right(); read('s');}
+ write('d');
+ right();
+ write('σ' ,EOR);
- // Center Break: Q·Check_Last_Char routes to the final chain
- if(s == leftmost) break;
+ left();
+ read('s');
+ while(s != EOM){left(); read('s');}
+ }
- // Main Carry Loop: Mark, carry, drop, and return to pivot
+ // Final Symbol Chain: Handle the last payload without a return sweep
write('σ' ,SP);
right();
read('s');
right();
write('σ' ,EOR);
- left();
- read('s');
- while(s != EOM){left(); read('s');}
+ // Termination: Q·Done
+ return;
}
-
- // Final Symbol Chain: Handle the last payload without a return sweep
- write('σ' ,SP);
- right();
- read('s');
- while(s != EOR){right(); read('s');}
- write('d');
- right();
- write('σ' ,EOR);
-
- // Termination: Q·Done
- return;
- }
- </RT·code>
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·TTCA-reverse_in_C"></RT·counter·read>. <RT·name>The TTCA reverse controller written as C</RT·name>
+ </RT·counter·step>
<p>The total number of steps for reversing an <RT·math>n</RT·math> symbol string using the TTCA Machine:</p>
- <RT·math>
- \text{steps} =
- \begin{cases}
- 7 & \text{if } n = 0 \\
- 4.5n^2 + 11.5n + 5 & \text{if } n \ge 1
- \end{cases}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·TTCA-reverse_step-count">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·TTCA-reverse_step-count"></RT·counter·snapshot>
+ <RT·math>
+ \text{steps} =
+ \begin{cases}
+ 7 & \text{if } n = 0 \\
+ 4.5n^2 + 11.5n + 5 & \text{if } n \ge 1
+ \end{cases}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·TTCA-reverse_step-count"></RT·counter·read> <RT·name>Steps taken by the TTCA reverse machine</RT·name>
+ </RT·counter·step>
</RT·section>
<p>The reverse string machine spends a lot of time shuttling the head between two context areas: one for the original string, and one for the resulting reversed string. This suggests that a two-head version would be faster. The following is the two-head state machine definition:</p>
- <RT·code>
- # TTCA Two-Head String Reverse
- # input: (σ ∈ Σ)* EOM (starting on the leftmost cell)
- # output: SP* EOM (σ ∈ Σ in reverse)* EOR
-
- halt: Q·Done
-
- table:
- # Phase 1: Both heads scan right to the EOM pivot
- Q·initial:
- λ: read('s' ,0)
- δ:
- (EOM: Q·Check_Empty)
- Q·Scan_Right_0
-
- Q·Scan_Right_0:
- λ: right(0)
- δ:
- Q·Scan_Right_1
-
- Q·Scan_Right_1:
- λ: right(1)
- δ:
- Q·initial
-
- # Phase 2: Setup pointers for reading and writing
- Q·Check_Empty:
- λ: status(0)
- δ:
- (leftmost: Q·Empty_Setup_1)
- Q·Setup_Write_1
-
- Q·Empty_Setup_1:
- λ: right(1)
- δ:
- Q·Write_EOR_Done
-
- Q·Setup_Write_1:
- λ: right(1)
- δ:
- Q·Setup_Write_2
-
- Q·Setup_Write_2:
- λ: left(0)
- δ:
- Q·Copy_Read
-
- # Phase 3: The Linear Copy Loop
- Q·Copy_Read:
- λ: read('d' ,0)
- δ:
- Q·Copy_Status
-
- Q·Copy_Status:
- λ: status(0)
- δ:
- (leftmost: Q·Copy_Last_Erase)
- Q·Copy_Erase
-
- Q·Copy_Erase:
- λ: write('σ' ,0 ,SP)
- δ:
- Q·Copy_Write
-
- Q·Copy_Write:
- λ: write('d' ,1)
- δ:
- Q·Copy_Advance_1
-
- Q·Copy_Advance_1:
- λ: right(1)
- δ:
- Q·Copy_Advance_0
-
- Q·Copy_Advance_0:
- λ: left(0)
- δ:
- Q·Copy_Read
-
- # Phase 4: Final Symbol and Clean Halt
- Q·Copy_Last_Erase:
- λ: write('σ' ,0 ,SP)
- δ:
- Q·Copy_Last_Write
-
- Q·Copy_Last_Write:
- λ: write('d' ,1)
- δ:
- Q·Copy_Last_Advance
-
- Q·Copy_Last_Advance:
- λ: right(1)
- δ:
- Q·Write_EOR_Done
-
- Q·Write_EOR_Done:
- λ: write('σ' ,1 ,EOR)
- δ:
- Q·Done
- </RT·code>
-
- <img src="TTCA_2_hd_reverse.png" class="RT·diagram" alt="TTCAM 2 hd reverse machine">
+ <RT·counter·step counter="RT·Code·counter" id="Code·two-headed-reverse_controller">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·two-headed-reverse_controller"></RT·counter·snapshot>
+ <RT·code>
+ # TTCA Two-Head String Reverse
+ # input: (σ ∈ Σ)* EOM (starting on the leftmost cell)
+ # output: SP* EOM (σ ∈ Σ in reverse)* EOR
+
+ halt: Q·Done
+
+ table:
+ # Phase 1: Both heads scan right to the EOM pivot
+ Q·initial:
+ λ: read('s' ,0)
+ δ:
+ (EOM: Q·Check_Empty)
+ Q·Scan_Right_0
+
+ Q·Scan_Right_0:
+ λ: right(0)
+ δ:
+ Q·Scan_Right_1
+
+ Q·Scan_Right_1:
+ λ: right(1)
+ δ:
+ Q·initial
+
+ # Phase 2: Setup pointers for reading and writing
+ Q·Check_Empty:
+ λ: status(0)
+ δ:
+ (leftmost: Q·Empty_Setup_1)
+ Q·Setup_Write_1
+
+ Q·Empty_Setup_1:
+ λ: right(1)
+ δ:
+ Q·Write_EOR_Done
+
+ Q·Setup_Write_1:
+ λ: right(1)
+ δ:
+ Q·Setup_Write_2
+
+ Q·Setup_Write_2:
+ λ: left(0)
+ δ:
+ Q·Copy_Read
+
+ # Phase 3: The Linear Copy Loop
+ Q·Copy_Read:
+ λ: read('d' ,0)
+ δ:
+ Q·Copy_Status
+
+ Q·Copy_Status:
+ λ: status(0)
+ δ:
+ (leftmost: Q·Copy_Last_Erase)
+ Q·Copy_Erase
+
+ Q·Copy_Erase:
+ λ: write('σ' ,0 ,SP)
+ δ:
+ Q·Copy_Write
+
+ Q·Copy_Write:
+ λ: write('d' ,1)
+ δ:
+ Q·Copy_Advance_1
+
+ Q·Copy_Advance_1:
+ λ: right(1)
+ δ:
+ Q·Copy_Advance_0
+
+ Q·Copy_Advance_0:
+ λ: left(0)
+ δ:
+ Q·Copy_Read
+
+ # Phase 4: Final Symbol and Clean Halt
+ Q·Copy_Last_Erase:
+ λ: write('σ' ,0 ,SP)
+ δ:
+ Q·Copy_Last_Write
+
+ Q·Copy_Last_Write:
+ λ: write('d' ,1)
+ δ:
+ Q·Copy_Last_Advance
+
+ Q·Copy_Last_Advance:
+ λ: right(1)
+ δ:
+ Q·Write_EOR_Done
+
+ Q·Write_EOR_Done:
+ λ: write('σ' ,1 ,EOR)
+ δ:
+ Q·Done
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·two-headed-reverse_controller"></RT·counter·read>. <RT·name>The two headed string reverse controller</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·TTCA_two-headed_reverse-machine">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·TTCA_two-headed_reverse-machine"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="TTCA_2_hd_reverse.png" class="RT·diagram" alt="TTCAM 2 hd reverse machine">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·TTCA_two-headed_reverse-machine"></RT·counter·read>. <RT·name>A two headed TTCA Machine that reverses a binary string</RT·name>
+ </RT·counter·step>
</RT·section>
<p>The number of states has dropped from 24 to 18, while the speed increase is dramatic, with the former quadratic performance becoming linear performance. The total number of steps for reversing an <RT·math>n</RT·math> symbol string using a two-head TTCA architecture:</p>
- <RT·math>
- \text{steps} =
- \begin{cases}
- 4 & \text{if } n = 0 \\
- 9n + 4 & \text{if } n \ge 1
- \end{cases}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·two-headed-reverse_step-count">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·two-headed-reverse_step-count"></RT·counter·snapshot>
+ <RT·math>
+ \text{steps} =
+ \begin{cases}
+ 4 & \text{if } n = 0 \\
+ 9n + 4 & \text{if } n \ge 1
+ \end{cases}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·two-headed-reverse_step-count"></RT·counter·read> <RT·name>Steps taken by the two headed TTCA reverse machine</RT·name>
+ </RT·counter·step>
<p>The two paths through the state machine, and the one loop, translate well into code:</p>
- <RT·code>
- void TTCA·reverse_string_2_head() {
- // Phase 1: Both heads scan right to the EOM pivot
- read('s' ,0);
- while(s != EOM){right(0); right(1); read('s' ,0);}
+ <RT·counter·step counter="RT·Code·counter" id="Code·two-headed-reverse_in_C">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·two-headed-reverse_in_C"></RT·counter·snapshot>
+ <RT·code>
+ void TTCA·reverse_string_2_head() {
+ // Phase 1: Both heads scan right to the EOM pivot
+ read('s' ,0);
+ while(s != EOM){right(0); right(1); read('s' ,0);}
+
+ // Phase 2: Setup pointers or short-circuit on empty string
+ status(0);
+ if(s == leftmost){
+ right(1);
+ write('σ' ,1 ,EOR);
+ return;
+ }
- // Phase 2: Setup pointers or short-circuit on empty string
- status(0);
- if(s == leftmost){
right(1);
- write('σ' ,1 ,EOR);
- return;
- }
+ left(0);
- right(1);
- left(0);
+ // Phase 3: The Linear Copy Loop
+ while(true){
+ read('d' ,0);
+ status(0);
- // Phase 3: The Linear Copy Loop
- while(true){
- read('d' ,0);
- status(0);
+ // Break out to process the final character
+ if(s == leftmost) break;
- // Break out to process the final character
- if(s == leftmost) break;
+ write('σ' ,0 ,SP);
+ write('d' ,1);
+ right(1);
+ left(0);
+ }
+ // Phase 4: Final character, advance, and clean halt
write('σ' ,0 ,SP);
write('d' ,1);
right(1);
- left(0);
- }
-
- // Phase 4: Final character, advance, and clean halt
- write('σ' ,0 ,SP);
- write('d' ,1);
- right(1);
- write('σ' ,1 ,EOR);
+ write('σ' ,1 ,EOR);
- return;
- }
- </RT·code>
+ return;
+ }
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·two-headed-reverse_in_C"></RT·counter·read>. <RT·name>The two headed reverse controller written as C</RT·name>
+ </RT·counter·step>
<p>This machine has a single tape with two heads marking two separate context areas. Because the areas do not overlap, this situation is indistinguishable from the case of the machine having two separate tapes, each with its own head. Hartmanis and Stearns established the original proof that simulating a Turing Machine with multiple tapes, each with its own head, on a single-tape, single-head machine incurs a quadratic time penalty <RT·endnote>J. Hartmanis and R. E. Stearns, "On the computational complexity of algorithms," <em>Transactions of the American Mathematical Society</em> 117 (1965): 285-306.</RT·endnote>. Hopcroft and Ullman formalize this relationship in their text <RT·endnote>John E. Hopcroft and Jeffrey D. Ullman, <em>Introduction to Automata Theory, Languages, and Computation</em> (Reading: Addison Wesley, 1979), 292.</RT·endnote>. This explains why in this example of a string reverse machine, when the second head was added to eliminate the head shuttling, the quadratic term disappeared. Not all quadratic terms in step count formulas are due to shuttling, but this one happens to be such a case.</p>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section>
+ <RT·section id="Section·TTCA_machine-design">
<RT·name>The TTCA Machine design</RT·name>
- <img src="machine fig.png" class="RT·diagram" alt="Figure 1: A Turing Machine">
- <!--<figcaption>Figure 1: A Turing Machine</figcaption>-->
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·Turing-Machine">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·Turing-Machine"></RT·counter·snapshot>
+ <!-- first edition: Figure 1 -->
+ <figure>
+ <img src="machine fig.png" class="RT·diagram" alt="Figure 1: A Turing Machine">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·Turing-Machine"></RT·counter·read>. <RT·name>A Turing Machine</RT·name>
+ </RT·counter·step>
- <p>The prior chapter on the computation theoretic TTCA machine serves as the architectural template, with only a few modifications. The architecture requires explicit data rather than accepting meta-symbols like 'unspecified' as presumed initial values 'by definition'. Actual values are transacted. Now that data and control have been separated, the controller is practical to implement, and even more so because it was defined in terms of tables that can be built in hardware. As the read status instruction returns the cell type, it will in its current form be able to return 'rightmost', so the right end of the tape can be detected. In order to extend the tape, the machine will stop and ask the operator to mount a new reel. This could be signaled when the user attempts to step right of rightmost, either by a panel light that illuminates upon the machine finding a rightmost status, or by the program printing a message on the console teletype. As this is a constant-time operation, it is computation theoretic inconsequential.</p>
+ <p>The prior chapter on the computation theoretic TTCA machine, chapter <RT·counter·read snapshot="Section·TTCA_computation-theoretic"></RT·counter·read>, serves as the architectural template, with only a few modifications. The architecture requires explicit data rather than accepting meta-symbols like 'unspecified' as presumed initial values 'by definition'. Actual values are transacted. Now that data and control have been separated, the controller is practical to implement, and even more so because it was defined in terms of tables that can be built in hardware. As the read status instruction returns the cell type, it will in its current form be able to return 'rightmost', so the right end of the tape can be detected. In order to extend the tape, the machine will stop and ask the operator to mount a new reel. This could be signaled when the user attempts to step right of rightmost, either by a panel light that illuminates upon the machine finding a rightmost status, or by the program printing a message on the console teletype. As this is a constant-time operation, it is computation theoretic inconsequential.</p>
- <p>Because a Turing Machine can only reach another cell further out on the tape by stepping to it, space complexity and time complexity are related. A program that runs for ten steps can consume at most ten cells of tape. However, if that program merely bounces between two cells, it will require less space, precisely two cells. As another example, a program that counts the number of characters on its input tape using Hindu-Arabic notation will execute in asymptotically linear time, as demonstrated later in the section analyzing the increment operation. Its working footprint, however, will be logarithmic in space complexity, because that is how fast an Hindu-Arabic representation grows with a count.</p>
+ <p>Because a Turing Machine can only reach another cell further out on the tape by stepping to it, space complexity and time complexity are related. A program that runs for ten steps can consume at most ten cells of tape. However, if that program merely bounces between two cells, it will require less space, precisely two cells. As another example, a program that counts the number of characters on its input tape using Hindu-Arabic notation will execute in asymptotically linear time, as demonstrated in section <RT·counter·read snapshot="Section·Hindu-Arabic_representation"></RT·counter·read>, which analyses the increment operation. Its working footprint, however, will be logarithmic in space complexity, because that is how fast an Hindu-Arabic representation grows with a count.</p>
<p>If a program executed at the speed of a human operator, the operator would likely abandon the process before it finished. This highlights a necessary attribute of good software: <RT·term>utility</RT·term>. It also exposes a limitation of pure computation theory, which abstracts away physical time. Nevertheless, formal analysis remains a necessity. Consider an exponential-time program processing worst-case operands: its execution time explodes relative to input length, rapidly exceeding the age of the universe. In such extremes, empirical wall-clock measurement becomes superfluous. Computation theory classifies a program's behavior, which establishes structural implications for wall-clock time, rather than calculating absolute durations.</p>
<p>An <RT·code>HU</RT·code> contains a head and a local controller. The local controller supports these instructions:</p>
- <ol>
- <li><RT·code>read()</RT·code> → σ</li>
- <li><RT·code>write(σ)</RT·code></li>
- <li><RT·code>status()</RT·code> → s</li>
- </ol>
-
- <p>On this model of machine, the <RT·code>HU</RT·code> status is identical to the indicated cell's type. The cell type is not read from the tape; rather, it is derived from the head's physical relationship to the ends of the tape. With a real tape drive, an unused leader and trailer are required to prevent the tape from departing from the reels, a condition difficult to reverse. Therefore, the format, or physical, markers will be on the ends of the usable portion of the tape, rather than on the physical end of the tape. Consequently, the <RT·code>HU</RT·code> works in conjunction with the <RT·code>TTU</RT·code> to derive the status. (The tape transport unit, the <RT·code>TTU</RT·code>, is discussed in the next section.) As established in the section discussing cells, cell types are:</p>
-
- <ol>
- <li><RT·code>leftmost</RT·code></li>
- <li><RT·code>rightmost</RT·code></li>
- <li><RT·code>medial</RT·code></li>
- <li><RT·code>island</RT·code></li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·HU_instructions">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·HU_instructions"></RT·counter·snapshot>
+ <ol>
+ <li><RT·code>read()</RT·code> → σ</li>
+ <li><RT·code>write(σ)</RT·code></li>
+ <li><RT·code>status()</RT·code> → s</li>
+ </ol>
+ List <RT·counter·read snapshot="List·HU_instructions"></RT·counter·read>. <RT·name>The instructions supported by the head unit controller</RT·name>
+ </RT·counter·step>
+
+ <p>On this model of machine, the <RT·code>HU</RT·code> status is identical to the indicated cell's type. The cell type is not read from the tape; rather, it is derived from the head's physical relationship to the ends of the tape. With a real tape drive, an unused leader and trailer are required to prevent the tape from departing from the reels, a condition difficult to reverse. Therefore, the format, or physical, markers will be on the ends of the usable portion of the tape, rather than on the physical end of the tape. Consequently, the <RT·code>HU</RT·code> works in conjunction with the <RT·code>TTU</RT·code> to derive the status. (The tape transport unit, the <RT·code>TTU</RT·code>, is discussed in the next section, section <RT·counter·read snapshot="Section·TTU"></RT·counter·read>.) As established in section <RT·counter·read snapshot="Section·tape-cell"></RT·counter·read>, cell types are:</p>
+
+ <RT·counter·step counter="RT·List·counter" id="List·cell_types">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·cell_types"></RT·counter·snapshot>
+ <ol>
+ <li><RT·code>leftmost</RT·code></li>
+ <li><RT·code>rightmost</RT·code></li>
+ <li><RT·code>medial</RT·code></li>
+ <li><RT·code>island</RT·code></li>
+ </ol>
+ List <RT·counter·read snapshot="List·cell_types"></RT·counter·read>. <RT·name>The cell types a head unit can report</RT·name>
+ </RT·counter·step>
<p>A computation theoretic Turing Machine would never encounter a status of <RT·code>rightmost</RT·code> or <RT·code>island</RT·code>. This is where a finite extendable tape structurally differs from a single-ended theoretical tape.</p>
</RT·section>
- <RT·section>
+ <RT·section id="Section·TTU">
<RT·name>Tape transport unit, <RT·code>TTU</RT·code></RT·name>
<p>The <RT·code>TTU</RT·code> is the component where tapes are mounted and unmounted, and where read/write head units are installed. When multiple <RT·code>HU</RT·code>s are plugged in, the controller passes control among them so it appears that heads never collide. The <RT·code>TTU</RT·code> controller has these components:
</p>
- <ol>
- <li>one or more <RT·code>HU</RT·code>s</li>
- <li>a <RT·term>data buffer</RT·term> holding a single symbol</li>
- <li>a <RT·term>status buffer</RT·term> </li>
- <li>a <RT·term>instruction buffer</RT·term>, written by the programmed controller, acted upon immediately by the <RT·code>TTU</RT·code></li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·TTU_components">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·TTU_components"></RT·counter·snapshot>
+ <ol>
+ <li>one or more <RT·code>HU</RT·code>s</li>
+ <li>a <RT·term>data buffer</RT·term> holding a single symbol</li>
+ <li>a <RT·term>status buffer</RT·term> </li>
+ <li>a <RT·term>instruction buffer</RT·term>, written by the programmed controller, acted upon immediately by the <RT·code>TTU</RT·code></li>
+ </ol>
+ List <RT·counter·read snapshot="List·TTU_components"></RT·counter·read>. <RT·name>The components of the tape transport unit controller</RT·name>
+ </RT·counter·step>
<p>The <RT·code>TTU</RT·code> interfaces with the executor, which in turn gates the flow of data through the machine. The executor controls the clock and reset lines, and through this supervises the <em>customer programmed control unit</em>, the <RT·code>CPCU</RT·code>. This two-layer control system is single-threaded and issues the following instructions to each selected <RT·code>TTU</RT·code>:</p>
- <ol>
- <li><RT·code>read(<em>head</em>)</RT·code> → σ</li>
- <li><RT·code>write(<em>σ</em> ,<em>head</em>)</RT·code></li>
- <li><RT·code>status(<em>head</em>)</RT·code> → γ</li>
- <li><RT·code>left(<em>head</em>)</RT·code></li>
- <li><RT·code>right(<em>head</em>)</RT·code></li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·TTU_instructions">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·TTU_instructions"></RT·counter·snapshot>
+ <ol>
+ <li><RT·code>read(<em>head</em>)</RT·code> → σ</li>
+ <li><RT·code>write(<em>σ</em> ,<em>head</em>)</RT·code></li>
+ <li><RT·code>status(<em>head</em>)</RT·code> → γ</li>
+ <li><RT·code>left(<em>head</em>)</RT·code></li>
+ <li><RT·code>right(<em>head</em>)</RT·code></li>
+ </ol>
+ List <RT·counter·read snapshot="List·TTU_instructions"></RT·counter·read>. <RT·name>The instructions issued to a selected tape transport unit</RT·name>
+ </RT·counter·step>
<p>The <em>head</em> argument multiplexes the instruction to the specified head. If the <RT·code>TTU</RT·code> has one head, the head argument is optional. The last two instructions cause the tape to be moved such that, relatively, the selected head moves left or right by one cell.</p>
<p>The controller is programmed via patch panels. The panels would look something like what is shown in the following ASCII art blocks. Note that <RT·code>●</RT·code> indicates an illuminated indicator light, whereas <RT·code>○</RT·code> is not illuminated. <RT·code>[/]</RT·code> represents an open toggle switch, while <RT·code>[—]</RT·code> is a closed one. <RT·code>{*}</RT·code> is a pushed button, while <RT·code>{ }</RT·code> is a button that is not pushed. <RT·code>( )</RT·code> represents a hole for a banana plug. Each patch cord has a banana plug on each end. Plugging a patch cord between separate panels will void the warranty ;-).</p>
- <RT·code>
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·control-panel">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·control-panel"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <pre>
[ CONTROL PANEL ]
+-----------------------------------+
| POWER [—] ● ERROR ○ RESET { } |
+-----------------------------------+
| RUN/STEP [/] ○ STEP { } |
+-----------------------------------+
- </RT·code>
-
- <RT·code>
+ </pre>
+ Figure <RT·counter·read snapshot="Figure·control-panel"></RT·counter·read>. <RT·name>The control panel, carrying power, error, reset and single step</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·state-transition-table_panel">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·state-transition-table_panel"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <pre>
[ State Transition Table ]
+-------------------------------------------+
current state | def q0 q1 q2 q3 q4 q5 |
| |
destination state | ( ) ( ) ( ) ( ) ( ) ( ) |
+-------------------------------------------+
- </RT·code>
-
- <RT·code>
+ </pre>
+ Figure <RT·counter·read snapshot="Figure·state-transition-table_panel"></RT·counter·read>. <RT·name>The state transition panel, with state indicators and halt switches</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·instruction_panel">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·instruction_panel"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <pre>
[ Instruction ]
+-----------------------------------+
| q0 q1 q2 q3 q4 q5 |
write('d')| ( ) ( ) ( ) ( ) ( ) ( ) |
write('σ')| ( ) ( ) ( ) ( ) ( ) ( ) |
+-----------------------------------+
- </RT·code>
-
- <RT·code>
+ </pre>
+ Figure <RT·counter·read snapshot="Figure·instruction_panel"></RT·counter·read>. <RT·name>The instruction panel, one patch row per instruction and one column per state</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·sigma-select_panel">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·sigma-select_panel"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <pre>
[ Sigma Select for write('σ') ]
+-----------------------------------+
| q0 q1 q2 q3 q4 q5 |
s3 | ( ) ( ) ( ) ( ) ( ) ( ) |
s4 | ( ) ( ) ( ) ( ) ( ) ( ) |
+-----------------------------------+
- </RT·code>
+ </pre>
+ Figure <RT·counter·read snapshot="Figure·sigma-select_panel"></RT·counter·read>. <RT·name>The sigma select panel, choosing the symbol written by write(σ)</RT·name>
+ </RT·counter·step>
<p>The top panel has two toggle switches. One turns the machine on, and the other selects run or single-step mode. Immediately to the right of the two toggles are indicator lights. To the right of the indicator lights are two push buttons. One is for reset, which sends the machine back to state <RT·math>q_0</RT·math>, and the other is for stepping the machine when it is in single-step mode. This panel also has an error indicator light which will illuminate if no next state is specified for a state transition, and thus the machine is hung, or if a head walks off the end of a tape.</p>
<RT·section>
<RT·name>The machine block diagram</RT·name>
- <figure>
- <img src="TTCA_machine.svg" class="RT·diagram" alt="Figure: TTCA block diagram">
- <figcaption>Figure: TTCA block diagram</figcaption>
- </figure>
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·TTCA_block-diagram">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·TTCA_block-diagram"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="TTCA_machine.svg" class="RT·diagram" alt="Figure: TTCA block diagram">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·TTCA_block-diagram"></RT·counter·read>. <RT·name>The TTCA Machine block diagram</RT·name>
+ </RT·counter·step>
- <p>This section describes the TTCA machine organization. The diagram above shows the major components and their channels of communications. The organization guides designers who will later draft schematics that specify all of the connections.</p>
+ <p>This section describes the TTCA machine organization. Figure <RT·counter·read snapshot="Figure·TTCA_block-diagram"></RT·counter·read> shows the major components and their channels of communications. The organization guides designers who will later draft schematics that specify all of the connections.</p>
<p><strong>Components</strong></p>
- <ol>
- <li>Control Panel
- <ol>
- <li>Power Switch, Single Step Switch, Reset Button, Single Step Button</li>
- <li>patch cord matrices</li>
- </ol>
- </li>
- <li>Executor
- <ol>
- <li>mode control
- <ol>
- <li>power</li>
- <li>run/step</li>
- </ol>
- </li>
- <li>staging
- <ol>
- <li>reset button</li>
- <li>reset logic and distribution lines</li>
- <li><RT·code>Halt Switch Bank</RT·code></li>
- </ol>
- </li>
- <li>Clock logic and distribution lines (<RT·code>clk</RT·code>)</li>
- <li>Single Step Switch single shot logic</li>
- </ol>
- </li>
- <li><RT·code>CPCU</RT·code> (Customer Programmed Control Unit)
- <ol>
- <li>One-hot <RT·code>q</RT·code> register</li>
- <li><RT·code>Next State Table</RT·code></li>
- <li><RT·code>Instruction Table</RT·code></li>
- </ol>
- </li>
- <li>Data bus</li>
- <li><RT·code>d</RT·code> register</li>
- <li><RT·code>s</RT·code> register</li>
- <li><RT·code>Status Decoder</RT·code></li>
- </ol>
-
- <p>As described in the computation theoretic section that is being used as the architectural template, the executor guides the machine through the initialization, programmed control, and halting stages of execution. The Executor contains the power, reset, and clock logic. It has two modes of execution: the run mode in which the clock runs free, and the single-step mode, in which clock pulses are sent with the push of a button. It also holds the halt state switch bank, and is ready to stop the clock when a halt state is reached. When in the programmed control stage, most of the active control comes from the <RT·code>CPCU</RT·code>.</p>
+ <RT·counter·step counter="RT·List·counter" id="List·block-diagram_components">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·block-diagram_components"></RT·counter·snapshot>
+ <ol>
+ <li>Control Panel
+ <ol>
+ <li>Power Switch, Single Step Switch, Reset Button, Single Step Button</li>
+ <li>patch cord matrices</li>
+ </ol>
+ </li>
+ <li>Executor
+ <ol>
+ <li>mode control
+ <ol>
+ <li>power</li>
+ <li>run/step</li>
+ </ol>
+ </li>
+ <li>staging
+ <ol>
+ <li>reset button</li>
+ <li>reset logic and distribution lines</li>
+ <li><RT·code>Halt Switch Bank</RT·code></li>
+ </ol>
+ </li>
+ <li>Clock logic and distribution lines (<RT·code>clk</RT·code>)</li>
+ <li>Single Step Switch single shot logic</li>
+ </ol>
+ </li>
+ <li><RT·code>CPCU</RT·code> (Customer Programmed Control Unit)
+ <ol>
+ <li>One-hot <RT·code>q</RT·code> register</li>
+ <li><RT·code>Next State Table</RT·code></li>
+ <li><RT·code>Instruction Table</RT·code></li>
+ </ol>
+ </li>
+ <li>Data bus</li>
+ <li><RT·code>d</RT·code> register</li>
+ <li><RT·code>s</RT·code> register</li>
+ <li><RT·code>Status Decoder</RT·code></li>
+ </ol>
+ List <RT·counter·read snapshot="List·block-diagram_components"></RT·counter·read>. <RT·name>The units and panels the machine is assembled from</RT·name>
+ </RT·counter·step>
+
+ <p>As described in chapter <RT·counter·read snapshot="Section·TTCA_computation-theoretic"></RT·counter·read>, which is being used as the architectural template, the executor guides the machine through the initialization, programmed control, and halting stages of execution. The Executor contains the power, reset, and clock logic. It has two modes of execution: the run mode in which the clock runs free, and the single-step mode, in which clock pulses are sent with the push of a button. It also holds the halt state switch bank, and is ready to stop the clock when a halt state is reached. When in the programmed control stage, most of the active control comes from the <RT·code>CPCU</RT·code>.</p>
<p>The <RT·code>CPCU</RT·code> contains the current state register <RT·code>q</RT·code>, the <RT·code>Next State Table</RT·code>, and the <RT·code>Instruction Table</RT·code>.</p>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section>
+ <RT·section id="Section·area-and-partitioning">
<RT·name>Area and partitioning</RT·name>
<p>
<RT·section>
<RT·name>Head partition</RT·name>
- <ol>
- <li>The left side: The finite set containing all of the cells to the left of the head cell.</li>
- <li>Head: the head cell.</li>
- <li>The right side: the infinite set containing all the cells to the right of the head.</li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·head_partition">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·head_partition"></RT·counter·snapshot>
+ <ol>
+ <li>The left side: The finite set containing all of the cells to the left of the head cell.</li>
+ <li>Head: the head cell.</li>
+ <li>The right side: the infinite set containing all the cells to the right of the head.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·head_partition"></RT·counter·read>. <RT·name>The three areas of the head partition</RT·name>
+ </RT·counter·step>
<p>If the head is on the leftmost cell, there is no left side area.</p>
<RT·section>
<RT·name>Leftmost/remaining partition</RT·name>
- <ol>
- <li>Leftmost: the leftmost cell.</li>
- <li>Remaining: the infinite set including the right neighbor of the leftmost cell, and all cells further to the right.</li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·leftmost-remaining_partition">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·leftmost-remaining_partition"></RT·counter·snapshot>
+ <ol>
+ <li>Leftmost: the leftmost cell.</li>
+ <li>Remaining: the infinite set including the right neighbor of the leftmost cell, and all cells further to the right.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·leftmost-remaining_partition"></RT·counter·read>. <RT·name>The two areas of the leftmost and remaining partition</RT·name>
+ </RT·counter·step>
</RT·section>
A nonempty tape, one with at least one cell holding an alphabet symbol, can be partitioned into the following areas:
</p>
- <ol>
- <li>The left empty tail: if the leftmost cell of the tape is an alphabet cell, there is no left empty tail. Otherwise, it consists of the leftmost cell and the empty cells, if any, to the right of the leftmost cell, up to, but not including, the first alphabet cell.</li>
+ <RT·counter·step counter="RT·List·counter" id="List·active-area_partition">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·active-area_partition"></RT·counter·snapshot>
+ <ol>
+ <li>The left empty tail: if the leftmost cell of the tape is an alphabet cell, there is no left empty tail. Otherwise, it consists of the leftmost cell and the empty cells, if any, to the right of the leftmost cell, up to, but not including, the first alphabet cell.</li>
- <li>Active area: a finite area for computational problems, containing the cells extending from the leftmost alphabet cell up to and including the rightmost alphabet cell. It is possible that the leftmost alphabet cell and the rightmost alphabet cell will be the same cell.</li>
+ <li>Active area: a finite area for computational problems, containing the cells extending from the leftmost alphabet cell up to and including the rightmost alphabet cell. It is possible that the leftmost alphabet cell and the rightmost alphabet cell will be the same cell.</li>
- <li>The right empty tail: the infinite set extending from the right neighbor of the rightmost cell of the active area, extending rightward.</li>
- </ol>
+ <li>The right empty tail: the infinite set extending from the right neighbor of the rightmost cell of the active area, extending rightward.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·active-area_partition"></RT·counter·read>. <RT·name>The three areas of the active area partition</RT·name>
+ </RT·counter·step>
<p>
A noncomputational tape is one that cannot be initialized by a Turing Machine, but can still be surmised to exist, perhaps in analysis due to its properties. The empty tape is an example. The tape holding the Natural Numbers is another example. For noncomputational tapes that have the property that the active area is open on the right, there is no right empty tail.
When a Turing Machine operates on a finite virtual tape, the structural logic of the partitions established earlier must be updated to reflect the absolute rightward boundary.
</p>
- <ol>
- <li>For the <strong>Head partition</strong> and <strong>Area implied partition</strong>, the right side is no longer infinite. It is a finite set containing all cells extending from the right neighbor of the head (or area) up to the absolute rightmost cell of the virtual tape. If the head (or area) includes the rightmost cell of the virtual tape, the right side set does not exist.</li>
- <li>For the <strong>Leftmost/remaining partition</strong>, the remaining area is now a finite set terminating at the rightmost cell of the virtual tape.</li>
- <li>For the <strong>Active area partition</strong>, the right empty tail is similarly a finite set extending to the rightmost boundary of the virtual tape. If the rightmost alphabet cell occupies the rightmost cell of the virtual tape, the right empty tail does not exist.</li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·finite-virtual-tape_partitions">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·finite-virtual-tape_partitions"></RT·counter·snapshot>
+ <ol>
+ <li>For the <strong>Head partition</strong> and <strong>Area implied partition</strong>, the right side is no longer infinite. It is a finite set containing all cells extending from the right neighbor of the head (or area) up to the absolute rightmost cell of the virtual tape. If the head (or area) includes the rightmost cell of the virtual tape, the right side set does not exist.</li>
+ <li>For the <strong>Leftmost/remaining partition</strong>, the remaining area is now a finite set terminating at the rightmost cell of the virtual tape.</li>
+ <li>For the <strong>Active area partition</strong>, the right empty tail is similarly a finite set extending to the rightmost boundary of the virtual tape. If the rightmost alphabet cell occupies the rightmost cell of the virtual tape, the right empty tail does not exist.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·finite-virtual-tape_partitions"></RT·counter·read>. <RT·name>The partitions of a finite virtual tape</RT·name>
+ </RT·counter·step>
</RT·section>
</RT·section>
So we now have two means for identifying a feature. One means is to state its address, and the other is to put a tape machine head on it.
</p>
- <p>As we noted in the section discussing area, an area has two distinguishing features, being that it has a leftmost cell, and a rightmost cell. That definition is topological. If we start with the leftmost cell of a tape, we are either already on the leftmost cell of a defined area, or we can step right to find it. At the point of finding it we know this leftmost cell is part of the area, then we are either already on the rightmost cell, or we can continue to step right on cells in the area until we find the rightmost cell in the area. The right neighbor of the rightmost cell in the area, and all cells to that right of that, are excluded from the area.
+ <p>As we noted in section <RT·counter·read snapshot="Section·area-and-partitioning"></RT·counter·read>, an area has two distinguishing features, being that it has a leftmost cell, and a rightmost cell. That definition is topological. If we start with the leftmost cell of a tape, we are either already on the leftmost cell of a defined area, or we can step right to find it. At the point of finding it we know this leftmost cell is part of the area, then we are either already on the rightmost cell, or we can continue to step right on cells in the area until we find the rightmost cell in the area. The right neighbor of the rightmost cell in the area, and all cells to that right of that, are excluded from the area.
</p>
<p>With addresses we can now define an area with two addresses, two natural numbers, the address of the leftmost cell, and that of the rightmost cell. All natural numbers greater than or equal to the address of the leftmost cell, or less than or equal to the address of the rightmost cell, are addresses of cells that are in the area. This feels more satisfactory for most of us, as now we are talking about arithmetic rather than graph topology. Though should the topology of the tape be generalized, this could become limiting. It reminds me of Frege's admonition that perhaps math should be built on top of geometry.
<RT·section>
<RT·name>How cardinality is computed</RT·name>
- <ol>
- <li>We set Turing Machine <RT·math>P</RT·math> with its head on the leftmost cell of an area. We mount the initial tape, '·', on the <RT·math>A</RT·math> machine.</li>
- <li>We step <RT·math>P</RT·math> and simultaneously run the <RT·math>A</RT·math> machine. Stepping stops when <RT·math>P</RT·math> reaches the rightmost cell of the area. At this point, the tape on the <RT·math>A</RT·math> machine holds the address space extent.</li>
- <li>The <RT·math>A</RT·math> machine is run an additional time. The output on the tape is defined to be the cardinality of the address space, aka the cardinality.</li>
- </ol>
+ <RT·counter·step counter="RT·List·counter" id="List·cardinality_procedure">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·cardinality_procedure"></RT·counter·snapshot>
+ <ol>
+ <li>We set Turing Machine <RT·math>P</RT·math> with its head on the leftmost cell of an area. We mount the initial tape, '·', on the <RT·math>A</RT·math> machine.</li>
+ <li>We step <RT·math>P</RT·math> and simultaneously run the <RT·math>A</RT·math> machine. Stepping stops when <RT·math>P</RT·math> reaches the rightmost cell of the area. At this point, the tape on the <RT·math>A</RT·math> machine holds the address space extent.</li>
+ <li>The <RT·math>A</RT·math> machine is run an additional time. The output on the tape is defined to be the cardinality of the address space, aka the cardinality.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·cardinality_procedure"></RT·counter·read>. <RT·name>The three steps for computing the cardinality of an address space</RT·name>
+ </RT·counter·step>
</RT·section>
Now here is an interesting result:
</p>
- <RT·math>
- \aleph_{0} - \aleph_{-1} = 1
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·aleph_difference">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·aleph_difference"></RT·counter·snapshot>
+ <RT·math>
+ \aleph_{0} - \aleph_{-1} = 1
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·aleph_difference"></RT·counter·read> <RT·name>The difference of two transfinite cardinals is one</RT·name>
+ </RT·counter·step>
<p>
Neither machine can be run. However we can compose the two machines, then simplify the composition. When we do so, the ever larger Natural Number machines annihilate each other, and the increment machine remains. The increment machine can be run, so we end up with an output value.
</RT·section>
- <RT·section>
+ <RT·section id="Section·Hindu-Arabic_representation">
<RT·name>Hindu-Arabic representation</RT·name>
<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>
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>
+ <RT·counter·step counter="RT·Code·counter" id="Code·increment_controller">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·increment_controller"></RT·counter·snapshot>
+ <RT·code>
+ increment:
+ a = TTU.read()
+ if a == 0 or a == □:
+ TTU.write(1)
+ halt
+ TTU.write(0)
+ TTU.step()
+ goto increment
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·increment_controller"></RT·counter·read>. <RT·name>A controller that increments a binary counter</RT·name>
+ </RT·counter·step>
<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>
+ 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. Table <RT·counter·read snapshot="Table·increment_cost"></RT·counter·read> lists 7 increments, which is sufficient to reach the maximum count that can be held by a 3 bit counter.
+ </p>
+
+ <RT·counter·step counter="RT·Table·counter" id="Table·increment_cost">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·increment_cost"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <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>
+ Table <RT·counter·read snapshot="Table·increment_cost"></RT·counter·read>. <RT·name>The cost in steps of each increment, through the range of a three bit counter</RT·name>
+ </RT·counter·step>
<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>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>
+ <RT·counter·step counter="RT·List·counter" id="List·zero_representation_options">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·zero_representation_options"></RT·counter·snapshot>
+ <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>
+ List <RT·counter·read snapshot="List·zero_representation_options"></RT·counter·read>. <RT·name>The two options for representing zero</RT·name>
+ </RT·counter·step>
<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>
<p>In the architectural terminology utilized here, viewing memory as a horizontal tape with bytes in the cells and addresses increasing while moving to the right, little-endian numbers have the least-significant digit on the left, and big-endian numbers have the least significant digit on the right of an allocation. Stated structurally, little-endian numbers are zero padded on the right, and big-endian numbers are zero padded on the left.</p>
- <p>Figure 10 depicts a word featuring byte addresses represented in hexadecimal, running from c0 to c3. (In decimal these addresses represent 192, 193, 194, 195). The address of the byte before c0 is bf. The address after c3 is c4. The address for the word itself evaluates to c0, as it is the minimum byte address. This word holds a little-endian number. Treating a byte as an octet digit, the binary encoding for the least-significant digit of this number is 0001 1000. The most-significant digit is 1010 1110.</p>
+ <p>Figure <RT·counter·read snapshot="Figure·little-endian_digit-order"></RT·counter·read> depicts a word featuring byte addresses represented in hexadecimal, running from c0 to c3. (In decimal these addresses represent 192, 193, 194, 195). The address of the byte before c0 is bf. The address after c3 is c4. The address for the word itself evaluates to c0, as it is the minimum byte address. This word holds a little-endian number. Treating a byte as an octet digit, the binary encoding for the least-significant digit of this number is 0001 1000. The most-significant digit is 1010 1110.</p>
- <figure>
- <img src="Hindu-Arabic number fig 1.png" class="RT·diagram" alt="Figure 10: Left justified, least-significant-digit-first">
- <figcaption>Figure 10: Left justified, least-significant-digit-first</figcaption>
- </figure>
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·little-endian_digit-order">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·little-endian_digit-order"></RT·counter·snapshot>
+ <!-- first edition: Figure 10 -->
+ <figure>
+ <img src="Hindu-Arabic number fig 1.png" class="RT·diagram" alt="Figure 10: Left justified, least-significant-digit-first">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·little-endian_digit-order"></RT·counter·read>. <RT·name>A left justified word holding a number least-significant-digit-first</RT·name>
+ </RT·counter·step>
- <p>In Figure 11, the same number populates the word using big-endian architecture. For all but very large numbers, the digit pointed at by the allocation pointer evaluates to zero. A system continues to scan zeros until reaching either the end of the allocation or the most-significant digit. If it reaches the end of the allocation, the contained number evaluates to zero. Because this is the exact same number shown in the prior figure, it retains the identical least-significant digit and most-significant digit.</p>
+ <p>In Figure <RT·counter·read snapshot="Figure·big-endian_digit-order"></RT·counter·read>, the same number populates the word using big-endian architecture. For all but very large numbers, the digit pointed at by the allocation pointer evaluates to zero. A system continues to scan zeros until reaching either the end of the allocation or the most-significant digit. If it reaches the end of the allocation, the contained number evaluates to zero. Because this is the exact same number shown in Figure <RT·counter·read snapshot="Figure·little-endian_digit-order"></RT·counter·read>, it retains the identical least-significant digit and most-significant digit.</p>
- <figure>
- <img src="Hindu-Arabic number fig 2.png" class="RT·diagram" alt="Figure 11: Same number using big-endian digit order">
- <figcaption>Figure 11: Same number using big-endian digit order</figcaption>
- </figure>
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·big-endian_digit-order">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·big-endian_digit-order"></RT·counter·snapshot>
+ <!-- first edition: Figure 11 -->
+ <figure>
+ <img src="Hindu-Arabic number fig 2.png" class="RT·diagram" alt="Figure 11: Same number using big-endian digit order">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·big-endian_digit-order"></RT·counter·read>. <RT·name>The same number held in big-endian digit order</RT·name>
+ </RT·counter·step>
<p>If the specified word holds a count, the counting mechanics differ. When counting with the little-endian convention, a number grows into larger addresses as the count carries into new digits. In contrast, with big-endian architecture, counting carries into strictly smaller memory addresses.</p>
<p>Our Indian Number derived representations consist of sequences of digits. Words of allocation consist of consecutively addressed bytes. Hardware manages bytes atomically. Any bit encoding for the digits of a number must pack cleanly into bytes, otherwise the digits fracture. Achieving a clean packing requires padding the data with zeros to force alignment to an 8-bit boundary. When a system meets this criterion, treating a number as a sequence of bytes acting as digits maintains structural consistency. Due to this constraint, little-endian and big-endian are routinely classified as byte orders.</p>
- <p>The following figure displays a stream of bytes arriving as data and being copied into a word. The digits of the word (the bytes) arrive in little-endian order and target a little-endian machine, so they are written in the exact order they are scanned off the channel.</p>
+ <p>Figure <RT·counter·read snapshot="Figure·in-address-order_byte-copy"></RT·counter·read> displays a stream of bytes arriving as data and being copied into a word. The digits of the word (the bytes) arrive in little-endian order and target a little-endian machine, so they are written in the exact order they are scanned off the channel.</p>
- <figure>
- <img src="Hindu-Arabic number fig 3.png" class="RT·diagram" alt="Figure 12: In-address-order byte by byte copy">
- <figcaption>Figure 12: In-address-order byte by byte copy</figcaption>
- </figure>
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·in-address-order_byte-copy">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·in-address-order_byte-copy"></RT·counter·snapshot>
+ <!-- first edition: Figure 12 -->
+ <figure>
+ <img src="Hindu-Arabic number fig 3.png" class="RT·diagram" alt="Figure 12: In-address-order byte by byte copy">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·in-address-order_byte-copy"></RT·counter·read>. <RT·name>A byte by byte copy performed in address order</RT·name>
+ </RT·counter·step>
<p>In the second case, the identical data stream arrives with words serialized as bytes in little-endian order, but the receiving machine is big-endian. The system must reverse the bytes strictly on a word-by-word basis.</p>
- <figure>
- <img src="Hindu-Arabic number fig 4.png" class="RT·diagram" alt="Figure 13: Reverse order byte copy for words">
- <figcaption>Figure 13: Reverse order byte copy for words</figcaption>
- </figure>
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·reverse-order_byte-copy">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·reverse-order_byte-copy"></RT·counter·snapshot>
+ <!-- first edition: Figure 13 -->
+ <figure>
+ <img src="Hindu-Arabic number fig 4.png" class="RT·diagram" alt="Figure 13: Reverse order byte copy for words">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·reverse-order_byte-copy"></RT·counter·read>. <RT·name>A reverse order byte copy performed word by word</RT·name>
+ </RT·counter·step>
<p>When the data arrives, there is no way to know where the word boundaries are. Serialization destroys that structural boundary information. Without knowing where the words are, a system cannot determine when to perform the byte order reversal. Therefore, resolving this requires a different approach than the one used for bit order in bytes; the problem transfers into the software layer.</p>
</p>
<p>
- Let us put this into perspective. Suppose in ancient Roman times that a clock tick for a computer was scaled to be one day long, so that the action involves sending letters rather than variable values. Under this scale, a single nanosecond of real world execution time equates to three days. Suppose a program initiated a read request for a location in memory on the Ides of March, the date when Caesar was assassinated on -0043-03-15. Surely that was a big day for posting letters. The following table provides the historical date that the variable value would finally be loaded into the processor, depending on the memory tier being accessed:
- </p>
-
- <table>
- <thead>
- <tr>
- <th>Memory Tier</th>
- <th>Real World Latency</th>
- <th>Scaled Delay</th>
- <th>Scaled Arrival Era</th>
- <th>Historical Context</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>L1 Cache Hit</td>
- <td>1 ns</td>
- <td>3 days</td>
- <td>-0043-03-18</td>
- <td>Three days after the assassination.</td>
- </tr>
- <tr>
- <td>DRAM (Main memory)</td>
- <td>100 ns</td>
- <td>300 days</td>
- <td>-0042-01-09</td>
- <td>Nearly a year later, during the Liberators' civil war.</td>
- </tr>
- <tr>
- <td>NVMe SSD Page Swap</td>
- <td>15 µs</td>
- <td>45,000 days</td>
- <td>0080</td>
- <td>123 years later, exactly as the Colosseum is completed in Rome.</td>
- </tr>
- <tr>
- <td>SATA SSD Page Swap</td>
- <td>100 µs</td>
- <td>300,000 days</td>
- <td>0778</td>
- <td>821 years later, during the reign of Charlemagne and the Frankish Empire.</td>
- </tr>
- <tr>
- <td>Magnetic HDD Page Swap</td>
- <td>10 ms</td>
- <td>30,000,000 days</td>
- <td>82092</td>
- <td>Tens of thousands of years in the future, long after current human civilizations are dust.</td>
- </tr>
- </tbody>
- </table>
+ Let us put this into perspective. Suppose in ancient Roman times that a clock tick for a computer was scaled to be one day long, so that the action involves sending letters rather than variable values. Under this scale, a single nanosecond of real world execution time equates to three days. Suppose a program initiated a read request for a location in memory on the Ides of March, the date when Caesar was assassinated on -0043-03-15. Surely that was a big day for posting letters. Table <RT·counter·read snapshot="Table·memory-tier_scaled-latency"></RT·counter·read> provides the historical date that the variable value would finally be loaded into the processor, depending on the memory tier being accessed:
+ </p>
+
+ <RT·counter·step counter="RT·Table·counter" id="Table·memory-tier_scaled-latency">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·memory-tier_scaled-latency"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <thead>
+ <tr>
+ <th>Memory Tier</th>
+ <th>Real World Latency</th>
+ <th>Scaled Delay</th>
+ <th>Scaled Arrival Era</th>
+ <th>Historical Context</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>L1 Cache Hit</td>
+ <td>1 ns</td>
+ <td>3 days</td>
+ <td>-0043-03-18</td>
+ <td>Three days after the assassination.</td>
+ </tr>
+ <tr>
+ <td>DRAM (Main memory)</td>
+ <td>100 ns</td>
+ <td>300 days</td>
+ <td>-0042-01-09</td>
+ <td>Nearly a year later, during the Liberators' civil war.</td>
+ </tr>
+ <tr>
+ <td>NVMe SSD Page Swap</td>
+ <td>15 µs</td>
+ <td>45,000 days</td>
+ <td>0080</td>
+ <td>123 years later, exactly as the Colosseum is completed in Rome.</td>
+ </tr>
+ <tr>
+ <td>SATA SSD Page Swap</td>
+ <td>100 µs</td>
+ <td>300,000 days</td>
+ <td>0778</td>
+ <td>821 years later, during the reign of Charlemagne and the Frankish Empire.</td>
+ </tr>
+ <tr>
+ <td>Magnetic HDD Page Swap</td>
+ <td>10 ms</td>
+ <td>30,000,000 days</td>
+ <td>82092</td>
+ <td>Tens of thousands of years in the future, long after current human civilizations are dust.</td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·memory-tier_scaled-latency"></RT·counter·read>. <RT·name>Memory tier latency, scaled so that one clock tick lasts one day</RT·name>
+ </RT·counter·step>
<p>
In computer architecture, there is a rule that the slower the access time, the larger the amount of data that should be transferred. The idea is then that of access time per bit, instead of access time per fetch. A common example given is that of a station wagon of hard drives driven across the country. <RT·endnote>Andrew S. Tanenbaum famously coined this concept in his 1981 textbook <em>Computer Networks</em>, stating: "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." This physical data transfer method is universally referred to as a sneakernet.</RT·endnote> Ten terabits, at three days, equates to 26 nanoseconds per bit. Not bad, if a user can wait three days to continue the program, but aliasing between data sets would make a program very slow. The Turing Machine model does not capture the effects of clumped data accesses.
<p>Applying this mechanical procedure to the TTCA two-headed reverse string example controller results in:</p>
- <RT·code>
- # Phase 1: Both heads scan right to the EOM pivot
- L·initial:
- read('s' ,0)
- jump(s, {EOM: L·Check_Empty, def: L·Scan_Right})
-
- L·Scan_Right:
- right(0)
- right(1)
- jump(def: L·initial)
-
- # Phase 2: Setup pointers or short-circuit on empty string
- L·Check_Empty:
- status(0)
- jump(s, {leftmost: L·Empty_Setup, def: L·Setup_Write})
-
- L·Empty_Setup:
- right(1)
- jump(def: L·Write_EOR_Done)
-
- L·Setup_Write:
- right(1)
- left(0)
- jump(def: L·Copy_Read)
-
- # Phase 3: The Linear Copy Loop
- L·Copy_Read:
- read('d' ,0)
- status(0)
- jump(s, {leftmost: L·Copy_Last, def: L·Copy_Loop})
-
- L·Copy_Loop:
- write('σ' ,0 ,SP)
- write('d' ,1)
- right(1)
- left(0)
- jump(def: L·Copy_Read)
-
- # Phase 4: Final character, advance, and clean halt
- L·Copy_Last:
- write('σ' ,0 ,SP)
- write('d' ,1)
- right(1)
- jump(def: L·Write_EOR_Done)
-
- L·Write_EOR_Done:
- write('σ' ,1 ,EOR)
- halt
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·two-headed-reverse_linearized">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·two-headed-reverse_linearized"></RT·counter·snapshot>
+ <RT·code>
+ # Phase 1: Both heads scan right to the EOM pivot
+ L·initial:
+ read('s' ,0)
+ jump(s, {EOM: L·Check_Empty, def: L·Scan_Right})
+
+ L·Scan_Right:
+ right(0)
+ right(1)
+ jump(def: L·initial)
+
+ # Phase 2: Setup pointers or short-circuit on empty string
+ L·Check_Empty:
+ status(0)
+ jump(s, {leftmost: L·Empty_Setup, def: L·Setup_Write})
+
+ L·Empty_Setup:
+ right(1)
+ jump(def: L·Write_EOR_Done)
+
+ L·Setup_Write:
+ right(1)
+ left(0)
+ jump(def: L·Copy_Read)
+
+ # Phase 3: The Linear Copy Loop
+ L·Copy_Read:
+ read('d' ,0)
+ status(0)
+ jump(s, {leftmost: L·Copy_Last, def: L·Copy_Loop})
+
+ L·Copy_Loop:
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+ right(1)
+ left(0)
+ jump(def: L·Copy_Read)
+
+ # Phase 4: Final character, advance, and clean halt
+ L·Copy_Last:
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+ right(1)
+ jump(def: L·Write_EOR_Done)
+
+ L·Write_EOR_Done:
+ write('σ' ,1 ,EOR)
+ halt
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·two-headed-reverse_linearized"></RT·counter·read>. <RT·name>The two headed reverse controller as linear code with jumps</RT·name>
+ </RT·counter·step>
<p>The state labels have become addresses into the program tape, and the address of the cell indicated by the head on the first tape is now an Instruction Pointer (IP). In a sense the programmed controller has been replaced by a little Turing Machine of its own. One that controls the head on the first tape, and moves it in response to the control instructions found on the first tape. Such a controller on a processor is called a <RT·term>sequencer</RT·term>.</p>
<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:
- read('s' ,0)
- test('s' ,EOM)
- beq L·Check_Empty
-
- # L·Scan_Right (Implicit fall-through)
- right(0)
- right(1)
- jump L·initial
-
- # Phase 2: Setup pointers or short-circuit on empty string
- L·Check_Empty:
- status(0)
- test('s' ,leftmost)
- beq L·Empty_Setup
-
- # L·Setup_Write (Implicit fall-through)
- right(1)
- left(0)
-
- # Phase 3: The Linear Copy Loop
- L·Copy_Read:
- read('d' ,0)
- status(0)
- test('s' ,leftmost)
- beq L·Copy_Last
-
- # L·Copy_Loop (Implicit fall-through)
- write('σ' ,0 ,SP)
- write('d' ,1)
- right(1)
- left(0)
- jump L·Copy_Read
-
- # Phase 4: Final character, advance, and clean halt
- L·Copy_Last:
- write('σ' ,0 ,SP)
- write('d' ,1)
-
- L·Empty_Setup:
- right(1)
-
- # L·Write_EOR_Done (Implicit fall-through)
- write('σ' ,1 ,EOR)
- halt
- </RT·code>
+ <p>Some of the default cases for the jump table unnecessarily jump to the instruction at the next sequential address. Code <RT·counter·read snapshot="Code·two-headed-reverse_linearized"></RT·counter·read> 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·counter·step counter="RT·Code·counter" id="Code·two-headed-reverse_with_branches">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·two-headed-reverse_with_branches"></RT·counter·snapshot>
+ <RT·code>
+ # Phase 1: Both heads scan right to the EOM pivot
+ L·initial:
+ read('s' ,0)
+ test('s' ,EOM)
+ beq L·Check_Empty
+
+ # L·Scan_Right (Implicit fall-through)
+ right(0)
+ right(1)
+ jump L·initial
+
+ # Phase 2: Setup pointers or short-circuit on empty string
+ L·Check_Empty:
+ status(0)
+ test('s' ,leftmost)
+ beq L·Empty_Setup
+
+ # L·Setup_Write (Implicit fall-through)
+ right(1)
+ left(0)
+
+ # Phase 3: The Linear Copy Loop
+ L·Copy_Read:
+ read('d' ,0)
+ status(0)
+ test('s' ,leftmost)
+ beq L·Copy_Last
+
+ # L·Copy_Loop (Implicit fall-through)
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+ right(1)
+ left(0)
+ jump L·Copy_Read
+
+ # Phase 4: Final character, advance, and clean halt
+ L·Copy_Last:
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+
+ L·Empty_Setup:
+ right(1)
+
+ # L·Write_EOR_Done (Implicit fall-through)
+ write('σ' ,1 ,EOR)
+ halt
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·two-headed-reverse_with_branches"></RT·counter·read>. <RT·name>The same controller using test, branch and jump instructions</RT·name>
+ </RT·counter·step>
<p>This is an assembly-level code description of an instruction sequence. To get it into final form, the labels that appear as instruction arguments would be replaced with their addresses. Symbolic labels would not appear on the tape. As an alternative to using absolute branches, relative branches could be used. Performance will be greatly enhanced for a sequencer that performs relative branching if it contains an adder circuit; otherwise, the addition of offsets would be another TTCA program invocation.</p>
</RT·section>
- <RT·section>
+ <RT·section id="Section·symbol_in-computing">
<RT·name>Symbol in computing</RT·name>
<p>
</p>
<p>
- At the time of this writing many machines use 64 bit words. This is equivalent to 8 ASCII characters, while the average size of an identifier is about 5 characters. Hence the approach of using a string as a symbol might not be as inefficient as it seems to be at first. Using strings has advantages. Symbol instances can carry semantic clues for the programmer. There is no hazard of conflating the string instance with the name, as they are the same. Also, a string instance will have integrity across contexts, such as between invocations or when passed between processes (note the section below on crossing context boundaries). A drawback is in cases there is no language support, the strings are typically ad hoc so the guarantee of distinctness becomes merely a contract with the programmer.
+ At the time of this writing many machines use 64 bit words. This is equivalent to 8 ASCII characters, while the average size of an identifier is about 5 characters. Hence the approach of using a string as a symbol might not be as inefficient as it seems to be at first. Using strings has advantages. Symbol instances can carry semantic clues for the programmer. There is no hazard of conflating the string instance with the name, as they are the same. Also, a string instance will have integrity across contexts, such as between invocations or when passed between processes (note section <RT·counter·read snapshot="Section·distinctness_across-contexts"></RT·counter·read>, on crossing context boundaries). A drawback is in cases there is no language support, the strings are typically ad hoc so the guarantee of distinctness becomes merely a contract with the programmer.
</p>
</RT·section>
- <RT·section>
+ <RT·section id="Section·distinctness_across-contexts">
<RT·name>Distinctness across contexts</RT·name>
<p>
The <RT·code>enum</RT·code> of C is used to make alphabets of named symbols. Each entry in the enum is a static symbol factory, and instances are distinct integers.
</p>
- <RT·code>
- /* The enum definition acts as the factory. */
- typedef enum {
- SYMBOL_EMPTY = 0,
- SYMBOL_ZERO = 1,
- SYMBOL_ONE = 2,
- SYMBOL_A = 3,
- SYMBOL_B = 4
- } TapeAlphabet;
-
- /* Instantiating copies of the symbols: */
- TapeAlphabet cell_1 = SYMBOL_A;
- TapeAlphabet cell_2 = SYMBOL_A;
-
- /* Equality comparison over instances */
- if(cell_1 == cell_2){
- /* Evaluates to True */
- }
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·symbol-factory_enum">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·symbol-factory_enum"></RT·counter·snapshot>
+ <RT·code>
+ /* The enum definition acts as the factory. */
+ typedef enum {
+ SYMBOL_EMPTY = 0,
+ SYMBOL_ZERO = 1,
+ SYMBOL_ONE = 2,
+ SYMBOL_A = 3,
+ SYMBOL_B = 4
+ } TapeAlphabet;
+
+ /* Instantiating copies of the symbols: */
+ TapeAlphabet cell_1 = SYMBOL_A;
+ TapeAlphabet cell_2 = SYMBOL_A;
+
+ /* Equality comparison over instances */
+ if(cell_1 == cell_2){
+ /* Evaluates to True */
+ }
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·symbol-factory_enum"></RT·counter·read>. <RT·name>A static symbol factory made with a C enum</RT·name>
+ </RT·counter·step>
<p>
The <RT·code>enum</RT·code> is a static alphabet made by the compiler, where symbol instances are integers. In the following example, the alphabet is made dynamically, where each symbol instance is a string pointer.
</p>
- <RT·code>
- #include <string.h>
- #include <stdlib.h>
- #include <stdio.h>
-
- // maximum legal index into the symbol list
- #define LIST_EXTENT 3
-
- typedef const char *Instance;
- typedef struct{
- Instance *head;
- Instance *tail;
- Instance *extent;
- } List;
+ <RT·counter·step counter="RT·Code·counter" id="Code·symbol-factory_dynamic">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·symbol-factory_dynamic"></RT·counter·snapshot>
+ <RT·code>
+ #include <string.h>
+ #include <stdlib.h>
+ #include <stdio.h>
+
+ // maximum legal index into the symbol list
+ #define LIST_EXTENT 3
+
+ typedef const char *Instance;
+ typedef struct{
+ Instance *head;
+ Instance *tail;
+ Instance *extent;
+ } List;
+
+ static List SYM_LIST = {NULL ,NULL ,NULL};
+
+ Instance make_list(const char *name){
+ size_t size = LIST_EXTENT + 1;
+ SYM_LIST.head = (Instance *)malloc( size * sizeof(Instance) );
+ SYM_LIST.tail = SYM_LIST.head;
+ SYM_LIST.extent = SYM_LIST.head + LIST_EXTENT;
+ *SYM_LIST.head = strdup(name);
+ return *SYM_LIST.head;
+ }
- static List SYM_LIST = {NULL ,NULL ,NULL};
+ Instance make_symbol(const char *name){
+ if(!SYM_LIST.head) return make_list(name);
- Instance make_list(const char *name){
- size_t size = LIST_EXTENT + 1;
- SYM_LIST.head = (Instance *)malloc( size * sizeof(Instance) );
- SYM_LIST.tail = SYM_LIST.head;
- SYM_LIST.extent = SYM_LIST.head + LIST_EXTENT;
- *SYM_LIST.head = strdup(name);
- return *SYM_LIST.head;
- }
+ Instance *pt = SYM_LIST.head;
+ while(1){
+ if( strcmp(*pt ,name) == 0 ) return *pt;
- Instance make_symbol(const char *name){
- if(!SYM_LIST.head) return make_list(name);
+ if(pt == SYM_LIST.extent){
+ fprintf(stderr ,"symbol list overflow for %s\n" ,name);
+ return NULL;
+ }
- Instance *pt = SYM_LIST.head;
- while(1){
- if( strcmp(*pt ,name) == 0 ) return *pt;
+ if(pt == SYM_LIST.tail){
+ *++SYM_LIST.tail = strdup(name);
+ return *SYM_LIST.tail;
+ }
- if(pt == SYM_LIST.extent){
- fprintf(stderr ,"symbol list overflow for %s\n" ,name);
- return NULL;
+ pt++;
}
+ }
- if(pt == SYM_LIST.tail){
- *++SYM_LIST.tail = strdup(name);
- return *SYM_LIST.tail;
+ int main(){
+ Instance a = make_symbol("a");
+ Instance b = make_symbol("b");
+ Instance c = make_symbol("c");
+ Instance d = make_symbol("d");
+ Instance e = make_symbol("e"); // overflows table
+
+ Instance *pt = SYM_LIST.head;
+ Instance *pt_tail = SYM_LIST.tail;
+ while(1){
+ puts(*pt);
+ if(pt == pt_tail) break;
+ pt++;
}
- pt++;
+ if(e == NULL) printf("e is NULL\n");
}
- }
-
- int main(){
- Instance a = make_symbol("a");
- Instance b = make_symbol("b");
- Instance c = make_symbol("c");
- Instance d = make_symbol("d");
- Instance e = make_symbol("e"); // overflows table
-
- Instance *pt = SYM_LIST.head;
- Instance *pt_tail = SYM_LIST.tail;
- while(1){
- puts(*pt);
- if(pt == pt_tail) break;
- pt++;
- }
-
- if(e == NULL) printf("e is NULL\n");
- }
- </RT·code>
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·symbol-factory_dynamic"></RT·counter·read>. <RT·name>A dynamic symbol factory whose instances are string pointers</RT·name>
+ </RT·counter·step>
</RT·section>
</RT·section>
- <RT·section>
+ <RT·section id="Section·tape-cell">
<RT·name>A Turing Machine tape cell</RT·name>
<p>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section>
+ <RT·section id="Section·computational-analysis">
<RT·name>Computational Analysis</RT·name>
<RT·section>
</p>
<p>
- This analytical perspective has been present from the very beginning of the field. Alan Turing's formulation of the halting problem relies explicitly on one machine examining another. To properly evaluate the limits of this analytical capacity, the examining machine must necessarily be given definitions of programs that loop infinitely. Consequently, the foundational proofs of computer science formally establish non computational programs as legitimate objects of analytical study.
- </p>
-
- <p>
- We call a program that examines another program so as to deduce properties of its results an <RT·term>analyzer</RT·term>. The program or machine definition being subjected to this evaluation is called the <RT·term>studied program</RT·term> or <RT·term>studied machine</RT·term>.
+ The orders of analysis were named in section
+ <RT·counter·read snapshot="Section·orders-of-analysis"></RT·counter·read>. This
+ chapter takes the second order as its working material.
</p>
- <p>
- Turing Machines that halt in a finite number of steps for any finite input within a stipulated domain are said to be <RT·term>computational</RT·term> over that domain.
- </p>
<p>
- By definition, first order analysis is the running of programs, and it has its place.
- Generally, when we want to know what output a computational machine will produce, the fastest route to this knowledge is to run the program. Most programs written to solve problems are most effectively run to solve those problems rather than analyzed to deduce what they will produce.
+ This analytical perspective has been present from the very beginning of the field. Alan Turing's formulation of the halting problem relies explicitly on one machine examining another. To properly evaluate the limits of this analytical capacity, the examining machine must necessarily be given definitions of programs that loop infinitely. Consequently, the foundational proofs of computer science formally establish non computational programs as legitimate objects of analytical study.
</p>
- <p>
- Now suppose we quantify the inputs to a computational machine over a domain and want to know a property of the machine. Perhaps, say, that it always produces an even number. If the quantification is over a large set, then it might be faster to study the machine than it would be to run the machine on every input in the domain while checking its output.
- </p>
- <p>
- Further suppose that the quantification is over an infinite input space. Then the only option for answering a question about the properties of results from such a machine is to analyze it. This is second order analysis, also called simply <RT·term>analysis</RT·term>.
- </p>
- <p>
- Famously, we know that universally an analyzer cannot determine if a machine is computational. This knowledge was derived by reasoning about the properties of a hypothetically existing analyzer machine. This is a third order analysis activity.
- </p>
<p>
As an analyzer does not run the machine being studied, it is not required to be a machine that halts. Suppose we have a machine that produces an infinite sequence of digits to a tape without halting. A limit analyzer could examine that machine and, in some cases, determine if it has asymptotic behavior. For example, recognizing that appending a binary fractional sequence of <RT·math>0.1111...</RT·math> indefinitely evaluates in the limit to <RT·math>1.0</RT·math>. In this manner, the use of analyzers facilitates using computation theory for deriving higher order mathematics.
Suppose our goal is to subtract 3 from 5 in the second order. Consider a Turing Machine representation named <RT·code>five</RT·code> that outputs the number 5, i.e., it prints to the tape, 'sssss', using unary notation. Let us assume that the tape is initially empty and that the empty symbol '□' terminates the string. To preserve the code for second order analysis, we define the program's Abstract Syntax Tree (AST) as a quoted <RT·code>progn</RT·code> block. This block can contain any native Lisp control structures, though for this generator it is a simple sequence:
</p>
- <RT·code>
- (defparameter *five-ast*
- '(progn
- (write s) (step)
- (write s) (step)
- (write s) (step)
- (write s) (step)
- (write s) (step)
- ))
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·five_AST">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·five_AST"></RT·counter·snapshot>
+ <RT·code>
+ (defparameter *five-ast*
+ '(progn
+ (write s) (step)
+ (write s) (step)
+ (write s) (step)
+ (write s) (step)
+ (write s) (step)
+ ))
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·five_AST"></RT·counter·read>. <RT·name>The abstract syntax tree for the natural number five</RT·name>
+ </RT·counter·step>
<p>Similarly, the AST for the number 3:</p>
- <RT·code>
- (defparameter *three-ast*
- '(progn
- (write s) (step)
- (write s) (step)
- (write s) (step)
- ))
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·three_AST">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·three_AST"></RT·counter·snapshot>
+ <RT·code>
+ (defparameter *three-ast*
+ '(progn
+ (write s) (step)
+ (write s) (step)
+ (write s) (step)
+ ))
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·three_AST"></RT·counter·read>. <RT·name>The abstract syntax tree for the natural number three</RT·name>
+ </RT·counter·step>
<p>
If we were to dynamically evaluate these ASTs in the first order, the Hindu-Arabic representation of each number would be physically written in unary code on the tape.
For the second order difference operation, we compose the ASTs to create a new program. Here we extract the body of the second operand's AST and substitute every <RT·code>(write s)</RT·code> followed by a <RT·code>(step)</RT·code> instruction with an inverted pair: a <RT·code>(left)</RT·code> instruction followed by writing the empty symbol <RT·code>(write □)</RT·code>.
</p>
- <RT·code>
- (defun invert-direction (cmds)
- (cond
- ((null cmds) nil)
- (
- (and
- (cdr cmds)
- (equal (first cmds) '(write s))
- (equal (second cmds) '(step)))
- (append
- '((left) (write □))
- (invert-direction (cddr cmds))
- ))
- (
- t
- (cons
- (first cmds)
- (invert-direction (cdr cmds))
- ))))
-
- (defun primitive-compose-subtract (ast-a ast-b)
- (let
- (
- (body-a (rest ast-a))
- (body-b (rest ast-b))
- )
- `(progn
- ,@body-a
- ,@(invert-direction body-b)
- )))
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·subtract_composer">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·subtract_composer"></RT·counter·snapshot>
+ <RT·code>
+ (defun invert-direction (cmds)
+ (cond
+ ((null cmds) nil)
+ (
+ (and
+ (cdr cmds)
+ (equal (first cmds) '(write s))
+ (equal (second cmds) '(step)))
+ (append
+ '((left) (write □))
+ (invert-direction (cddr cmds))
+ ))
+ (
+ t
+ (cons
+ (first cmds)
+ (invert-direction (cdr cmds))
+ ))))
+
+ (defun primitive-compose-subtract (ast-a ast-b)
+ (let
+ (
+ (body-a (rest ast-a))
+ (body-b (rest ast-b))
+ )
+ `(progn
+ ,@body-a
+ ,@(invert-direction body-b)
+ )))
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·subtract_composer"></RT·counter·read>. <RT·name>A composer that subtracts by inverting the direction of one machine</RT·name>
+ </RT·counter·step>
<p>We pass our two natural number ASTs to this composer, and we get as a result a newly synthesized AST.</p>
- <RT·code>
- (defparameter
- *primitive-five-minus-3-ast*
- (primitive-compose-subtract *five-ast* *three-ast*)
- )
-
- ;; *primitive-five-minus-3-ast* evaluates to:
- ;; '(progn
- ;; (write s) (step)
- ;; (write s) (step)
- ;; (write s) (step)
- ;; (write s) (step)
- ;; (write s) (step)
- ;; (left) (write □)
- ;; (left) (write □)
- ;; (left) (write □)
- ;; )
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·five-minus-three_primitive">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·five-minus-three_primitive"></RT·counter·snapshot>
+ <RT·code>
+ (defparameter
+ *primitive-five-minus-3-ast*
+ (primitive-compose-subtract *five-ast* *three-ast*)
+ )
+
+ ;; *primitive-five-minus-3-ast* evaluates to:
+ ;; '(progn
+ ;; (write s) (step)
+ ;; (write s) (step)
+ ;; (write s) (step)
+ ;; (write s) (step)
+ ;; (write s) (step)
+ ;; (left) (write □)
+ ;; (left) (write □)
+ ;; (left) (write □)
+ ;; )
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·five-minus-three_primitive"></RT·counter·read>. <RT·name>The composed but unsimplified tree for five minus three</RT·name>
+ </RT·counter·step>
<p>
I called this 'primitive' because it is missing the simplification. This sort of simplification is also known as compiler code optimization. Optimizations can be operation specific, or general in nature. Here we will send the primitive composition's body to an analyzer which scans the steps and removes the redundant operations.
For a program containing branched control logic, the simplifier would require a deep recursive walk of the AST to ensure operations aren't annihilated across conditional boundaries. For our explicit natural number generators, a linear scan of the <RT·code>progn</RT·code> body suffices. It calls itself recursively until the scan fails to find any further reductions, returning its optimized AST.
</p>
- <RT·code>
- (defun remove-annihilations (cmds)
- (cond
- ((null cmds) nil)
- (
- (and
- (cdr cmds)
- (equal (first cmds) '(step))
- (equal (second cmds) '(left)))
- (remove-annihilations (cddr cmds)))
- (
- (and
- (cdr cmds)
- (equal (first cmds) '(write s))
- (equal (second cmds) '(write □)))
- (remove-annihilations (cddr cmds)))
- (
- t
- (cons
- (first cmds)
- (remove-annihilations (cdr cmds))
- ))))
-
- (defun simplify-machine (ast)
- (let*
- (
- (cmds (rest ast))
- (reduced (remove-annihilations cmds))
- )
- (if
- (equal reduced cmds)
- ast
- (simplify-machine `(progn ,@reduced))
- )))
-
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·machine_simplifier">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·machine_simplifier"></RT·counter·snapshot>
+ <RT·code>
+ (defun remove-annihilations (cmds)
+ (cond
+ ((null cmds) nil)
+ (
+ (and
+ (cdr cmds)
+ (equal (first cmds) '(step))
+ (equal (second cmds) '(left)))
+ (remove-annihilations (cddr cmds)))
+ (
+ (and
+ (cdr cmds)
+ (equal (first cmds) '(write s))
+ (equal (second cmds) '(write □)))
+ (remove-annihilations (cddr cmds)))
+ (
+ t
+ (cons
+ (first cmds)
+ (remove-annihilations (cdr cmds))
+ ))))
+
+ (defun simplify-machine (ast)
+ (let*
+ (
+ (cmds (rest ast))
+ (reduced (remove-annihilations cmds))
+ )
+ (if
+ (equal reduced cmds)
+ ast
+ (simplify-machine `(progn ,@reduced))
+ )))
+
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·machine_simplifier"></RT·counter·read>. <RT·name>A simplifier that removes annihilating instruction pairs</RT·name>
+ </RT·counter·step>
<p>After giving the difference program to the simplifier, we get:</p>
- <RT·code>
- (defparameter
- *simplified-five-minus-3-ast*
- (simplify-machine *primitive-five-minus-3-ast*)
- )
-
- ;; *simplified-five-minus-3-ast* evaluates to:
- ;; '(progn
- ;; (write s) (step)
- ;; (write s) (step))
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·five-minus-three_simplified">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·five-minus-three_simplified"></RT·counter·snapshot>
+ <RT·code>
+ (defparameter
+ *simplified-five-minus-3-ast*
+ (simplify-machine *primitive-five-minus-3-ast*)
+ )
+
+ ;; *simplified-five-minus-3-ast* evaluates to:
+ ;; '(progn
+ ;; (write s) (step)
+ ;; (write s) (step))
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·five-minus-three_simplified"></RT·counter·read>. <RT·name>The simplified tree for five minus three</RT·name>
+ </RT·counter·step>
<p>This technique of composing Turing Machine programs in the presence of simplification is closely related to that of symbol computation and expression simplification that we find in math tools such as Mathematica. We can imagine our Turing Machines as functions with names, and then symbolic computation leaves them unevaluated as here. Then the Mathematica <RT·code>Simplify</RT·code> is the compiler optimization simplifier as above. A difference in these two systems is that of the functions being reduced to Turing Machine head and tape transport unit instructions.</p>
Let us take the multiplicative inverse of the additive identity as an example, AKA division by zero. In the second order, when we attempt to compute a division, say 6/0, the machine will not reduce.
</p>
- <RT·code>
- (divide 6 0)
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·divide-by-zero">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·divide-by-zero"></RT·counter·snapshot>
+ <RT·code>
+ (divide 6 0)
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·divide-by-zero"></RT·counter·read>. <RT·name>A division by zero, which does not reduce</RT·name>
+ </RT·counter·step>
<p>Now consider the compiler optimization like simplification of this expression:</p>
- <RT·code>
- (divide (divide 6 0) (divide 3 0))
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·divide-by-zero_composed">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·divide-by-zero_composed"></RT·counter·snapshot>
+ <RT·code>
+ (divide (divide 6 0) (divide 3 0))
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·divide-by-zero_composed"></RT·counter·read>. <RT·name>A composition of two unreduced divisions</RT·name>
+ </RT·counter·step>
<p>The result will be:</p>
- <RT·code>
- (multiply 2 (divide 0 0))
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·divide-by-zero_result">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·divide-by-zero_result"></RT·counter·snapshot>
+ <RT·code>
+ (multiply 2 (divide 0 0))
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·divide-by-zero_result"></RT·counter·read>. <RT·name>The reduced result, still carrying a divide of zero by zero</RT·name>
+ </RT·counter·step>
<p>
There is no special help here. Hence, <RT·code>(divide 0 0)</RT·code> remains as an error flag.
Let us construct a forward difference pyramid for the polynomial <RT·math>f(t) = t^2</RT·math>.
</p>
- <table>
- <thead>
- <tr>
- <th>Count (<RT·math>t</RT·math>)</th>
- <th><RT·math>f(t) = t^2</RT·math></th>
- <th>1st Diff (<RT·math>δ^1</RT·math>)</th>
- <th>2nd Diff (<RT·math>δ^2</RT·math>)</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>0</td>
- <td>0</td>
- <td>1</td>
- <td>2</td>
- </tr>
- <tr>
- <td>1</td>
- <td>1</td>
- <td>3</td>
- <td>2</td>
- </tr>
- <tr>
- <td>2</td>
- <td>4</td>
- <td>5</td>
- <td>2</td>
- </tr>
- <tr>
- <td>3</td>
- <td>9</td>
- <td>7</td>
- <td></td>
- </tr>
- <tr>
- <td>4</td>
- <td>16</td>
- <td></td>
- <td></td>
- </tr>
- </tbody>
- </table>
+ <RT·counter·step counter="RT·Table·counter" id="Table·difference-table_for_t-squared">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·difference-table_for_t-squared"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <thead>
+ <tr>
+ <th>Count (<RT·math>t</RT·math>)</th>
+ <th><RT·math>f(t) = t^2</RT·math></th>
+ <th>1st Diff (<RT·math>δ^1</RT·math>)</th>
+ <th>2nd Diff (<RT·math>δ^2</RT·math>)</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>0</td>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1</td>
+ <td>3</td>
+ <td>2</td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>4</td>
+ <td>5</td>
+ <td>2</td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td>9</td>
+ <td>7</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>16</td>
+ <td></td>
+ <td></td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·difference-table_for_t-squared"></RT·counter·read>. <RT·name>The forward difference table for f(t) = t²</RT·name>
+ </RT·counter·step>
<p>
In order to design for indefinite extension, the Turing Machine tape must retain the function value alongside with its forward differences. Because the second difference is constant higher order differences are all zero. Hence the tape requires a three component vector to hold the differences.
Here is the sequence of tape states as the machine is repeatedly called to extend the function from its initial conditions at <RT·math>t = 0</RT·math>. During each step, the machine adds <RT·math>δ^1</RT·math> to <RT·math>f</RT·math>, and <RT·math>δ^2</RT·math> to <RT·math>δ^1</RT·math>, as there is no <RT·math>δ^3</RT·math>, it is taken to be zero, so <RT·math>δ^2</RT·math> is merely copied down.
</p>
- <RT·code>
- Initial Tape (t=0): [0, 1, 2]
- Call 1 (t=1): [1, 3, 2]
- Call 2 (t=2): [4, 5, 2]
- Call 3 (t=3): [9, 7, 2]
- Call 4 (t=4): [16, 9, 2]
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·difference-engine_tape-trace">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·difference-engine_tape-trace"></RT·counter·snapshot>
+ <RT·code>
+ Initial Tape (t=0): [0, 1, 2]
+ Call 1 (t=1): [1, 3, 2]
+ Call 2 (t=2): [4, 5, 2]
+ Call 3 (t=3): [9, 7, 2]
+ Call 4 (t=4): [16, 9, 2]
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·difference-engine_tape-trace"></RT·counter·read>. <RT·name>The tape at each call while extending t²</RT·name>
+ </RT·counter·step>
<p>
For Call 1, the input tape is the Initial Tape. In Call 1 the machine will take the function value on the input tape, 0, and add the first difference, 1, writing the result 1, to the result tape. The machine will then continue on and take the first difference on the input tape, 1, and add the second difference on the input tape, 2, writing the result first difference to the result tape, 3. Then finishing up, the machine will not find a third difference on the input tape, so it will copy the second difference found on the input tape as the second difference for the result tape.
</RT·section>
- <RT·section>
+ <RT·section id="Section·lemma_evaluating-call">
<RT·name>Lemma: Evaluating call <RT·math>\omega</RT·math> requires an initial tape populated with components 0 through <RT·math>\omega</RT·math> of row 0</RT·name>
<p>
The exact algebraic composition of this mechanical expansion is formalized by Newton's calculus of finite differences <RT·endnote>Isaac Newton formalized this interpolation method in 1675, later published in his <em>Methodus Differentialis</em> (1711). For a comprehensive foundational treatment, see George Boole, <em>A Treatise on the Calculus of Finite Differences</em> (Cambridge: Macmillan and Co., 1860), Chapter II.</RT·endnote>. Instead of executing the machine incrementally, a person can calculate the function value at call <RT·math>\omega</RT·math> directly as a linear combination of the initial tape components using Newton's forward difference formula:
</p>
- <RT·math>
- D_{\omega, 0} = \sum_{j=0}^{\omega} \binom{\omega}{j} D_{0, j}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·Newton_forward-difference">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Newton_forward-difference"></RT·counter·snapshot>
+ <RT·math>
+ D_{\omega, 0} = \sum_{j=0}^{\omega} \binom{\omega}{j} D_{0, j}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·Newton_forward-difference"></RT·counter·read> <RT·name>Newton's forward difference formula for the value at call ω</RT·name>
+ </RT·counter·step>
<p>
Because the binomial coefficient <RT·math>\binom{\omega}{j}</RT·math> evaluates to exactly zero for any integer <RT·math>j > \omega</RT·math>, the summation naturally truncates at index <RT·math>\omega</RT·math>. This algebraic property perfectly mirrors the physical boundary established by the machine execution trace. Furthermore, the relationship is symmetric. A person can compute the specific components of the initial tape, <RT·math>D_{0, n}</RT·math>, directly from the sequence of evaluated function calls, <RT·math>D_{k, 0}</RT·math>, using the alternating binomial sum:
</p>
- <RT·math>
- D_{0, n} = \sum_{k=0}^{n} (-1)^{n-k} \binom{n}{k} D_{k, 0}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·initial-tape_from_evaluations">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·initial-tape_from_evaluations"></RT·counter·snapshot>
+ <RT·math>
+ D_{0, n} = \sum_{k=0}^{n} (-1)^{n-k} \binom{n}{k} D_{k, 0}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·initial-tape_from_evaluations"></RT·counter·read> <RT·name>The initial tape components recovered from evaluated calls</RT·name>
+ </RT·counter·step>
<p>
As a consequence of this lemma, we know that for any finite number of calls, i.e. finite <RT·math>\omega</RT·math>, that a finite prefix of <RT·math>D_0</RT·math> is used.
To observe the structural integrity of this progression, a person can array these relationships into a system of equations mapping the initial tape to the polynomial constants:
</p>
- <table>
- <thead>
- <tr>
- <th>Difference</th>
- <th>Equation</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><RT·math>D_{0,0}</RT·math></td>
- <td><RT·math>= a_0</RT·math></td>
- </tr>
- <tr>
- <td><RT·math>D_{0,1}</RT·math></td>
- <td><RT·math>= a_1 + a_2 + a_3 + \ldots + a_\omega</RT·math></td>
- </tr>
- <tr>
- <td><RT·math>D_{0,2}</RT·math></td>
- <td><RT·math>= 2a_2 + 6a_3 + \ldots</RT·math></td>
- </tr>
- <tr>
- <td><RT·math>D_{0,3}</RT·math></td>
- <td><RT·math>= 6a_3 + \ldots</RT·math></td>
- </tr>
- <tr>
- <td><RT·math>\ldots</RT·math></td>
- <td><RT·math>\ldots</RT·math></td>
- </tr>
- <tr>
- <td><RT·math>D_{0,\omega}</RT·math></td>
- <td><RT·math>= \omega! a_\omega</RT·math></td>
- </tr>
- </tbody>
- </table>
+ <RT·counter·step counter="RT·Table·counter" id="Table·difference_equations">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·difference_equations"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <thead>
+ <tr>
+ <th>Difference</th>
+ <th>Equation</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><RT·math>D_{0,0}</RT·math></td>
+ <td><RT·math>= a_0</RT·math></td>
+ </tr>
+ <tr>
+ <td><RT·math>D_{0,1}</RT·math></td>
+ <td><RT·math>= a_1 + a_2 + a_3 + \ldots + a_\omega</RT·math></td>
+ </tr>
+ <tr>
+ <td><RT·math>D_{0,2}</RT·math></td>
+ <td><RT·math>= 2a_2 + 6a_3 + \ldots</RT·math></td>
+ </tr>
+ <tr>
+ <td><RT·math>D_{0,3}</RT·math></td>
+ <td><RT·math>= 6a_3 + \ldots</RT·math></td>
+ </tr>
+ <tr>
+ <td><RT·math>\ldots</RT·math></td>
+ <td><RT·math>\ldots</RT·math></td>
+ </tr>
+ <tr>
+ <td><RT·math>D_{0,\omega}</RT·math></td>
+ <td><RT·math>= \omega! a_\omega</RT·math></td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·difference_equations"></RT·counter·read>. <RT·name>The initial differences as a system of equations in the polynomial constants</RT·name>
+ </RT·counter·step>
<p>
A pattern emerges. Because each successive forward difference operator annihilates the lowest power of <RT·math>t</RT·math>, the resulting algebraic system is upper triangular. For any extent <RT·math>\omega</RT·math>, the <RT·math>\omega</RT·math>th difference equation reduces to <RT·math>D_{0,\omega} = \omega! a_\omega</RT·math>. This structural guarantee permits a person to reliably recover <RT·math>a_\omega = D_{0,\omega} / \omega!</RT·math>. Because an initial tape of extent <RT·math>\omega</RT·math> dictates that <RT·math>D_{0,\omega}</RT·math> is nonzero, <RT·math>a_\omega</RT·math> is guaranteed to be nonzero. All subsequent lower order constants are then systematically resolved through cascading back substitution.
To observe the formal mechanics of this progression, a person can alternatively array these relationships into a matrix equation mapping the polynomial constants, <RT·math>a_i</RT·math>, to the initial tape differences, <RT·math>D_{0,n}</RT·math>. The coefficients of this transformation are defined by the Stirling numbers of the second kind, denoted <RT·math>S(i,n)</RT·math>:
</p>
- <RT·math>
- \begin{bmatrix} D_{0,0} \\ D_{0,1} \\ D_{0,2} \\ \vdots \\ D_{0,\omega} \end{bmatrix} =
- \begin{bmatrix}
- 0! S(0,0) & 0! S(1,0) & 0! S(2,0) & ⋯ & 0! S(\omega,0) \\
- 0 & 1! S(1,1) & 1! S(2,1) & ⋯ & 1! S(\omega,1) \\
- 0 & 0 & 2! S(2,2) & ⋯ & 2! S(\omega,2) \\
- \vdots & \vdots & \vdots & \ddots & \vdots \\
- 0 & 0 & 0 & ⋯ & \omega! S(\omega,\omega)
- \end{bmatrix}
- \begin{bmatrix} a_0 \\ a_1 \\ a_2 \\ \vdots \\ a_\omega \end{bmatrix}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·Stirling-second_matrix">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Stirling-second_matrix"></RT·counter·snapshot>
+ <RT·math>
+ \begin{bmatrix} D_{0,0} \\ D_{0,1} \\ D_{0,2} \\ \vdots \\ D_{0,\omega} \end{bmatrix} =
+ \begin{bmatrix}
+ 0! S(0,0) & 0! S(1,0) & 0! S(2,0) & ⋯ & 0! S(\omega,0) \\
+ 0 & 1! S(1,1) & 1! S(2,1) & ⋯ & 1! S(\omega,1) \\
+ 0 & 0 & 2! S(2,2) & ⋯ & 2! S(\omega,2) \\
+ \vdots & \vdots & \vdots & \ddots & \vdots \\
+ 0 & 0 & 0 & ⋯ & \omega! S(\omega,\omega)
+ \end{bmatrix}
+ \begin{bmatrix} a_0 \\ a_1 \\ a_2 \\ \vdots \\ a_\omega \end{bmatrix}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·Stirling-second_matrix"></RT·counter·read> <RT·name>Polynomial constants carried to initial differences by Stirling numbers of the second kind</RT·name>
+ </RT·counter·step>
<p>
For any extent <RT·math>\omega</RT·math>, the final row of this strictly upper triangular matrix again simplifies to <RT·math>D_{0,\omega} = \omega! a_\omega</RT·math>.
</p>
<p>
- The main diagonal contains strictly non zero factorials, ensuring the matrix is invertible. By inverting this matrix, a person replaces the cascading back substitution with a direct, closed form equation to recover any constant <RT·math>a_i</RT·math>. The inversion utilizes the signed Stirling numbers of the first kind, denoted <RT·math>s(n,i)</RT·math> (see the Appendix on Stirling numbers).
+ The main diagonal contains strictly non zero factorials, ensuring the matrix is invertible. By inverting this matrix, a person replaces the cascading back substitution with a direct, closed form equation to recover any constant <RT·math>a_i</RT·math>. The inversion utilizes the signed Stirling numbers of the first kind, denoted <RT·math>s(n,i)</RT·math> (see the Appendix on Stirling numbers, section <RT·counter·read snapshot="Section·appendix_Stirling-numbers"></RT·counter·read>).
</p>
- <RT·math>
- a_i = \sum_{n=i}^{\omega} \frac{s(n,i)}{n!} D_{0,n}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·polynomial-constant_from_differences">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·polynomial-constant_from_differences"></RT·counter·snapshot>
+ <RT·math>
+ a_i = \sum_{n=i}^{\omega} \frac{s(n,i)}{n!} D_{0,n}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·polynomial-constant_from_differences"></RT·counter·read> <RT·name>A polynomial constant recovered using signed Stirling numbers of the first kind</RT·name>
+ </RT·counter·step>
<p>
Thus, extending this procedure <RT·math>\omega</RT·math> times definitively recovers the constants for exactly a polynomial of degree <RT·math>\omega</RT·math>.
This mechanical recovery of standard polynomial constants is completely analogous to Newton's interpolation formula <RT·endnote>Ibid.</RT·endnote>. Instead of resolving the standard constants <RT·math>a_i</RT·math> through an upper triangular matrix, a person can construct the polynomial directly by treating the initial tape components as the exact coefficients for a basis of binomial terms:
</p>
- <RT·math>
- f(t) = \sum_{n=0}^{\omega} D_{0, n} \binom{t}{n}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·polynomial_from_initial-tape">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·polynomial_from_initial-tape"></RT·counter·snapshot>
+ <RT·math>
+ f(t) = \sum_{n=0}^{\omega} D_{0, n} \binom{t}{n}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·polynomial_from_initial-tape"></RT·counter·read> <RT·name>The polynomial built directly on a basis of binomial terms</RT·name>
+ </RT·counter·step>
<p>
Because the <RT·math>n</RT·math>th binomial coefficient expands into a polynomial of exactly degree <RT·math>n</RT·math>, and the summation is bounded by the finite extent <RT·math>\omega</RT·math> where <RT·math>D_{0, \omega}</RT·math> is definitively nonzero, the constructed function <RT·math>f(t)</RT·math> is structurally guaranteed to be a polynomial of degree <RT·math>\omega</RT·math>.
Here is the table of finite differences for the function <RT·math>2^t</RT·math>.
</p>
- <table>
- <thead>
- <tr>
- <th>Count (<RT·math>t</RT·math>)</th>
- <th><RT·math>f(t) = 2^t</RT·math></th>
- <th>1st Diff (<RT·math>δ^1</RT·math>)</th>
- <th>2nd Diff (<RT·math>δ^2</RT·math>)</th>
- <th>3rd Diff (<RT·math>δ^3</RT·math>)</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>0</td>
- <td>1</td>
- <td>1</td>
- <td>1</td>
- <td>1</td>
- </tr>
- <tr>
- <td>1</td>
- <td>2</td>
- <td>2</td>
- <td>2</td>
- <td>2</td>
- </tr>
- <tr>
- <td>2</td>
- <td>4</td>
- <td>4</td>
- <td>4</td>
- <td></td>
- </tr>
- <tr>
- <td>3</td>
- <td>8</td>
- <td>8</td>
- <td></td>
- <td></td>
- </tr>
- <tr>
- <td>4</td>
- <td>16</td>
- <td></td>
- <td></td>
- <td></td>
- </tr>
- </tbody>
- </table>
-
- <p>
- The first difference of <RT·math>2^t</RT·math> is also <RT·math>2^t</RT·math>, so row 0 of the table will have an infinite number of values. Fortunately, due to the lemma stating that evaluating call <RT·math>\omega</RT·math> requires an initial tape populated with components 0 through <RT·math>\omega</RT·math> of row 0, exactly those components are needed for the recurrence to proceed. Furthermore, when new values are needed, they are easily computed. A programmer need not store the entire infinite first row of the difference table on a static tape.
+ <RT·counter·step counter="RT·Table·counter" id="Table·difference-table_for_2-to-the-t">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·difference-table_for_2-to-the-t"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <thead>
+ <tr>
+ <th>Count (<RT·math>t</RT·math>)</th>
+ <th><RT·math>f(t) = 2^t</RT·math></th>
+ <th>1st Diff (<RT·math>δ^1</RT·math>)</th>
+ <th>2nd Diff (<RT·math>δ^2</RT·math>)</th>
+ <th>3rd Diff (<RT·math>δ^3</RT·math>)</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>0</td>
+ <td>1</td>
+ <td>1</td>
+ <td>1</td>
+ <td>1</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>2</td>
+ <td>2</td>
+ <td>2</td>
+ <td>2</td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>4</td>
+ <td>4</td>
+ <td>4</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td>8</td>
+ <td>8</td>
+ <td></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>16</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·difference-table_for_2-to-the-t"></RT·counter·read>. <RT·name>The forward difference table for f(t) = 2ᵗ</RT·name>
+ </RT·counter·step>
+
+ <p>
+ The first difference of <RT·math>2^t</RT·math> is also <RT·math>2^t</RT·math>, so row 0 of the table will have an infinite number of values. Fortunately, due to the lemma of section <RT·counter·read snapshot="Section·lemma_evaluating-call"></RT·counter·read>, stating that evaluating call <RT·math>\omega</RT·math> requires an initial tape populated with components 0 through <RT·math>\omega</RT·math> of row 0, exactly those components are needed for the recurrence to proceed. Furthermore, when new values are needed, they are easily computed. A programmer need not store the entire infinite first row of the difference table on a static tape.
</p>
<p>
Now suppose we want to express the quotient of these two functions.
</p>
- <RT·math>
- h(t) = \frac{f(t)}{g(t)} = \frac{2^t - 32}{3t - 15}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·quotient_definition">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·quotient_definition"></RT·counter·snapshot>
+ <RT·math>
+ h(t) = \frac{f(t)}{g(t)} = \frac{2^t - 32}{3t - 15}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·quotient_definition"></RT·counter·read> <RT·name>The quotient h(t), carrying a pole and a zero at t = 5</RT·name>
+ </RT·counter·step>
- <img src="singularity_plot.png" class="RT·diagram" alt="Figure singularity plot">
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·singularity_plot">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·singularity_plot"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="singularity_plot.png" class="RT·diagram" alt="Figure singularity plot">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·singularity_plot"></RT·counter·read>. <RT·name>The quotient h(t) plotted across the singularity at t = 5</RT·name>
+ </RT·counter·step>
<p>
Suppose we move to a second order evaluation, and for places the computation does not work, we return the machine that isn't evaluating. That is similar to what we did to get <RT·code>(divide 0 0)</RT·code>, but the zeros in that expression came from a prior step first order evaluation. Let us instead give the quotient composer two machines to compose, and have it return a value when reduction to the first order is possible, and return the full problem as posed to it when it can not be reduced.
</p>
- <table>
- <thead>
- <tr>
- <th>Count (<RT·math>t</RT·math>)</th>
- <th>Quotient (<RT·math>f(t)/g(t)</RT·math>)</th>
- <th>1st Diff Ratio (<RT·math>δ^1 f(t) / δ^1 g(t)</RT·math>)</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>0</td>
- <td>31/15</td>
- <td>1/3</td>
- <td></td>
- </tr>
- <tr>
- <td>1</td>
- <td>30/12</td>
- <td>2/3</td>
- <td></td>
- </tr>
- <tr>
- <td>2</td>
- <td>28/9</td>
- <td>4/3</td>
- <td></td>
- </tr>
- <tr>
- <td>3</td>
- <td>24/6</td>
- <td>8/3</td>
- <td></td>
- </tr>
- <tr>
- <td>4</td>
- <td>16/3</td>
- <td>16/3</td>
- <td></td>
- </tr>
- <tr>
- <td>5</td>
- <td><RT·code>(divide f(5) g(5))</RT·code></td>
- <td>32/3</td>
- <td></td>
- </tr>
- <tr>
- <td>6</td>
- <td>32/3</td>
- <td>64/3</td>
- <td></td>
- </tr>
- <tr>
- <td>7</td>
- <td>96/6</td>
- <td>128/3</td>
- <td></td>
- </tr>
- <tr>
- <td>8</td>
- <td>224/9</td>
- <td>256/3</td>
- <td></td>
- </tr>
- <tr>
- <td>9</td>
- <td>480/12</td>
- <td>512/3</td>
- <td></td>
- </tr>
- </tbody>
- </table>
+ <RT·counter·step counter="RT·Table·counter" id="Table·quotient_difference-ratios">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·quotient_difference-ratios"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <thead>
+ <tr>
+ <th>Count (<RT·math>t</RT·math>)</th>
+ <th>Quotient (<RT·math>f(t)/g(t)</RT·math>)</th>
+ <th>1st Diff Ratio (<RT·math>δ^1 f(t) / δ^1 g(t)</RT·math>)</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>0</td>
+ <td>31/15</td>
+ <td>1/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>30/12</td>
+ <td>2/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>28/9</td>
+ <td>4/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td>24/6</td>
+ <td>8/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>16/3</td>
+ <td>16/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>5</td>
+ <td><RT·code>(divide f(5) g(5))</RT·code></td>
+ <td>32/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>6</td>
+ <td>32/3</td>
+ <td>64/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>7</td>
+ <td>96/6</td>
+ <td>128/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>224/9</td>
+ <td>256/3</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>9</td>
+ <td>480/12</td>
+ <td>512/3</td>
+ <td></td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·quotient_difference-ratios"></RT·counter·read>. <RT·name>The quotient and the ratio of first differences through the singularity</RT·name>
+ </RT·counter·step>
<p>
The quotient machine, <RT·code>(divide f(5) g(5))</RT·code>, is no more representative of the value we expected here, than was <RT·code>(divide 0 0)</RT·code>. However, as we have the whole program, we could pass it to a L'Hôpital evaluator and get a value back. But I am wondering if we can't design function extension form that extends to the value and beyond without any hiccups, as most apparently there is a value to extend to.
</p>
<p>
- I included the first difference along with the evaluation results in the table above. When building a first difference table an interesting thing happens at the singularity, the first difference and the function itself coincide, note calls 4 and 5. This makes sense because <RT·math>δ f(4) = f(5) - f(4)</RT·math>, which becomes <RT·math>δ f(4) = 0 - f(4)</RT·math>, and the same happens to <RT·code>g</RT·code> in the denominator, so the signs cancel. Note also <RT·math>δ f(5) = f(6) - f(5)</RT·math>, which becomes <RT·math>δ f(5) = f(6) - 0</RT·math>.
+ I included the first difference along with the evaluation results in Table <RT·counter·read snapshot="Table·quotient_difference-ratios"></RT·counter·read>. When building a first difference table an interesting thing happens at the singularity, the first difference and the function itself coincide, note calls 4 and 5. This makes sense because <RT·math>δ f(4) = f(5) - f(4)</RT·math>, which becomes <RT·math>δ f(4) = 0 - f(4)</RT·math>, and the same happens to <RT·code>g</RT·code> in the denominator, so the signs cancel. Note also <RT·math>δ f(5) = f(6) - f(5)</RT·math>, which becomes <RT·math>δ f(5) = f(6) - 0</RT·math>.
</p>
<p>Ostensibly it looks like we have happened upon a discrete version of L'Hôpital's rule, that we merely use the first difference quotient instead of the function quotient at the singularity. But alas, the coincidence occurs at <RT·math>h(4)</RT·math> rather than at <RT·math>h(5)</RT·math>. For the second coincidence, we find <RT·math>h(6)</RT·math> as the 5th first finite difference. In neither case did we learn anything about the value of <RT·math>h(5)</RT·math>.
So then, perhaps we set the value at the singularity to <RT·math>x</RT·math> build out the difference table, then solve for <RT·math>x</RT·math>?
</p>
- <img src="with_x_variable.png" class="RT·diagram" alt="Figure with x variable.">
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·difference-table_with_x">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·difference-table_with_x"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="with_x_variable.png" class="RT·diagram" alt="Figure with x variable.">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·difference-table_with_x"></RT·counter·read>. <RT·name>The difference table with the singular value carried as the variable x</RT·name>
+ </RT·counter·step>
<p>
As Newton pointed out, we can know the differences on the <RT·math>D_0</RT·math> row of the table from the quotient function:
</p>
- <RT·math>
- D_{0,n} = \sum_{k=0}^n (-1)^{n-k} \binom{n}{k} \frac{f(k)}{g(k)}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·quotient_initial-differences">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·quotient_initial-differences"></RT·counter·snapshot>
+ <RT·math>
+ D_{0,n} = \sum_{k=0}^n (-1)^{n-k} \binom{n}{k} \frac{f(k)}{g(k)}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·quotient_initial-differences"></RT·counter·read> <RT·name>The initial differences of the quotient, taken from the function</RT·name>
+ </RT·counter·step>
<p>
For <RT·math>k=5</RT·math> the difference evaluates to be <RT·code>(divide 0 0)</RT·code>, as it did for the quotient, and it also fails for all values above <RT·math>k=5</RT·math> due to the summation. So we can not use this to solve for <RT·math>x</RT·math>.
The L'Hôpital evaluator will discover that a transcendental constant is required. It will be returned as a higher order object, a machine definition, because the value can not be written to the tape.
</p>
- <RT·math>
- T = \frac{32 \ln(2)}{3}
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·transcendental_constant">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·transcendental_constant"></RT·counter·snapshot>
+ <RT·math>
+ T = \frac{32 \ln(2)}{3}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·transcendental_constant"></RT·counter·read> <RT·name>The transcendental constant the quotient requires</RT·name>
+ </RT·counter·step>
<p>The resulting <RT·math>D_0</RT·math> vector for the quotient is:</p>
- <img src="D_10.png" class="RT·diagram" alt="Figure D_0 h(t)">
-
- <img src="h_of_t_D_table.png" class="RT·diagram" alt="Figure D table for h(t)">
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·D_0-vector_for-quotient">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·D_0-vector_for-quotient"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="D_10.png" class="RT·diagram" alt="Figure D_0 h(t)">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·D_0-vector_for-quotient"></RT·counter·read>. <RT·name>The D₀ vector for the quotient</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·difference-table_for_h">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·difference-table_for_h"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="h_of_t_D_table.png" class="RT·diagram" alt="Figure D table for h(t)">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·difference-table_for_h"></RT·counter·read>. <RT·name>The difference table for h(t)</RT·name>
+ </RT·counter·step>
<p>
I find it fascinating to watch the transcendental difference values march down the table, then all cancel out after <RT·math>h(5)</RT·math> is generated.
<p>And for the victory lap, evaluation versus higher order computation and function extension:</p>
- <table>
- <thead>
- <tr>
- <th>Count (<RT·math>t</RT·math>)</th>
- <th>Direct Evaluation (<RT·math>f(t)/g(t)</RT·math>)</th>
- <th>Extended Quotient Vector (<RT·math>H(t)</RT·math>)</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>0</td>
- <td>31/15</td>
- <td>31/15</td>
- </tr>
- <tr>
- <td>1</td>
- <td>30/12</td>
- <td>30/12</td>
- </tr>
- <tr>
- <td>2</td>
- <td>28/9</td>
- <td>28/9</td>
- </tr>
- <tr>
- <td>3</td>
- <td>24/6</td>
- <td>24/6</td>
- </tr>
- <tr>
- <td>4</td>
- <td>16/3</td>
- <td>16/3</td>
- </tr>
- <tr>
- <td>5</td>
- <td><RT·code>(divide 0 0)</RT·code></td>
- <td><RT·math>\frac{32 \ln(2)}{3}</RT·math></td>
- </tr>
- <tr>
- <td>6</td>
- <td>32/3</td>
- <td>32/3</td>
- </tr>
- <tr>
- <td>7</td>
- <td>96/6</td>
- <td>96/6</td>
- </tr>
- <tr>
- <td>8</td>
- <td>224/9</td>
- <td>224/9</td>
- </tr>
- <tr>
- <td>9</td>
- <td>480/12</td>
- <td>480/12</td>
- </tr>
- </tbody>
- </table>
+ <RT·counter·step counter="RT·Table·counter" id="Table·direct-evaluation_vs_extended-quotient">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·direct-evaluation_vs_extended-quotient"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <thead>
+ <tr>
+ <th>Count (<RT·math>t</RT·math>)</th>
+ <th>Direct Evaluation (<RT·math>f(t)/g(t)</RT·math>)</th>
+ <th>Extended Quotient Vector (<RT·math>H(t)</RT·math>)</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>0</td>
+ <td>31/15</td>
+ <td>31/15</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>30/12</td>
+ <td>30/12</td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>28/9</td>
+ <td>28/9</td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td>24/6</td>
+ <td>24/6</td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>16/3</td>
+ <td>16/3</td>
+ </tr>
+ <tr>
+ <td>5</td>
+ <td><RT·code>(divide 0 0)</RT·code></td>
+ <td><RT·math>\frac{32 \ln(2)}{3}</RT·math></td>
+ </tr>
+ <tr>
+ <td>6</td>
+ <td>32/3</td>
+ <td>32/3</td>
+ </tr>
+ <tr>
+ <td>7</td>
+ <td>96/6</td>
+ <td>96/6</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>224/9</td>
+ <td>224/9</td>
+ </tr>
+ <tr>
+ <td>9</td>
+ <td>480/12</td>
+ <td>480/12</td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·direct-evaluation_vs_extended-quotient"></RT·counter·read>. <RT·name>Direct evaluation of f(t)/g(t) against the extended quotient vector H(t)</RT·name>
+ </RT·counter·step>
</RT·section>
<p>The fundamental claim of computational analysis is that all functions can be viewed as discrete entities. Take this simple function:</p>
- <RT·code>
- f(t) = t^3
- </RT·code>
+ <RT·counter·step counter="RT·Code·counter" id="Code·cubic_function">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·cubic_function"></RT·counter·snapshot>
+ <RT·code>
+ f(t) = t^3
+ </RT·code>
+ Code <RT·counter·read snapshot="Code·cubic_function"></RT·counter·read>. <RT·name>A simple cubic function</RT·name>
+ </RT·counter·step>
<p>It is said to be a continuous function over the real field. However, from a computational perspective, it is a string of 8 discrete symbols. A person might ask then, "If the function is not continuous, then how can a person take a derivative?" Often people view a derivative as a tangent line to a curve drawn on a plot. The computational analyst's answer is to use a machine that manipulates the symbols; it will move the 3 down in front of the <RT·math>t</RT·math>, decrement the power, and write 2. Those are all discrete operations.</p>
<RT·name>Does computation theory matter to computing?</RT·name>
<p>
- Let us put this into perspective. Suppose in ancient Roman times that a clock tick for a computer was scaled to be one day long. Under this scale, a single nanosecond of real world execution time equates to three days. Suppose a program initiated a read request for a location in memory on the Ides of March, the date when Caesar was assassinated on 0043-03-15. The following table provides the historical date that the variable value would finally be loaded into the processor, depending on the memory tier being accessed:
- </p>
-
- <table>
- <thead>
- <tr>
- <th>Memory Tier</th>
- <th>Real World Latency</th>
- <th>Scaled Delay</th>
- <th>Scaled Arrival Era</th>
- <th>Historical Context</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>L1 Cache Hit</td>
- <td>1 ns</td>
- <td>3 days</td>
- <td>-0043-03-18</td>
- <td>Three days after the assassination.</td>
- </tr>
- <tr>
- <td>DRAM (Main memory)</td>
- <td>100 ns</td>
- <td>300 days</td>
- <td>-0042-01-09</td>
- <td>Nearly a year later, during the Liberators' civil war.</td>
- </tr>
- <tr>
- <td>NVMe SSD Page Swap</td>
- <td>15 µs</td>
- <td>45,000 days</td>
- <td>0080</td>
- <td>123 years later, exactly as the Colosseum is completed in Rome.</td>
- </tr>
- <tr>
- <td>SATA SSD Page Swap</td>
- <td>100 µs</td>
- <td>300,000 days</td>
- <td>0778</td>
- <td>821 years later, during the reign of Charlemagne and the Frankish Empire.</td>
- </tr>
- <tr>
- <td>Magnetic HDD Page Swap</td>
- <td>10 ms</td>
- <td>30,000,000 days</td>
- <td>82092</td>
- <td>Tens of thousands of years in the future, long after current human civilizations are dust.</td>
- </tr>
- </tbody>
- </table>
+ Let us put this into perspective. Suppose in ancient Roman times that a clock tick for a computer was scaled to be one day long. Under this scale, a single nanosecond of real world execution time equates to three days. Suppose a program initiated a read request for a location in memory on the Ides of March, the date when Caesar was assassinated on 0043-03-15. Table <RT·counter·read snapshot="Table·memory-tier_scaled-latency_appendix"></RT·counter·read> provides the historical date that the variable value would finally be loaded into the processor, depending on the memory tier being accessed:
+ </p>
+
+ <RT·counter·step counter="RT·Table·counter" id="Table·memory-tier_scaled-latency_appendix">
+ <RT·counter·snapshot counter="RT·Table·counter" snapshot="Table·memory-tier_scaled-latency_appendix"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <table>
+ <thead>
+ <tr>
+ <th>Memory Tier</th>
+ <th>Real World Latency</th>
+ <th>Scaled Delay</th>
+ <th>Scaled Arrival Era</th>
+ <th>Historical Context</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>L1 Cache Hit</td>
+ <td>1 ns</td>
+ <td>3 days</td>
+ <td>-0043-03-18</td>
+ <td>Three days after the assassination.</td>
+ </tr>
+ <tr>
+ <td>DRAM (Main memory)</td>
+ <td>100 ns</td>
+ <td>300 days</td>
+ <td>-0042-01-09</td>
+ <td>Nearly a year later, during the Liberators' civil war.</td>
+ </tr>
+ <tr>
+ <td>NVMe SSD Page Swap</td>
+ <td>15 µs</td>
+ <td>45,000 days</td>
+ <td>0080</td>
+ <td>123 years later, exactly as the Colosseum is completed in Rome.</td>
+ </tr>
+ <tr>
+ <td>SATA SSD Page Swap</td>
+ <td>100 µs</td>
+ <td>300,000 days</td>
+ <td>0778</td>
+ <td>821 years later, during the reign of Charlemagne and the Frankish Empire.</td>
+ </tr>
+ <tr>
+ <td>Magnetic HDD Page Swap</td>
+ <td>10 ms</td>
+ <td>30,000,000 days</td>
+ <td>82092</td>
+ <td>Tens of thousands of years in the future, long after current human civilizations are dust.</td>
+ </tr>
+ </tbody>
+ </table>
+ Table <RT·counter·read snapshot="Table·memory-tier_scaled-latency_appendix"></RT·counter·read>. <RT·name>Memory tier latency, scaled so that one clock tick lasts one day</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
<RT·name>Do formal methods belong in computer design?</RT·name>
- <p>
- The latency table above speaks to the physical reality that constrains all programs, entirely independent of their theoretical complexity class. This illustrates why computer architects spend almost their entire effort designing machines that execute as many instructions per cycle as possible, operating within a memory subsystem mathematically optimized to keep data in the lowest latency tiers. As a demonstration of this industry focus, there is not a single chapter dedicated to computation theory in Hennessy and Patterson's definitive textbook on the subject <RT·endnote>John L. Hennessy and David A. Patterson, <em>Computer Architecture: A Quantitative Approach</em>, 6th ed. (Cambridge: Morgan Kaufmann, 2017).</RT·endnote>.
- </p>
- <table>
- <tbody>
- <tr>
- <td>Chapter 1</td>
- <td>Fundamentals of Quantitative Design and Analysis</td>
- </tr>
- <tr>
- <td>Chapter 2</td>
- <td>Memory Hierarchy Design</td>
- </tr>
- <tr>
- <td>Chapter 3</td>
- <td>Instruction Level Parallelism and Its Exploitation</td>
- </tr>
- <tr>
- <td>Chapter 4</td>
- <td>Data Level Parallelism in Vector, SIMD, and GPU Architectures</td>
- </tr>
- <tr>
- <td>Chapter 5</td>
- <td>Thread Level Parallelism</td>
- </tr>
- <tr>
- <td>Chapter 6</td>
- <td>Warehouse Scale Computers</td>
- </tr>
- <tr>
- <td>Chapter 7</td>
- <td>Domain Specific Architectures</td>
- </tr>
- <tr>
- <td>Chapter 8</td>
- <td>The Future of Computing</td>
- </tr>
- </tbody>
- </table>
<p>
Professor Gonzalez once observed that the primary purpose of computer architecture is to execute the customer's programs as rapidly as possible. IBM later amended this philosophy to add 'for what they paid for,' famously designing a computer model where performance was artificially restricted unless the customer paid to have a physical hardware jumper removed. Within this prevailing design philosophy, the graceful handling of computational end cases, where most formal theoretical questions arise, is deemed secondary because such cases do not occur frequently in the critical execution path.
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section>
- <RT·name>Or, does it go the other way? Computational Naturalism</RT·name>
+ <RT·section id="Section·computational-naturalism">
+ <RT·name>Computational Naturalism: the transforms are reversible</RT·name>
<p>
Given that we have an architectural definition for a Turing Machine, and will modify this in a later chapter to define a realizable Turing Complete architecture, it is possible to invert the foundation of mathematics. Instead of mathematics preceding computation, we posit that given a Turing Machine exists, all of mathematics is an interpretation of what can be done with it.
</p>
<p>
- We then define the symbol in computational terms, as done in the prior section. This begins with memory addresses, represented as charge arrays, acting as primitive symbols, and extends to the symbol factory, copy operations, and instance comparison.
+ We then define the symbol in computational terms, as done in section <RT·counter·read snapshot="Section·symbol_in-computing"></RT·counter·read>. This begins with memory addresses, represented as charge arrays, acting as primitive symbols, and extends to the symbol factory, copy operations, and instance comparison.
</p>
<p>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section>
+ <RT·section id="Section·appendix_Stirling-numbers">
<RT·name>Appendix: Stirling Numbers</RT·name>
<p>
However, in the calculus of finite differences, standard exponents are clumsy. Because the Turing Machine evaluates discrete jumps, the natural basis is the falling factorial, denoted as <RT·math>t^{\underline{n}}</RT·math>:
</p>
- <RT·math>
- t^{\underline{n}} = t(t - 1)(t - 2) ⋯ (t - n + 1)
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·falling-factorial_definition">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·falling-factorial_definition"></RT·counter·snapshot>
+ <RT·math>
+ t^{\underline{n}} = t(t - 1)(t - 2) ⋯ (t - n + 1)
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·falling-factorial_definition"></RT·counter·read> <RT·name>The falling factorial, the natural basis for discrete differences</RT·name>
+ </RT·counter·step>
<p>
When a person applies the discrete forward difference operator, <RT·math>δ</RT·math>, to a falling factorial, it behaves identically to the continuous derivative: <RT·math>δ(t^{\underline{n}}) = n t^{\underline{n - 1}}</RT·math>.
The signed Stirling numbers of the first kind perform the exact inverse operation. They reconstruct standard continuous powers from falling factorials:
</p>
- <RT·math>
- t^{\underline{n}} = \sum_{k=0}^n s(n,k) t^k
- </RT·math>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·falling-factorial_in_powers">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·falling-factorial_in_powers"></RT·counter·snapshot>
+ <RT·math>
+ t^{\underline{n}} = \sum_{k=0}^n s(n,k) t^k
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·falling-factorial_in_powers"></RT·counter·read> <RT·name>The falling factorial expanded over standard powers</RT·name>
+ </RT·counter·step>
<p>
Combinatorially, the unsigned magnitude of <RT·math>s(n,k)</RT·math> represents the number of ways to arrange <RT·math>n</RT·math> items into <RT·math>k</RT·math> disjoint cycles. The alternating signs account for the algebraic expansion of the falling factorial terms <RT·math>(t - 1)(t - 2)</RT·math>, etc.
projects / TM-2026 / commitdiff
