copyright="2026 Reasoning Technology">
</RT·title>
+
<RT·TOC level="1-2"></RT·TOC>
<!--------------------------------------------------------------------------------->
- <RT·section id="Section·terminology">
- <RT·name>Nomenclature</RT·name>
+ <RT·section id="Section·acknowledgment">
+ <RT·name>Acknowledgment</RT·name>
- <p>All communication is founded upon common knowledge, so here are some notes on the conventions used in this book.</p>
+ <p>This RT Iterator library work was sponsored by Reasoning Technology Inc. They have been kind enough to allow the library to be made public under an MIT license and placed on GitHub.</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 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>This text was written separately, and was only possible due to the support of my loving wife Shihju.</p>
+ </RT·section>
- <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 the other words that appear in RFC 2119 to be capitalized so as to dodge the grammar debate.</p>
+ <!--------------------------------------------------------------------------------->
+ <RT·section id="Section·nomenclature">
+ <RT·name>Nomenclature</RT·name>
- <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>
+ <p>All communication is founded upon common knowledge, so here are some notes on the conventions used in this book.</p>
- <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>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>Multi-level enclosures receive a single space of padding only on the outermost boundary:</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>
- <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>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 number.</p>
- <p>Furthermore, identifier naming leverages both hyphens and underscores, when available, to establish semantic binding precedence. An example of this is:</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>
- <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>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>
- <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>
+ <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>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>Multi-level enclosures receive a single space of padding only on the outermost boundary:</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·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>
- Several words in this book carry a formal definition that distinguishes them from their ordinary English counterparts, so they are capitalized: <RT·term>Natural Number</RT·term>, <RT·term>Integer</RT·term>, <RT·term>Rational</RT·term>, <RT·term>Real</RT·term>. The word <em>real</em> is the perhaps the best example of why this is done. It was too much of an ask by mathematics to remove it common English or to explicitly disambiguate it. Hence, 'Real' is the object mathematics defines, and 'real' is the ordinary English word. Integer suffers no such ambiguity, but it is capitalized for consistency with its siblings.
- </p>
+ <p>Identifier naming leverages both hyphens and underscores, when available, to establish semantic binding precedence. An example of this is:</p>
- <p>
- Natural Numbers begin at zero, while Counting Numbers begin at one. The word Natural in front of Natural Number is overloaded. Counting Numbers are also <em>Natural</em> according to the thesis of this book, as are Rationals and even Reals. Enlightenment era thinkers did not carry it that far. So 'Natural Number' is a number as defined as Peano
+ <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>In this coding culture, we say that argument values are <em>given</em> to a function. Functions do not <em>take</em> arguments, as it is the caller that has authority over making the call, and thus over sending the arguments. A function is only said to <em>accept</em> or <em>reject</em> a value in the context of guard code evaluating argument validity, something it has authority to do. Similarly, machines, factories, and software <em>make</em> objects by assembling components they are given; they do not <em>create</em> them, since bringing components into being is not within an engineer's authority. That leaves 'creation' to imply a more fundamental synthesis outside the scope of engineering, perhaps done by artists or supernatural beings.</p>
-In a book with the thesis that all number types stem from a Naturalism interpretation, all numbers are Natural. Note also that the Natural of Natural Number is inherited from mathematics and has nothing to do with the Naturalism this book argues from. Every number kind here is arrived at naturalistically, the Integers and the Rationals and the Reals along with the Naturals, so Natural Number should not be read as naming the naturalistic one. It names what a Peano machine outputs.
- </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>. As per the standard, if the day is not to be specified it is simply dropped, e.g. <RT·code>2026-06</RT·code>.</p>
<p>
- In this book, a Natural Number is what a Peano machine outputs. An Integer, a Rational, and a Real are likewise the outputs of machines, each constructed in its turn. Because these name machines, and because this book capitalizes the names of machines, as in Turing Machine and TTCA Machine, they are capitalized here as well. The lower case forms are reserved for the ordinary mathematical notions and for the fixed-width values a contemporary architecture provides. So a reader will find the natural numbers of arithmetic, the real field, and the 32 bit integer of a conventional processor in lower case, while the machines this work constructs, and the values they produce, are in upper case.
+ Several words in this book carry a formal definition that displaces their ordinary English sense, and those are capitalized: <RT·term>Peano Number</RT·term>, <RT·term>Integer</RT·term>, <RT·term>Rational</RT·term>, <RT·term>Real</RT·term>. The word <em>real</em> is the best example of why this is done. It was too much of an ask by mathematics to take a common English adjective and hold it to a technical meaning, and a reader is entitled to know which sense is in play. So a Real is the object mathematics defines, and a real problem or a real difficulty is the ordinary English word. Integer suffers no such ambiguity. It is capitalized for consistency with its siblings.
+ </p>
+ <p>
+ The leading capital letter on the mathematical number types does not distinguish the classical notion from the one constructed herein, because this book denies that the two are distinct in the first place. A Real is a Real whether a mathematician defines it or a machine produces the definition.
+ </p>
+ <p>
+ What mathematics calls the natural numbers are called <RT·term>Peano Numbers</RT·term> in this book. A Peano Number is what a Peano Machine outputs. This convention frees the word 'Natural' to refer to the philosophy only, so a reader never has to work out which of the two is meant. Note that herein Peano Numbers are taken to begin at zero, while <RT·term>Counting Numbers</RT·term> begin at one, and the two are not the same.<RT·endnote>Peano's own axioms began at one. Modern presentations of Peano arithmetic begin at zero, and that is the convention followed here. Giuseppe Peano, <em>Arithmetices principia, nova methodo exposita</em> (Turin: Bocca, 1889), §1.</RT·endnote> An Integer, a Rational, and a Real are likewise the outputs of machines, each constructed in its turn.
+ </p>
+
+
+ <p>This book discusses four theoretical computing machines: two kinds of Turing Machine, which are not realizable, and two kinds of <RT·term>RT Machine</RT·term>, which are.</p>
+
+ <p>The first kind of <RT·term>Turing Machine</RT·term> has a fixed controller, and that controller determines the machine's behavior. Colloquially, a person could say that the program it runs is built-in. There can be many instances of this kind, each with a different built-in program, which is why the term Turing Machine is sometimes used in the sense of a computer program, and is sometimes plural. The program of such a machine cannot be changed, though the same input tape can be mounted on another Turing Machine having a different controller.</p>
+ <p>The second kind is the <RT·term>Universal Turing Machine</RT·term>, which reads its program from its tape. Each tape then gives the machine its own personality, so the built-in controller of a Universal Turing Machine is an interpreter. There is no reason there could not be several Universal Turing Machines, each with a different interpreter for reading the program from the tape. Hence, where this text speaks of a Turing Machine reading a program from a tape, it refers to a Universal Turing Machine; and where it speaks of a program, it refers to data that, when written to a tape, could be executed by a Universal Turing Machine.</p>
-The distinction is not decoration. A Natural Number is arrived at by construction and carries its derivation with it, whereas an integer is stipulated by an architecture and carries a width. The two cases also mark a distance this book intends to close. Lower case names a notion as the tradition hands it to us, upper case names the same notion as constructed here, and the argument of the later chapters is that the tradition's notion was a machine's output all along.
- </p>
+ <p>The <RT·term>RT Machine</RT·term> is a variation on the Turing Machine, and it comes in the same two kinds: one with a built-in controller, and one that reads its program from the tape. Unlike the Turing Machine, the RT Machine belongs to a class of realizable machines.</p>
</RT·section>
<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 can only point him at Mitch Alsup's book, and ponder how I can 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 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 RT 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>A Natural Number is a computational structure, as described by Peano. It starts with emptiness, a zero, and is then built up by repeated application of the successor function. Because a number is a computational structure, number theory was already computation theory before Church, Turing, and their contemporaries gave the subject its name. It is a computation theory whose discussion is confined to the relationships among Peano structures, which is to say, to Natural Numbers. Then the activity of writing algorithms and designing circuits that relate those structures to one another, in the service of solving real problems, is applied number theory.</p>
+ <p>A Peano Number is a computational structure, as its name records. It starts with emptiness, a zero, and is then built up by repeated application of the successor function. Because a number is a computational structure, number theory was already computation theory before Church, Turing, and their contemporaries gave the subject its name. It is a computation theory whose discussion is confined to the relationships among Peano structures, which is to say, to Peano Numbers. Then the activity of writing algorithms and designing circuits that relate those structures to one another, in the service of solving real problems, is applied number theory.</p>
- </RT·section>
+ </RT·section>
<!--------------------------------------------------------------------------------->
<RT·section id="Section·introduction">
<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>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 Natural 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>
<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. 1 (Jena: Hermann Pohle, 1893), §20.</RT·endnote>.
- </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. 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>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>
+ 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>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 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>
+ 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.
- </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.
+ </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>S</RT·math>, the first term of the set comprehension rule, <RT·math>x ∈ S</RT·math>, is false, and the paradox vanishes.
- </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>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 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>
+ 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 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>
+ 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, 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>
+ 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, <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>
+ 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>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>
+ 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 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>
+ 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 <RT·term-em>analyzer</RT·term-em> program can universally decide whether a second <RT·term-em>analyzed program</RT·term-em> will halt when it is run <RT·endnote>Ibid.</RT·endnote>. An answer to this <RT·term>halting problem</RT·term> (specifically asserting "The analyzed machine halts" or "The analyzed 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>
+ 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 <RT·term-em>analyzer</RT·term-em> program can universally decide whether a second <RT·term-em>analyzed program</RT·term-em> will halt when it is run <RT·endnote>Ibid.</RT·endnote>. An answer to this <RT·term>halting problem</RT·term> (specifically asserting "The analyzed machine halts" or "The analyzed 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>
- <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>
+ 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·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 ){
+ <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>
+ }
+ </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>
+ 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 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>
+ 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 Peano 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>.
- </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>.
+ </p>
</RT·section>
<RT·name>The Turing Machine transforms mathematics into computing</RT·name>
<p>
- To apply his proof to the Entscheidungsproblem, Turing carried the additional burden of establishing that Hilbert and Ackermann's intuitive concept of an effective <RT·term>procedure</RT·term> was functionally equivalent to a Turing Machine program. Alonzo Church had made an identification of this kind some months earlier
- <RT·endnote>Alonzo Church, "An Unsolvable Problem of Elementary Number Theory," <em>American Journal of Mathematics</em> 58, no. 2 (April 1936): 345–363, the identification at 356. A preliminary statement was presented to the American Mathematical Society on 1935-04-19. The name 'Church's thesis' is due to Kleene. Church first framed the identification in terms of his own λ-definability. Gödel told him that this was thoroughly unsatisfactory, and Church restated it in terms of Herbrand-Gödel general recursiveness, which is the form that reached print. The exchange survives in a letter from Church to Kleene of 1935-11-29, quoted in Stephen C. Kleene, "Origins of Recursive Function Theory," <em>Annals of the History of Computing</em> 3, no. 1 (1981): 52–67, at 59.</RT·endnote>,
- and there was some controversy over his proposal. Turing then provided his naturalist argument, based on what a person does when he computes with pencil and paper. This made the explanation more intuitive, and it resolved the controversy
- <RT·endnote>Church himself conceded that the 'Turing machine' explanation had the advantage of "making the identification with effectiveness in the ordinary (not explicitly defined) sense evident immediately", without preliminary theorems. Alonzo Church, review of A. M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem," <em>The Journal of Symbolic Logic</em> 2, no. 1 (March 1937): 42–43. It runs two pages, and is the clearest short statement of the difference, made by the man who stood to lose by it. Gödel, who had rejected Church's proposal, came to the same view, remarking to Hao Wang that the sharp concept of a mechanical procedure was not perceived before Turing, who brought us to the right perspective; Hao Wang, <em>From Mathematics to Philosophy</em> (London: Routledge and Kegan Paul, 1974), 85. How far Gödel ever accepted the thesis in Church's own form is disputed; see Martin Davis, "Why Gödel Didn't Have Church's Thesis," <em>Information and Control</em> 54 (1982): 3–24.</RT·endnote>.
+ To apply his proof to the Entscheidungsproblem, Turing carried the additional burden of establishing that Hilbert and Ackermann's intuitive concept of an effective <RT·term>procedure</RT·term> was functionally equivalent to a Turing Machine program. Alonzo Church had made an identification of this kind some months earlier
+ <RT·endnote>Alonzo Church, "An Unsolvable Problem of Elementary Number Theory," <em>American Journal of Mathematics</em> 58, no. 2 (April 1936): 345–363, the identification at 356. A preliminary statement was presented to the American Mathematical Society on 1935-04-19. The name 'Church's thesis' is due to Kleene. Church first framed the identification in terms of his own λ-definability. Gödel told him that this was thoroughly unsatisfactory, and Church restated it in terms of Herbrand-Gödel general recursiveness, which is the form that reached print. The exchange survives in a letter from Church to Kleene of 1935-11-29, quoted in Stephen C. Kleene, "Origins of Recursive Function Theory," <em>Annals of the History of Computing</em> 3, no. 1 (1981): 52–67, at 59.</RT·endnote>,
+ and there was some controversy over his proposal. Turing then provided his naturalist argument, based on what a person does when he computes with pencil and paper. This made the explanation more intuitive, and it resolved the controversy
+ <RT·endnote>Church himself conceded that the 'Turing machine' explanation had the advantage of "making the identification with effectiveness in the ordinary (not explicitly defined) sense evident immediately", without preliminary theorems. Alonzo Church, review of A. M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem," <em>The Journal of Symbolic Logic</em> 2, no. 1 (March 1937): 42–43. It runs two pages, and is the clearest short statement of the difference, made by the man who stood to lose by it. Gödel, who had rejected Church's proposal, came to the same view, remarking to Hao Wang that the sharp concept of a mechanical procedure was not perceived before Turing, who brought us to the right perspective; Hao Wang, <em>From Mathematics to Philosophy</em> (London: Routledge and Kegan Paul, 1974), 85. How far Gödel ever accepted the thesis in Church's own form is disputed; see Martin Davis, "Why Gödel Didn't Have Church's Thesis," <em>Information and Control</em> 54 (1982): 3–24.</RT·endnote>.
</p>
- <p>
- Over the following decades, the academic community evaluated and accepted the argument, cementing what is now known as the <RT·term>Church-Turing Thesis</RT·term>. This consensus supplied the necessary bridge between mathematics and modern computer science by formally equating the vague, historical notion of a human procedure with the rigorous, mechanical definition of an <RT·term>algorithm</RT·term>.
- </p>
+ Over the following decades, the academic community evaluated and accepted the argument, cementing what is now known as the <RT·term>Church-Turing Thesis</RT·term>. This consensus supplied the necessary bridge between mathematics and modern computer science by formally equating the vague, historical notion of a human procedure with the rigorous, mechanical definition of an <RT·term>algorithm</RT·term>.
+ </p>
- <p>
- For Turing's purposes working on the Entscheidungsproblem, establishing functional equivalence between algorithms and Turing Machine programs was sufficient. However, when the Turing Machine serves as a foundational model for computation theory, we are led to ask another question: whether the Turing Machine is representative of modern architectures, and to the extent it differs, how this would affect the applicability of computation theoretic results. That question occupies the remainder of this chapter, and the answer arrived at is that neither side is quite fit to be compared to the other as it stands.
- </p>
+ For Turing's purposes working on the Entscheidungsproblem, establishing functional equivalence between algorithms and Turing Machine programs was sufficient. However, when the Turing Machine serves as a foundational model for computation theory, we are led to ask another question: whether the Turing Machine is representative of modern architectures, and to the extent it differs, how this would affect the applicability of computation theoretic results. That question occupies the remainder of this chapter, and the answer arrived at is that neither side is quite fit to be compared to the other as it stands.
+ </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 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 Analytical Engine, first described in 1837, 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>
+ 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 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 Analytical Engine, first described in 1837, 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>
- Also of interest, Turing restricted the figures printed by his <RT·term>a-machine</RT·term> to 0 and 1, so that the sequences it computes are binary. George Boole's work (1847, 1854) was well established by then, so from a theoretical standpoint, it was a sensible simplification. However, utilizing binary within the context of a machine description effectively bridged the gap to the more practically minded engineers of the time. Alan Turing's paper arrived at the same time that switched telephone networks had reached a scale that made them difficult to maintain without systematic approaches. These networks were built upon electromechanical relays, which were decisively binary devices. At least seven men in addition to Alan Turing appear to have independently contemplated the intersection of Boolean algebra, logic, and physical computing: Victor Shestakov (1935, proposed mapping Boolean algebra to electromechanical relay circuits), Konrad Zuse (1936, adopted base 2 architecture to bypass the physical complexity of decimal mechanical gears), Akira Nakashima (1936, published the mathematical equivalence of Boolean algebra and two-terminal switching networks), Louis Couffignal (1936, argued calculating machines must shift to binary linkages to reduce physical friction), Claude Shannon (1937, published the definitive mathematical proof mapping Boolean algebra to electrical relays), George Stibitz (1937, constructed the first electromechanical binary adder), and John Vincent Atanasoff (1937, adopted binary to keep the vacuum-tube count of electronic circuits physically viable).
- </p>
+ Also of interest, Turing restricted the figures printed by his <RT·term>a-machine</RT·term> to 0 and 1, so that the sequences it computes are binary. George Boole's work (1847, 1854) was well established by then, so from a theoretical standpoint, it was a sensible simplification. However, utilizing binary within the context of a machine description effectively bridged the gap to the more practically minded engineers of the time. Alan Turing's paper arrived at the same time that switched telephone networks had reached a scale that made them difficult to maintain without systematic approaches. These networks were built upon electromechanical relays, which were decisively binary devices. At least seven men in addition to Alan Turing appear to have independently contemplated the intersection of Boolean algebra, logic, and physical computing: Victor Shestakov (1935, proposed mapping Boolean algebra to electromechanical relay circuits), Konrad Zuse (1936, adopted base 2 architecture to bypass the physical complexity of decimal mechanical gears), Akira Nakashima (1936, published the mathematical equivalence of Boolean algebra and two-terminal switching networks), Louis Couffignal (1936, argued calculating machines must shift to binary linkages to reduce physical friction), Claude Shannon (1937, published the definitive mathematical proof mapping Boolean algebra to electrical relays), George Stibitz (1937, constructed the first electromechanical binary adder), and John Vincent Atanasoff (1937, adopted binary to keep the vacuum-tube count of electronic circuits physically viable).
+ </p>
- <p>
- Before asking whether a given architecture measures up to the Turing Machine, we need to say what measuring up would consist of. Like a Turing Machine, a computer architecture is an abstraction. The box sitting on a person's desk is a realization of some computer architecture. To say a Turing Machine does something is to say that the Turing Machine was analyzed and the result of the analysis is that 'something'. A computer architecture can also be analyzed. A computer architecture is said to be <RT·term>Turing Complete</RT·term> when, through analysis, it is determined that it can do anything that a Turing Machine can do. The practical implication for a realization of such an architecture is that running a program will fault only because a) the program logic told it to, b) the program has a flaw, or c) there is a mathematical fact standing in the way of execution. A shortage of a physical resource is not a fourth reason, provided the architecture can pause a program until a 'more memory' request is fulfilled, because that shortage is a limit of the realization and not of the architecture. However, if the architecture itself stipulates a bound that a program can reach, such as a fixed address width or a fixed Integer width, then every realization of it must fail on some program that a Turing Machine would carry to completion, and the architecture is not Turing Complete.
- </p>
+ Before asking whether a given architecture measures up to the Turing Machine, we need to say what measuring up would consist of. Like a Turing Machine, a computer architecture is an abstraction. The box sitting on a person's desk is a realization of some computer architecture. To say a Turing Machine does something is to say that the Turing Machine was analyzed and the result of the analysis is that 'something'. A computer architecture can also be analyzed. A computer architecture is said to be <RT·term>Turing Complete</RT·term> when, through analysis, it is determined that it can do anything that a Turing Machine can do. The practical implication for a realization of such an architecture is that running a program will fault only because a) the program logic told it to, b) the program has a flaw, or c) there is a mathematical fact standing in the way of execution. A shortage of a physical resource is not a fourth reason, provided the architecture can pause a program until a 'more memory' request is fulfilled, because that shortage is a limit of the realization and not of the architecture. However, if the architecture itself stipulates a bound that a program can reach, such as a fixed address width or a fixed Integer width, then every realization of it must fail on some program that a Turing Machine would carry to completion, and the architecture is not Turing Complete.
+ </p>
- <p>
- With that criterion in hand, consider the infinite tape, which is not as large a hurdle as it might seem at first. For computational problems, the Turing Machine halts in a finite number of steps. Because the Turing Machine is limited to stepping the read/write head over one cell per machine execution step, only a finite amount of tape is ever used. But for a given computation, how much tape is that? Resolving this by assuming more tape is simply attached when needed is analogous to cheating in a 'guess the bigger number' game by declaring, "My number is always one bigger than the given number, so I will tell you my guess after you state your number." Some mathematicians suggest that what is meant by infinity is precisely a rule of this sort. For engineers building physical hardware, however, to state that a resource starts finite and expands incrementally over time is a very different proposition from being asked to install infinite memory on a machine in the first place.
- </p>
+ With that criterion in hand, consider the infinite tape, which is not as large a hurdle as it might seem at first. For computational problems, the Turing Machine halts in a finite number of steps. Because the Turing Machine is limited to stepping the read/write head over one cell per machine execution step, only a finite amount of tape is ever used. But for a given computation, how much tape is that? Resolving this by assuming more tape is simply attached when needed is analogous to cheating in a 'guess the bigger number' game by declaring, "My number is always one bigger than the given number, so I will tell you my guess after you state your number." Some mathematicians suggest that what is meant by infinity is precisely a rule of this sort. For engineers building physical hardware, however, to state that a resource starts finite and expands incrementally over time is a very different proposition from being asked to install infinite memory on a machine in the first place.
+ </p>
- <p>
- In 1967, Marvin Minsky addressed this very topic, saying: "We need not think of the machine's tape as infinite. We imagine instead that the machine begins with a finite tape, but that, whenever an end is encountered, another unit of tape is attached." <RT·endnote>Marvin L. Minsky, <em>Computation: Finite and Infinite Machines</em> (Englewood Cliffs: Prentice-Hall, 1967), 167.</RT·endnote> In 1967, this was a perfectly natural thing to suggest, as computers utilized magnetic tape memory on manually mounted reels, and it was entirely possible for a computation to stop and request a new reel of tape to be mounted. Contemporary computer architectures do, in fact, achieve a similar effect through virtual memory. When physical RAM is depleted, the operating system pauses the active process and autonomously provisions apparent capacity by swapping memory pages out to auxiliary storage. So the graceful expansion Minsky described is already in place, and it works, right up until a stipulated bound is reached. Once the available swap space is exhausted or the address space is saturated, the operating system abruptly terminates the process.
- </p>
+ In 1967, Marvin Minsky addressed this very topic, saying: "We need not think of the machine's tape as infinite. We imagine instead that the machine begins with a finite tape, but that, whenever an end is encountered, another unit of tape is attached." <RT·endnote>Marvin L. Minsky, <em>Computation: Finite and Infinite Machines</em> (Englewood Cliffs: Prentice-Hall, 1967), 167.</RT·endnote> In 1967, this was a perfectly natural thing to suggest, as computers utilized magnetic tape memory on manually mounted reels, and it was entirely possible for a computation to stop and request a new reel of tape to be mounted. Contemporary computer architectures do, in fact, achieve a similar effect through virtual memory. When physical RAM is depleted, the operating system pauses the active process and autonomously provisions apparent capacity by swapping memory pages out to auxiliary storage. So the graceful expansion Minsky described is already in place, and it works, right up until a stipulated bound is reached. Once the available swap space is exhausted or the address space is saturated, the operating system abruptly terminates the process.
+ </p>
- <p>
- Notice where the failure actually sits. Expanding the memory available to a process is handled, and handled well. What is missing is the ability to continue rather than to terminate, and supplying that is software's work, much as Python supplies Integers of arbitrary range over a machine whose Integers are of fixed width. The difference is one of motive. Python's arbitrary range Integers are a convenience offered to the programmer, whereas here the software would be compensating for a bound the architecture imposed. This is the shape of the whole problem in miniature: an architecture is made to look complete by software written to work around it, rather than being complete by virtue of its own instructions.
- </p>
+ Notice where the failure actually sits. Expanding the memory available to a process is handled, and handled well. What is missing is the ability to continue rather than to terminate, and supplying that is software's work, much as Python supplies Integers of arbitrary range over a machine whose Integers are of fixed width. The difference is one of motive. Python's arbitrary range Integers are a convenience offered to the programmer, whereas here the software would be compensating for a bound the architecture imposed. This is the shape of the whole problem in miniature: an architecture is made to look complete by software written to work around it, rather than being complete by virtue of its own instructions.
+ </p>
- <p>
- The Turing Machine does not escape criticism either, and its defect is the more serious of the two. Its head must read and react at every step, and the only place a controller has to hold what it has seen is a branch in its own control path. So the Turing Machine uses its controller as memory. When we come to analyze a machine that reverses a string, we will find the consequence: the number of states and arcs required grows exponentially against the width of a machine word, and for a word of any practical size the controller cannot be built at all. A machine room operator can mount another reel of tape. Nobody can mount a larger controller, because the controller is finite by definition. The tape's limit was handed outside the machine and dealt with there. The controller's limit is sealed inside the model, where nothing can reach it.
- </p>
+ The Turing Machine does not escape criticism either, and its defect is the more serious of the two. Its head must read and react at every step, and the only place a controller has to hold what it has seen is a branch in its own control path. So the Turing Machine uses its controller as memory. When we come to analyze a machine that reverses a string, we will find the consequence: the number of states and arcs required grows exponentially against the width of a machine word, and for a word of any practical size the controller cannot be built at all. A machine room operator can mount another reel of tape. Nobody can mount a larger controller, because the controller is finite by definition. The tape's limit was handed outside the machine and dealt with there. The controller's limit is sealed inside the model, where nothing can reach it.
+ </p>
- <p>
- To complete the Turing Machine story, then, we will transform the Turing Machine into a modern architecture in a stepwise fashion, while ensuring that at each step the modifications are inconsequential to computation theoretic existence proofs and complexity class results. The transformation does not run in one direction only. On the Turing Machine side, the controller has to stop being used as memory. On the modern side, the fixed widths an architecture stipulates, of an address and of an Integer, are what have to give way. The two meet in the middle, and the machine we arrive at is less strange than that might suggest. It separates the control path from the data path, it holds an instruction table, and it has a small register file. It looks modern. The differences from what we currently build are real but few, and the point of the exercise is that we could build it.
- </p>
+ To complete the Turing Machine story, then, we will transform the Turing Machine into a modern architecture in a stepwise fashion, while ensuring that at each step the modifications are inconsequential to computation theoretic existence proofs and complexity class results. The transformation does not run in one direction only. On the Turing Machine side, the controller has to stop being used as memory. On the modern side, the fixed widths an architecture stipulates, of an address and of an Integer, are what have to give way. The two meet in the middle, and the machine we arrive at is less strange than that might suggest. It separates the control path from the data path, it holds an instruction table, and it has a small register file. It looks modern. The differences from what we currently build are real but few, and the point of the exercise is that we could build it.
+ </p>
</RT·section>
<RT·section>
<RT·name>The six levels</RT·name>
- <p>
- These are the discernible levels of the computer design abstraction stack:
- </p>
-
- <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-em>mathematical logic</RT·term-em></li>
- <li><RT·term-em>computation theory</RT·term-em></li>
- <li><RT·term-em>architecture</RT·term-em></li>
- <li><RT·term-em>organization</RT·term-em></li>
- <li><RT·term-em>implementation</RT·term-em></li>
- <li><RT·term-em>realization</RT·term-em></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>
- <RT·term>Mathematical logic</RT·term> underpins the computation theory level. <RT·term>Computation theory</RT·term> 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 levels.
- </p>
-
- <p>
- An <RT·term>architecture</RT·term> provides programmers with information that is valuable when designing the logic of programs. This includes programmers across the entire software stack, such as firmware engineers, driver developers, systems programmers, compiler writers, and application developers, although application programs might only be exposed to the <RT·term>virtual architecture</RT·term> presented by the standards, the libraries, and the programming language in use. Beyond specifying the instructions, which is the instruction set architecture, an architecture describes the memory and hardware virtualization features, the behavior of the interrupt subsystem, the method of doing I/O, DMA, the special registers and their effects, any architectural buses, and the standards to be followed for each, if any. More recently, this also includes specifying how programs can make use of secure areas. The architecture is specified by an <RT·term>architect</RT·term>.
- </p>
-
- <p>
- The classic text by Hamacher, Vranesic, and Zaky carefully defines the organizational level as sitting between architecture and implementation <RT·endnote>V. Carl Hamacher, Zvonko G. Vranesic, and Safwat G. Zaky, <em>Computer Organization</em>, 5th ed. (New York: McGraw-Hill, 2002).</RT·endnote>.
- <RT·term>Organization</RT·term> is the register-transfer level description of the machine, which includes internal buses, external buses and the state machines that implement the protocols used, control units, interrupt structures, and ALU layout. Crucially, it is at this level that decisions regarding instruction-level parallelism are made, such as whether the processor will employ a scalar, superscalar, or VLIW design, the depth of its execution pipelines, the use of out-of-order execution, branch prediction strategies, and the specific hierarchy of hardware caches. It dictates the logical arrangement of hardware and the procedures that force the data to flow to satisfy the architectural constraints. Organization is sometimes called <RT·term>microarchitecture</RT·term>, and it is made by a <RT·term>design architect</RT·term>.
- </p>
-
- <p>
- It is not a requirement of a computer organization, nor of 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>
- The <RT·term>implementation</RT·term> instructs the manufacturing teams very specifically on what is to be built. For a microprocessor chip, this consists of the full wiring of the logic gates and transistors, instructions for cutting the lithography masks, the package to be used, and the production test programs to be run. The instructions for cutting the masks consist of the sizes and placement of doping wells and gates, the placement of contacts, and where to run wires. The implementation is designed by <RT·term>design engineers</RT·term>, with the assistance of design synthesis tools and CAD tools.
- </p>
-
- <p>
- A <RT·term>realization</RT·term> is a physical box full of plastic, metal, fiberglass, and silicon, along with a smattering of exotic materials. A realization is made by <RT·term>manufacturing engineers</RT·term>, <RT·term>technicians</RT·term>, and <RT·term>product line workers</RT·term>, with the assistance of some of the most sophisticated machines ever built by humankind.
- </p>
-
- <p>
- If a computer manufacturer keeps the architecture constant, all other levels can change, and a customer will be able to run the same software. The same organization can be used with different implementations. Minor changes in the manufacturing process can sometimes be used with an older implementation, for example a simple transistor shrink.
- </p>
+ These are the discernible levels of the computer design abstraction stack:
+ </p>
+
+ <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>
+ <li><RT·term-em>mathematical logic</RT·term-em></li>
+ <li><RT·term-em>computation theory</RT·term-em></li>
+ <li><RT·term-em>architecture</RT·term-em></li>
+ <li><RT·term-em>organization</RT·term-em></li>
+ <li><RT·term-em>implementation</RT·term-em></li>
+ <li><RT·term-em>realization</RT·term-em></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>
+
+ <RT·term>Mathematical logic</RT·term> underpins the computation theory level. <RT·term>Computation theory</RT·term> 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 levels.
+ </p>
+
+ An <RT·term>architecture</RT·term> provides programmers with information that is valuable when designing the logic of programs. This includes programmers across the entire software stack, such as firmware engineers, driver developers, systems programmers, compiler writers, and application developers, although application programs might only be exposed to the <RT·term>virtual architecture</RT·term> presented by the standards, the libraries, and the programming language in use. Beyond specifying the instructions, which is the instruction set architecture, an architecture describes the memory and hardware virtualization features, the behavior of the interrupt subsystem, the method of doing I/O, DMA, the special registers and their effects, any architectural buses, and the standards to be followed for each, if any. More recently, this also includes specifying how programs can make use of secure areas. The architecture is specified by an <RT·term>architect</RT·term>.
+ </p>
+
+ The classic text by Hamacher, Vranesic, and Zaky carefully defines the organizational level as sitting between architecture and implementation <RT·endnote>V. Carl Hamacher, Zvonko G. Vranesic, and Safwat G. Zaky, <em>Computer Organization</em>, 5th ed. (New York: McGraw-Hill, 2002).</RT·endnote>.
+ <RT·term>Organization</RT·term> is the register-transfer level description of the machine, which includes internal buses, external buses and the state machines that implement the protocols used, control units, interrupt structures, and ALU layout. Crucially, it is at this level that decisions regarding instruction-level parallelism are made, such as whether the processor will employ a scalar, superscalar, or VLIW design, the depth of its execution pipelines, the use of out-of-order execution, branch prediction strategies, and the specific hierarchy of hardware caches. It dictates the logical arrangement of hardware and the procedures that force the data to flow to satisfy the architectural constraints. Organization is sometimes called <RT·term>microarchitecture</RT·term>, and it is made by a <RT·term>design architect</RT·term>.
+ </p>
+
+ It is not a requirement of a computer organization, nor of an architecture, that it be capable of physical realization. The abstract Turing Machine organization developed in chapter <RT·counter·read snapshot="Section·RT_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>
+
+ The <RT·term>implementation</RT·term> instructs the manufacturing teams very specifically on what is to be built. For a microprocessor chip, this consists of the full wiring of the logic gates and transistors, instructions for cutting the lithography masks, the package to be used, and the production test programs to be run. The instructions for cutting the masks consist of the sizes and placement of doping wells and gates, the placement of contacts, and where to run wires. The implementation is designed by <RT·term>design engineers</RT·term>, with the assistance of design synthesis tools and CAD tools.
+ </p>
+
+ A <RT·term>realization</RT·term> is a physical box full of plastic, metal, fiberglass, and silicon, along with a smattering of exotic materials. A realization is made by <RT·term>manufacturing engineers</RT·term>, <RT·term>technicians</RT·term>, and <RT·term>product line workers</RT·term>, with the assistance of some of the most sophisticated machines ever built by humankind.
+ </p>
+
+ If a computer manufacturer keeps the architecture constant, all other levels can change, and a customer will be able to run the same software. The same organization can be used with different implementations. Minor changes in the manufacturing process can sometimes be used with an older implementation, for example a simple transistor shrink.
+ </p>
</RT·section>
<RT·section>
<RT·name>The levels are not independent</RT·name>
- <p>
- The levels are merely idealizations. In both practice and theory it is not possible to completely disentangle them. On a new machine of the same architecture, it is common that some software will require updates to run, and almost certainly specific operating system support will be required.
- </p>
+ The levels are merely idealizations. In both practice and theory it is not possible to completely disentangle them. On a new machine of the same architecture, it is common that some software will require updates to run, and almost certainly specific operating system support will be required.
+ </p>
- <p>
- An architect almost always has a reference organization in mind. Design architects work with design engineers to know what is practical, and design engineers work with manufacturing engineers to know what can be built.
- </p>
+ An architect almost always has a reference organization in mind. Design architects work with design engineers to know what is practical, and design engineers work with manufacturing engineers to know what can be built.
+ </p>
- <p>
- The common understanding of the word 'architecture' is what Hamacher, Vranesic, and Zaky call an 'organization'. For example, even the most experienced of architects will say things like a microprocessor has a "superscalar architecture", though whether a processor is scalar or superscalar is clearly a question of computer organization.
- </p>
+ The common understanding of the word 'architecture' is what Hamacher, Vranesic, and Zaky call an 'organization'. For example, even the most experienced of architects will say things like a microprocessor has a "superscalar architecture", though whether a processor is scalar or superscalar is clearly a question of computer organization.
+ </p>
- <p>
- In fact, architecture instructs organization. The fact there is an instruction set already means that there will be instruction fetch, and thus an instruction bus. Furthermore the load data has to come from somewhere, so there will be data fetch and data bus. Could both be the same bus? If not, then we have a "Harvard Architecture". The fact is, almost no one involved in computer design completely divorces architecture from organization.
- </p>
+ In fact, architecture instructs organization. The fact there is an instruction set already means that there will be instruction fetch, and thus an instruction bus. Furthermore the load data has to come from somewhere, so there will be data fetch and data bus. Could both be the same bus? If not, then we have a "Harvard Architecture". The fact is, almost no one involved in computer design completely divorces architecture from organization.
+ </p>
- <p>
- This cascades down the stack, as organization instructs implementation, and implementation instructs realization. For example, if the architecture has an instruction that names one of <RT·math>N</RT·math> registers as an operand, then the organization has a register file that data flows to and from, along with buses to carry that data. The implementation then specifies that register file and lays out those buses, and the manufacturing people build them.
- </p>
+ This cascades down the stack, as organization instructs implementation, and implementation instructs realization. For example, if the architecture has an instruction that names one of <RT·math>N</RT·math> registers as an operand, then the organization has a register file that data flows to and from, along with buses to carry that data. The implementation then specifies that register file and lays out those buses, and the manufacturing people build them.
+ </p>
</RT·section>
<RT·section>
<RT·name>Where the Turing Machine fits in</RT·name>
- <p>
- The Turing Machine is a computation theory object that is suggestive of a simple architecture, and a computer organization. A person who has had to do homework problems centered on Turing Machines will have tracked the flow of data through the machine, i.e. worked at the register-transfer level. However, a little work is needed to complete the architecture analog. The fundamentals are present: the read/write head, the tape, and the procedure for using the tape. Other things are missing, or are left unspecified:
- </p>
-
- <RT·counter·step counter="RT·List·counter" id="List·Turing-Machine_missing-components">
- <RT·counter·snapshot counter="RT·List·counter" snapshot="List·Turing-Machine_missing-components"></RT·counter·snapshot>
- <ol>
- <li>The manipulation of symbols remains ungrounded.</li>
- <li>The tape is not well defined.</li>
- <li>The use of emptiness is not architectural.</li>
- <li>The tape transport is not articulated, though it is implied.</li>
- <li>The read buffer is not identified as a component. One is required so that the programmed controller can do a write without clobbering the read data needed for the next transition.</li>
- </ol>
- List <RT·counter·read snapshot="List·Turing-Machine_missing-components"></RT·counter·read>. <RT·name>What the Turing Machine leaves out of its architecture</RT·name>
- </RT·counter·step>
-
- <p>
- As we proceed, we will likely discover other missing components.
- </p>
+ The Turing Machine is a computation theory object that is suggestive of a simple architecture, and a computer organization. A person who has had to do homework problems centered on Turing Machines will have tracked the flow of data through the machine, i.e. worked at the register-transfer level. However, a little work is needed to complete the architecture analog. The fundamentals are present: the read/write head, the tape, and the procedure for using the tape. Other things are missing, or are left unspecified:
+ </p>
+
+ <RT·counter·step counter="RT·List·counter" id="List·Turing-Machine_missing-components">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·Turing-Machine_missing-components"></RT·counter·snapshot>
+ <li>The manipulation of symbols remains ungrounded.</li>
+ <li>The tape is not well defined.</li>
+ <li>The use of emptiness is not architectural.</li>
+ <li>The tape transport is not articulated, though it is implied.</li>
+ <li>The read buffer is not identified as a component. One is required so that the programmed controller can do a write without clobbering the read data needed for the next transition.</li>
+ </ol>
+ List <RT·counter·read snapshot="List·Turing-Machine_missing-components"></RT·counter·read>. <RT·name>What the Turing Machine leaves out of its architecture</RT·name>
+ </RT·counter·step>
+
+ As we proceed, we will likely discover other missing components.
+ </p>
</RT·section>
</RT·section>
-
+
<!--------------------------------------------------------------------------------->
<RT·section>
<RT·name>Computation theoretic consequentiality</RT·name>
<RT·section>
<RT·name>The conventional Turing Machine</RT·name>
- <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·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>
-
- <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>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>
- <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>
+ <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>
+
+ <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>Here the <em>input</em> alphabet is said to be a subset of a larger alphabet. This allows some symbols to be set aside and only used by the machine. The symbols which are exclusive to the larger set are <RT·term>control symbols</RT·term>. <RT·term>control symbols</RT·term> symbols are distinguished by their use in describing the machine status rather than serving explicitly as input data. Hopcroft and Ullman include the empty symbol, □, as a control symbol. However, they have simultaneously listed it as a separate component.</p>
+
+ <p>State transitions are gated by the value read from the tape. Each state transition is bound to an action to be taken by the machine; hence, this Turing Machine definition describes a Mealy style state machine. Structurally, this action specifies two distinct instructions. First, it is mandatory that exactly one of the two-step instructions, <RT·code>left</RT·code> or <RT·code>right</RT·code>, be issued. Second, a <RT·code>write(σ)</RT·code> instruction must also be specified, though the written symbol can be the same symbol that is read, making the write operation effectively optional.</p>
+
+ <p>This machine makes use of a single-ended tape. If a computation specifies a two way infinite tape, it can be emulated by interleaving the addresses: assigning odd addressed cells to represent the right going half, and even addressed cells to represent the left going half. This emulation requires taking two steps instead of one to advance in a given logical direction, and to wrap motion at the dividing cell, and is otherwise undetectable. The transformation has a small constant effect at the dividing cell, and otherwise multiplies the step-count formula by two, which do not affect big O results. Hence, the single-ended tape machine is a computation theoretic inconsequential variation of the two way tape machine.
+ </p>
- <p>Here the <em>input</em> alphabet is said to be a subset of a larger alphabet. This allows some symbols to be set aside and only used by the machine. The symbols which are exclusive to the larger set are <RT·term>control symbols</RT·term>. <RT·term>control symbols</RT·term> symbols are distinguished by their use in describing the machine status rather than serving explicitly as input data. Hopcroft and Ullman include the empty symbol, □, as a control symbol. However, they have simultaneously listed it as a separate component.</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>
- <p>State transitions are gated by the value read from the tape. Each state transition is bound to an action to be taken by the machine; hence, this Turing Machine definition describes a Mealy style state machine. Structurally, this action specifies two distinct instructions. First, it is mandatory that exactly one of the two-step instructions, <RT·code>left</RT·code> or <RT·code>right</RT·code>, be issued. Second, a <RT·code>write(σ)</RT·code> instruction must also be specified, though the written symbol can be the same symbol that is read, making the write operation effectively optional.</p>
+ <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>This machine makes use of a single-ended tape. If a computation specifies a two way infinite tape, it can be emulated by interleaving the addresses: assigning odd addressed cells to represent the right going half, and even addressed cells to represent the left going half. This emulation requires taking two steps instead of one to advance in a given logical direction, and to wrap motion at the dividing cell, and is otherwise undetectable. The transformation has a small constant effect at the dividing cell, and otherwise multiplies the step-count formula by two, which do not affect big O results. Hence, the single-ended tape machine is a computation theoretic inconsequential variation of the two way tape machine.
- </p>
+ <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>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·section>
+ <RT·name>The reverse machine example</RT·name>
- <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>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>
- <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>
+ <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>
- <RT·section>
- <RT·name>The reverse machine example</RT·name>
+ <p>Provided the site is still alive, the following YAML can be entered at TuringMachine.io to watch the machine run.</p>
+
+ <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>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>
-
- <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·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·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>
+ <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·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>
<RT·section>
<RT·name>Analysis of the reverse machine</RT·name>
- <p>The total number of steps for reversing an <RT·math>n</RT·math> symbol string:</p>
-
- <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>Reversing a string does not intrinsically require making decisions based on the values in the string that is being reversed; however, a Turing Machine must use the value under the head for the next-state transitions. Also, the only memory a controller has is through adding control path branches, so to "carry the symbol right" requires a branch in the state controller per symbol to remember what the symbol is. Consequently, had the input alphabet been larger, this controller would have required proportionally more states, as noted on the diagram.</p>
-
- <p>For a realized 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·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·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 modern 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>
+
<p>The total number of steps for reversing an <RT·math>n</RT·math> symbol string:</p>
+
+ <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>Reversing a string does not intrinsically require making decisions based on the values in the string that is being reversed; however, a Turing Machine must use the value under the head for the next-state transitions. Also, the only memory a controller has is through adding control path branches, so to "carry the symbol right" requires a branch in the state controller per symbol to remember what the symbol is. Consequently, had the input alphabet been larger, this controller would have required proportionally more states, as noted on the diagram.</p>
+
+
<p>For a realized 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·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·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 modern 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 -->
+ <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>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>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>The abstract concept here is that of a container. A piece of paper is a container for symbols. When it contains no symbols, the container is empty. Only when we say the container is a piece of paper does it make sense to call it blank. But we are speaking of abstractions, not of paper. As a point of perspective, when computation theory texts are translated into French, the blank symbol is called the "symbole vide", or literally "empty symbol", as apparently blank paper is empty.
- </p>
+
<p>The abstract concept here is that of a container. A piece of paper is a container for symbols. When it contains no symbols, the container is empty. Only when we say the container is a piece of paper does it make sense to call it blank. But we are speaking of abstractions, not of paper. As a point of perspective, when computation theory texts are translated into French, the blank symbol is called the "symbole vide", or literally "empty symbol", as apparently blank paper is empty.
+ </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>
+
<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·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>
+ <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>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>A conventionally defined Turing Machine will break if reading a cell does not yield a symbol, because the next-state function has the read symbol as an argument.</p>
+
<p>A conventionally defined Turing Machine will break if reading a cell does not yield a symbol, because the next-state function has the read symbol as an argument.</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>
+
<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·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):
+ <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:
+ 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):
+ </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':
+ 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>
+ </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>
+
<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·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>
+ <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>For machine B, no modifications are required to the native <RT·code>read</RT·code> and <RT·code>write</RT·code> functions.</p>
- <p>It is possible to build a mapping between the machine A and machine B. The read and write operations are placed into correspondence. The empty set as a member of tape sequence of machine A is placed into correspondence with the <RT·code>empty</RT·code> symbol of machine B. The other components are defined identically, and map directly. This establishes an isomorphism between the two machines. Hence, they are equally expressive. However, machine B is simpler, so it is understandable that computer theoreticians have settled on this definition.</p>
+
<p>It is possible to build a mapping between the machine A and machine B. The read and write operations are placed into correspondence. The empty set as a member of tape sequence of machine A is placed into correspondence with the <RT·code>empty</RT·code> symbol of machine B. The other components are defined identically, and map directly. This establishes an isomorphism between the two machines. Hence, they are equally expressive. However, machine B is simpler, so it is understandable that computer theoreticians have settled on this definition.</p>
- <p>If we view the <RT·code>empty</RT·code> symbol from within the definition of machine B, it is a category error. It is a sequence element rather than a container. Even if it were allowed that a position within a sequence were a container and thus could have the property of being empty, the symbol represents that there is no symbol in the very location it is found. Hence, to ascribe an appropriate meaning to the <RT·code>empty</RT·code> symbol, the entire system must be kept including the mapping to machine A, then the empty symbol found on machine B means that if machine A were used instead, the same location in the tape sequence would be an empty set. However, this feels unsatisfactory, because in all other respects, machine B is a perfectly well-defined Turing Machine all by itself.</p>
+
<p>If we view the <RT·code>empty</RT·code> symbol from within the definition of machine B, it is a category error. It is a sequence element rather than a container. Even if it were allowed that a position within a sequence were a container and thus could have the property of being empty, the symbol represents that there is no symbol in the very location it is found. Hence, to ascribe an appropriate meaning to the <RT·code>empty</RT·code> symbol, the entire system must be kept including the mapping to machine A, then the empty symbol found on machine B means that if machine A were used instead, the same location in the tape sequence would be an empty set. However, this feels unsatisfactory, because in all other respects, machine B is a perfectly well-defined Turing Machine all by itself.</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>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>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 analyzed 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 analyzed. 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>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 analyzed 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 analyzed. 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 analyzed' 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>
+
<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 analyzed' 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>
- <p>Firstly note that excluding <RT·code>SP</RT·code> from <RT·math>Σ</RT·math> does not prevent a Turing Machine from writing <RT·code>SP</RT·code> to a tape to be used as a message. If a message writing machine wants to write an <RT·code>SP</RT·code> to the tape, it merely writes a different symbol then erases it.</p>
+
<p>Firstly note that excluding <RT·code>SP</RT·code> from <RT·math>Σ</RT·math> does not prevent a Turing Machine from writing <RT·code>SP</RT·code> to a tape to be used as a message. If a message writing machine wants to write an <RT·code>SP</RT·code> to the tape, it merely writes a different symbol then erases it.</p>
- <p>Secondly, once it is realized that <RT·code>SP</RT·code> symbols can be written to tape as messages, the very reason of excluding it from <RT·math>Γ</RT·math>, to guarantee that received messages are parsable, is lost. A message authoring machine could, for example, happily output a variable length array of strings while using an arbitrary number of empty symbols to separate the elements. A receiving machine could then not know how many elements it should try to recover, or when to say a string of <RT·code>SP</RT·code> symbols is sufficiently long to not be considered a separator. Nothing in the Turing Machine definition prevents this.</p>
+
<p>Secondly, once it is realized that <RT·code>SP</RT·code> symbols can be written to tape as messages, the very reason of excluding it from <RT·math>Γ</RT·math>, to guarantee that received messages are parsable, is lost. A message authoring machine could, for example, happily output a variable length array of strings while using an arbitrary number of empty symbols to separate the elements. A receiving machine could then not know how many elements it should try to recover, or when to say a string of <RT·code>SP</RT·code> symbols is sufficiently long to not be considered a separator. Nothing in the Turing Machine definition prevents this.</p>
- <p>Furthermore, the Universal Turing Machine can act as the aforementioned higher authority. In this case, Turing Machines, and sometimes their tapes, are written to a Universal Turing Machine's tape. Consequently, it is not only possible to want to terminate multiple strings in series, as mentioned in the prior paragraph; the termination issue itself is embedded in proofs such as the Halting Problem.</p>
+
<p>Furthermore, the Universal Turing Machine can act as the aforementioned higher authority. In this case, Turing Machines, and sometimes their tapes, are written to a Universal Turing Machine's tape. Consequently, it is not only possible to want to terminate multiple strings in series, as mentioned in the prior paragraph; the termination issue itself is embedded in proofs such as the Halting Problem.</p>
- <p>A common technique programmers use for embedding strings with terminators within other strings is to embed escape characters. This is another in-band protocol, and it is inefficient. The escape sequences grow exponentially with nesting levels. Also, such strings with embedded escape sequences cannot be interpreted without knowledge of the intended nesting level of the string author, which requires the interpreter of the string to know the author's intentions.</p>
+
<p>A common technique programmers use for embedding strings with terminators within other strings is to embed escape characters. This is another in-band protocol, and it is inefficient. The escape sequences grow exponentially with nesting levels. Also, such strings with embedded escape sequences cannot be interpreted without knowledge of the intended nesting level of the string author, which requires the interpreter of the string to know the author's intentions.</p>
- <p>For the modified computational Turing Machine presented later in this chapter, there will be a separate control alphabet of predefined symbols, as for the Hopcroft-Ullman interpretation. However, so as to support recursion, and because the current scheme does not achieve protocol guarantees, the predefined alphabet will be part of the alphabet <RT·math>Σ</RT·math> rather than distinct from it. Programmers then must explicitly design communication protocols that suit the problems they are working on, and those protocols become opaque for examination by a higher authority. Note that this does not preclude a programmer from using <RT·code>SP</RT·code> as an EOM marker, rather it removes the embedding of that protocol from the Turing Machine definition.</p>
+
<p>For the modified computational Turing Machine presented later in this chapter, there will be a separate control alphabet of predefined symbols, as for the Hopcroft-Ullman interpretation. However, so as to support recursion, and because the current scheme does not achieve protocol guarantees, the predefined alphabet will be part of the alphabet <RT·math>Σ</RT·math> rather than distinct from it. Programmers then must explicitly design communication protocols that suit the problems they are working on, and those protocols become opaque for examination by a higher authority. Note that this does not preclude a programmer from using <RT·code>SP</RT·code> as an EOM marker, rather it removes the embedding of that protocol from the Turing Machine definition.</p>
</RT·section>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section id="Section·TTCA_computation-theoretic">
- <RT·name>The computation theoretic TTCA Machine</RT·name>
+ <RT·section id="Section·RT_computation-theoretic">
+ <RT·name>The computation theoretic RT 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>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>
<RT·section>
<RT·name>The <RT·code>unspecified</RT·code> meta-symbol</RT·name>
- <p>In the first edition of this book, I introduced a "read-only after write" rule while working towards an architectural Turing Machine because conventional computer architectures do not maintain a concept of empty memory. The approach described in this section integrates the "read-only after write" into a computation theoretic machine by designing in the concept of being <em>unspecified</em>, which then displaces the concept of a cell being <em>empty</em>.</p>
+
<p>In the first edition of this book, I introduced a "read-only after write" rule while working towards an architectural Turing Machine because conventional computer architectures do not maintain a concept of empty memory. The approach described in this section integrates the "read-only after write" into a computation theoretic machine by designing in the concept of being <em>unspecified</em>, which then displaces the concept of a cell being <em>empty</em>.</p>
- <p>The standard 9-track tape introduced by IBM in 1964 came from the factory unformatted. The format operation would write a header and an EOF marker to mark the end of the device file. Then, a standard library call such as open(), followed by write(), would write over the EOF marker, continue writing data, and finally append a new EOF marker, effectively pushing the EOF boundary back. EOF could be pushed back until the physical EOT marker was struck. This matches, in some ways, how the empty symbol is used on the computation theoretic Turing Machine in the Hopcroft and Ullman book, if we consider it to be an EOF marker. However, a difference exists in that realized machines do not use an EOF to erase data characters.</p>
+
<p>The standard 9-track tape introduced by IBM in 1964 came from the factory unformatted. The format operation would write a header and an EOF marker to mark the end of the device file. Then, a standard library call such as open(), followed by write(), would write over the EOF marker, continue writing data, and finally append a new EOF marker, effectively pushing the EOF boundary back. EOF could be pushed back until the physical EOT marker was struck. This matches, in some ways, how the empty symbol is used on the computation theoretic Turing Machine in the Hopcroft and Ullman book, if we consider it to be an EOF marker. However, a difference exists in that realized machines do not use an EOF to erase data characters.</p>
- <p>While using the standard library to write tapes, the uninitialized part of the tape could not be read until after it was written, so early tape machines indeed enforced the "read-only after write" rule. However, if the programmer were to seek the head back into the device file to do fresh work and perform reads and writes, the device EOF would be nowhere in sight. The burden of the "read-only after write" rule would then fall on the shoulders of the programmer, as would the task of structuring the data.</p>
+
<p>While using the standard library to write tapes, the uninitialized part of the tape could not be read until after it was written, so early tape machines indeed enforced the "read-only after write" rule. However, if the programmer were to seek the head back into the device file to do fresh work and perform reads and writes, the device EOF would be nowhere in sight. The burden of the "read-only after write" rule would then fall on the shoulders of the programmer, as would the task of structuring the data.</p>
- <p>Core memory, and later system memory, was random access and initially fully accessible. The data would be whatever scrambled mess the machine booted with, or in early virtual memory systems, whatever was left over from the prior use of the page. The approach of recycling pages was a security hazard, so today a page is initially allocated from a read-only zero page, and due to a copy-on-write trap, a new page will be created in memory then the original page copied to it, thus scrubbing it with zeros. The zero pointer is in a sense an empty symbol, as an attempt to dereference it will cause a fault. However, on realized machines, there are many integer values used, and these can also be zero. Thus the zeros of the new page are not identical to saying the page contains all empty symbols. In this system, the programmer is again burdened with maintaining the "read-only after write" rule. Compilers and interpreters often help with this by attempting to detecting the use of uninitialized data and throwing an error.</p>
+
<p>Core memory, and later system memory, was random access and initially fully accessible. The data would be whatever scrambled mess the machine booted with, or in early virtual memory systems, whatever was left over from the prior use of the page. The approach of recycling pages was a security hazard, so today a page is initially allocated from a read-only zero page, and due to a copy-on-write trap, a new page will be created in memory then the original page copied to it, thus scrubbing it with zeros. The zero pointer is in a sense an empty symbol, as an attempt to dereference it will cause a fault. However, on realized machines, there are many integer values used, and these can also be zero. Thus the zeros of the new page are not identical to saying the page contains all empty symbols. In this system, the programmer is again burdened with maintaining the "read-only after write" rule. Compilers and interpreters often help with this by attempting to detecting the use of uninitialized data and throwing an error.</p>
- <p>A violation of "read-only after write" could be detected by a modified computation theoretic Turing Machine if, instead of an empty symbol, the initial tape is filled with the <RT·code>unspecified</RT·code> symbol. The end objective is to detect an erroneous condition, which is useful for debugging and testing. Conventionally, mathematicians do not concern themselves with the test and debug phases of programming a Turing Machine, but rather concern themselves with answering computation theoretic questions about known working Turing Machine programs. Though perhaps an algorithm could be analyzed for this very quality of not ever making decisions based on unspecified data. Nor do realized machines have an <RT·code>unspecified</RT·code> symbol; rather, a program reads garbage from memory locations with unspecified data. There is precedent for an <RT·code>x</RT·code>, <em>unknown</em>, logic state in hardware simulators.</p>
+
<p>A violation of "read-only after write" could be detected by a modified computation theoretic Turing Machine if, instead of an empty symbol, the initial tape is filled with the <RT·code>unspecified</RT·code> symbol. The end objective is to detect an erroneous condition, which is useful for debugging and testing. Conventionally, mathematicians do not concern themselves with the test and debug phases of programming a Turing Machine, but rather concern themselves with answering computation theoretic questions about known working Turing Machine programs. Though perhaps an algorithm could be analyzed for this very quality of not ever making decisions based on unspecified data. Nor do realized machines have an <RT·code>unspecified</RT·code> symbol; rather, a program reads garbage from memory locations with unspecified data. There is precedent for an <RT·code>x</RT·code>, <em>unknown</em>, logic state in hardware simulators.</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>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>
- <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.</li>
- </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>Reasons that memory can be <RT·code>unspecified</RT·code> include:</p>
+ <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>
+ <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.</li>
+ </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>
+
<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>
- <p>Recall the suggestion earlier in this section that "perhaps an algorithm could be analyzed for this very quality of not ever making decisions based on unspecified data." In this capacity, the <RT·code>unspecified</RT·code> symbol functions as a <RT·term>test probe</RT·term>. Such an analysis can be done with a two-layer architecture: a first-order machine under study and a second-order machine performing the analysis. The <RT·code>unspecified</RT·code> symbol resides within the alphabet of the second-order machine, which possesses the authority not only to move the symbol but also to base logic upon it. However, demoting the <RT·code>unspecified</RT·code> marker from a meta-symbol to a standard decision symbol leaves the second-order machine without a meta-symbol of its own. In a strictly layered architecture, analogous to Russell and Whitehead's hierarchy of types, a programmer could define <RT·code>unspecified-0</RT·code>, <RT·code>unspecified-1</RT·code>, and so forth, explicitly embedding the order as a unique identifier. However, if the system lacks this strict stratification, the layering strategy collapses. This occurs when a statement operates as an independent island of meaning, analogous to Gödel's unprovable truths, or when an analyzer is tasked with evaluating itself, as in Turing's halting proof. Therefore, whether an <RT·code>unspecified</RT·code> meta-symbol can be deployed successfully depends entirely upon the structural boundaries of the specific system under test.</p>
+
<p>Recall the suggestion earlier in this section that "perhaps an algorithm could be analyzed for this very quality of not ever making decisions based on unspecified data." In this capacity, the <RT·code>unspecified</RT·code> symbol functions as a <RT·term>test probe</RT·term>. Such an analysis can be done with a two-layer architecture: a first-order machine under study and a second-order machine performing the analysis. The <RT·code>unspecified</RT·code> symbol resides within the alphabet of the second-order machine, which possesses the authority not only to move the symbol but also to base logic upon it. However, demoting the <RT·code>unspecified</RT·code> marker from a meta-symbol to a standard decision symbol leaves the second-order machine without a meta-symbol of its own. In a strictly layered architecture, analogous to Russell and Whitehead's hierarchy of types, a programmer could define <RT·code>unspecified-0</RT·code>, <RT·code>unspecified-1</RT·code>, and so forth, explicitly embedding the order as a unique identifier. However, if the system lacks this strict stratification, the layering strategy collapses. This occurs when a statement operates as an independent island of meaning, analogous to Gödel's unprovable truths, or when an analyzer is tasked with evaluating itself, as in Turing's halting proof. Therefore, whether an <RT·code>unspecified</RT·code> meta-symbol can be deployed successfully depends entirely upon the structural boundaries of the specific system under test.</p>
</RT·section>
<RT·section>
<RT·name>The modifications</RT·name>
- <p>The specific architectural modifications are as follows:</p>
- <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>):
+ <p>The specific architectural modifications are as follows:</p>
+ <RT·counter·step counter="RT·List·counter" id="List·RT_modifications">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·RT_modifications"></RT·counter·snapshot>
<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>
+ <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>
- </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>
+ List <RT·counter·read snapshot="List·RT_modifications"></RT·counter·read>. <RT·name>The architectural modifications that distinguish the RT 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>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>
+
<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>
- <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>
- <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>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>
+ <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>
+ <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>
+
<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>
- <p>This approach of cascading next-state decisions does more than merely make the machine more convenient to program; it also enables a programmer to support an <RT·code>unspecified</RT·code> symbol. For example, a programmer can incorporate a first-order <RT·code>unspecified</RT·code> symbol by first adding it to the alphabet <RT·math>Σ</RT·math>, adding a <RT·code>Q_unspecified</RT·code> state to <RT·math>Q</RT·math>, and then adding a status default arc to <RT·math>Δ_2</RT·math> of <RT·math>\langle \mathtt{s{·}unspecified}, \mathit{Q\_unspecified} \rangle</RT·math>. Finally, the programmer adds <RT·code>Q_unspecified</RT·code> to the set of halting states. Then, if the machine attempts to make a decision upon the <RT·code>unspecified</RT·code> symbol, the machine will transition to the <RT·code>Q_unspecified</RT·code> state and halt. Such a machine can then be analyzed to see if it ever visits the <RT·code>Q_unspecified</RT·code> state, although the analyst must take care, because if he puts some thought into this, he will realize that no such universal analyzer can exist.</p>
+
<p>This approach of cascading next-state decisions does more than merely make the machine more convenient to program; it also enables a programmer to support an <RT·code>unspecified</RT·code> symbol. For example, a programmer can incorporate a first-order <RT·code>unspecified</RT·code> symbol by first adding it to the alphabet <RT·math>Σ</RT·math>, adding a <RT·code>Q_unspecified</RT·code> state to <RT·math>Q</RT·math>, and then adding a status default arc to <RT·math>Δ_2</RT·math> of <RT·math>\langle \mathtt{s{·}unspecified}, \mathit{Q\_unspecified} \rangle</RT·math>. Finally, the programmer adds <RT·code>Q_unspecified</RT·code> to the set of halting states. Then, if the machine attempts to make a decision upon the <RT·code>unspecified</RT·code> symbol, the machine will transition to the <RT·code>Q_unspecified</RT·code> state and halt. Such a machine can then be analyzed to see if it ever visits the <RT·code>Q_unspecified</RT·code> state, although the analyst must take care, because if he puts some thought into this, he will realize that no such universal analyzer can exist.</p>
- <p>The formal definition that follows will be partitioned according to the <em>separation of concerns</em>. The first section defines the fixed parts of the Turing Machine definition. The second section defines the memory elements (variables). The third section describes the programmable components, which vary between specific Turing Machines depending on their purposes.</p>
+
<p>The formal definition that follows will be partitioned according to the <em>separation of concerns</em>. The first section defines the fixed parts of the Turing Machine definition. The second section defines the memory elements (variables). The third section describes the programmable components, which vary between specific Turing Machines depending on their purposes.</p>
- <p>There is a mechanical procedure for converting a Moore Machine into a Mealy Machine, and the reverse. Two such converted machines are equally expressive. Making the read operation an explicit instruction, instead of having it implied by a state transition, increases the number of states in a controller, and consequently the number of steps that must be taken. However, the new machine can do in two steps anything the former machine could do in one; consequently, this change scales the step-count formula by a constant factor, leaving the order of the highest term unchanged. The layers of next-state functions can be collapsed into one layer, where the missing arguments are filled in with all possible unused values. This potentially increases the number of state transition arcs that must be specified, but the state transition logic and the number of states remain unchanged. Partitioning the machine definition by separation of concerns does not change the total specification. Hence, these modifications are computation theoretic inconsequential.</p>
+
<p>There is a mechanical procedure for converting a Moore Machine into a Mealy Machine, and the reverse. Two such converted machines are equally expressive. Making the read operation an explicit instruction, instead of having it implied by a state transition, increases the number of states in a controller, and consequently the number of steps that must be taken. However, the new machine can do in two steps anything the former machine could do in one; consequently, this change scales the step-count formula by a constant factor, leaving the order of the highest term unchanged. The layers of next-state functions can be collapsed into one layer, where the missing arguments are filled in with all possible unused values. This potentially increases the number of state transition arcs that must be specified, but the state transition logic and the number of states remain unchanged. Partitioning the machine definition by separation of concerns does not change the total specification. Hence, these modifications are computation theoretic inconsequential.</p>
</RT·section>
<RT·section>
- <RT·name>The TTCA Machine fixed part</RT·name>
-
- <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·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·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·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·name>The RT Machine fixed part</RT·name>
+
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_fixed-part">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_fixed-part"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{MF} = (\mathit{QF}, \mathit{ΣF}, \mathit{AF})
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_fixed-part"></RT·counter·read> <RT·name>MF, the fixed part of the RT 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·counter·step counter="RT·Equation·counter" id="Equation·RT_fixed-states">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_fixed-states"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{QF} = \{\mathit{QF}{·}\mathtt{initial}\}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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·counter·step counter="RT·Equation·counter" id="Equation·RT_fixed-instructions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_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·RT_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·counter·step counter="RT·Equation·counter" id="Equation·RT_fixed-symbols">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_fixed-symbols"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{ΣF} = \{\mathit{ΣF}{·}\mathtt{leftmost}, \mathit{ΣF}{·}\mathtt{rightmost}\}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_fixed-symbols"></RT·counter·read> <RT·name>ΣF, the set of predefined symbols</RT·name>
+ </RT·counter·step>
+
+ <p>
+ Note that the machine does not report having stepped off the end of the tape. There are no errors of the "you did it, shame on you" kind in this architecture. Instead the status register carries the cell type, and <RT·code>rightmost</RT·code> is one of the types it can carry. A controller that cannot prove it will stay on the tape must therefore consult the status before stepping right, and decide. Often the proof is available, in which case no test is needed and no cycles are spent on one. Where it is not available, the machine has told the program what it needs to know in advance rather than punished it afterwards. This is the same discipline applied to <RT·code>empty</RT·code> and to unspecified data, and it is what allows the fault taxonomy given earlier to hold: a program stops because its logic said to, because it has a flaw, or because a physical resource ran out and somebody must bring more. Walking off the end of the tape is not a fourth reason, because the machine gives the program the means to see the end coming.
+ </p>
+
</RT·section>
<RT·section>
<RT·name>Machine variables</RT·name>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_machine-variables">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_machine-variables"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{MV} = (q, s, d)
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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>
+
<p><RT·code>q</RT·code>: is the current state of the machine.</p>
- <p><RT·code>s</RT·code>: is the status register value, also called the <em>machine status</em>.</p>
+
<p><RT·code>s</RT·code>: is the status register value, also called the <em>machine status</em>.</p>
- <p><RT·code>d</RT·code>: is the data register value.</p>
+
<p><RT·code>d</RT·code>: is the data register value.</p>
</RT·section>
<RT·section>
<RT·name>Programmable part</RT·name>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_programmable-part">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_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·RT_programmable-part"></RT·counter·read> <RT·name>MP, the programmable part of the RT Machine</RT·name>
+ </RT·counter·step>
- <p>A set of programmed <em>state</em> symbols:</p>
+
<p>A set of programmed <em>state</em> symbols:</p>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_programmed-states">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_programmed-states"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{QP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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>
+
<p>A set of programmed data symbols:</p>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_programmed-symbols">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_programmed-symbols"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{ΣP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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·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>The programmed instructions. A set of pairs of the form:</p>
+
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_programmed-instructions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_programmed-instructions"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{ΛP} = \{ \langle q_i, a \rangle, \dots \}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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>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>
+
<p>The conditional transition table. A set of state transition triples; each triple is of the form:</p>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_conditional-transitions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_conditional-transitions"></RT·counter·snapshot>
+ <RT·math>
+ Δ_0 = \{ \langle q_i, σ, q_{i+1} \rangle, \dots \}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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>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>
+
<p>The state default transition table. A set of state transition pairs; each pair is of the form:</p>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_state-default-transitions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_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·RT_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>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>
+
<p>The status default transition table. A set of state transition pairs; each pair is of the form:</p>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_status-default-transitions">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_status-default-transitions"></RT·counter·snapshot>
+ <RT·math>
+ Δ_2 = \{ \langle σ, q_{i+1} \rangle, \dots \}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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>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>
+
<p>The global default next-state:</p>
- <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>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_global-default-transition">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_global-default-transition"></RT·counter·snapshot>
+ <RT·math>
+ Δ_3 = q_{i+1}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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>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>
+
<p>A set of programmer-defined halting states:</p>
- <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·counter·step counter="RT·Equation·counter" id="Equation·RT_halt-states">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_halt-states"></RT·counter·snapshot>
+ <RT·math>
+ \mathit{HP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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·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·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·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·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·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·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·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·name>The RT Machine definition in total</RT·name>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_machine_definition">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_machine_definition"></RT·counter·snapshot>
+ <RT·math>
+ M = (q, s, d, Q, Σ, A, Λ, Δ, H)
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_machine_definition"></RT·counter·read> <RT·name>The RT Machine in total</RT·name>
+ </RT·counter·step>
- </RT·section>
- <RT·section>
- <RT·name>Computation theoretic TTCA Machine executor</RT·name>
+ <p>The variables used by the executor, <RT·math>\mathit{MV} = (q, s, d)</RT·math>.</p>
- <p><em>Computer</em> was at one time a job title. Turing described a clerk following directions to cause his machine to go, thus implying that mathematicians are mere automata chained to following the procedures they derive. So then an executor can be a person, perhaps a student who is studying the computation theoretic machine, and has a homework assignment of showing what it does.</p>
+ <p>The complete set of states, uniting the fixed predefined states and the programmed states:</p>
- <p>The executor takes the TTCA machine through three stages of execution: initialization, programmed control, and halting. While going through these stages, the executor gives the <RT·math>\mathit{MV}</RT·math> variables values.</p>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_state-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_state-set"></RT·counter·snapshot>
+ <RT·math>
+ Q = \mathit{QF} \cup \mathit{QP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_state-set"></RT·counter·read> <RT·name>Q, the complete state set, fixed united with programmed</RT·name>
+ </RT·counter·step>
- <p>This description assumes support is programmed in for the first-order <RT·code>unspecified</RT·code> symbol.</p>
+ <p>The complete set of symbols, uniting the fixed control symbols and the programmed data symbols:</p>
- <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>
- <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·counter·step counter="RT·Equation·counter" id="Equation·RT_symbol-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_symbol-set"></RT·counter·snapshot>
+ <RT·math>
+ Σ = \mathit{ΣF} \cup \mathit{ΣP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_symbol-set"></RT·counter·read> <RT·name>Σ, the complete symbol set, fixed united with programmed</RT·name>
+ </RT·counter·step>
- </RT·section>
+ <p>All members of the set of available instructions are fixed:</p>
- <RT·section>
- <RT·name>Programmed control stage</RT·name>
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_instruction-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_instruction-set"></RT·counter·snapshot>
+ <RT·math>
+ A = \mathit{AF}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_instruction-set"></RT·counter·read> <RT·name>A, the instruction set, entirely fixed</RT·name>
+ </RT·counter·step>
- <RT·section>
- <RT·name>Phase 1: Instruction issue and execution</RT·name>
- <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>
+ <p>The table of state-instruction pairs is strictly programmed.</p>
+
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT_instruction-table">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_instruction-table"></RT·counter·snapshot>
+ <RT·math>
+ Λ = \mathit{ΛP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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·counter·step counter="RT·Equation·counter" id="Equation·RT_transition-sequence">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_transition-sequence"></RT·counter·snapshot>
+ <RT·math>
+ Δ = [Δ_0 \mid Δ_1 \mid Δ_2 \mid Δ_3]
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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·counter·step counter="RT·Equation·counter" id="Equation·RT_halt-set">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT_halt-set"></RT·counter·snapshot>
+ <RT·math>
+ H = \mathit{HP}
+ </RT·math>
+ eq: <RT·counter·read snapshot="Equation·RT_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>Computation theoretic RT Machine executor</RT·name>
+
+ <p><em>Computer</em> was at one time a job title. Turing described a clerk following directions to cause his machine to go, thus implying that mathematicians are mere automata chained to following the procedures they derive. So then an executor can be a person, perhaps a student who is studying the computation theoretic machine, and has a homework assignment of showing what it does.</p>
+
+ <p>The executor takes the RT Machine through three stages of execution: initialization, programmed control, and halting. While going through these stages, the executor gives the <RT·math>\mathit{MV}</RT·math> variables values.</p>
+
+ <p>This description assumes support is programmed in for the first-order <RT·code>unspecified</RT·code> symbol.</p>
+
+ <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>
+ <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>Programmed control stage</RT·name>
+
+ <RT·section>
+ <RT·name>Phase 1: Instruction issue and execution</RT·name>
+ <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>
<RT·section>
<RT·name>Phase 2: The state transition</RT·name>
- <p>Following the completion of the instruction, the programmed controller evaluates the next-state by cascading through the ordered sequence of transition rules <RT·math>Δ = [Δ_0 \mid Δ_1 \mid Δ_2 \mid Δ_3]</RT·math>. The evaluation follows this hierarchy, stopping and branching at the first valid match. Upon not finding a next-state transition, the machine hangs.</p>
+
<p>Following the completion of the instruction, the programmed controller evaluates the next-state by cascading through the ordered sequence of transition rules <RT·math>Δ = [Δ_0 \mid Δ_1 \mid Δ_2 \mid Δ_3]</RT·math>. The evaluation follows this hierarchy, stopping and branching at the first valid match. Upon not finding a next-state transition, the machine hangs.</p>
</RT·section>
</RT·section>
<RT·section>
<RT·name>Halting stage</RT·name>
- <p>If, after the state transition phase completes, the current state is a member of <RT·math>H</RT·math>, the machine halts. Otherwise, the execution continues from the programmed control stage.</p>
+
<p>If, after the state transition phase completes, the current state is a member of <RT·math>H</RT·math>, the machine halts. Otherwise, the execution continues from the programmed control stage.</p>
</RT·section>
</RT·section>
<RT·section>
- <RT·name>The TTCA Machine string reverse</RT·name>
-
- <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·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)
- δ:
+ <RT·name>The RT Machine string reverse</RT·name>
+
+ <p>Because the RT 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·counter·step counter="RT·Code·counter" id="Code·RT-reverse_controller">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·RT-reverse_controller"></RT·counter·snapshot>
+ <RT·code>
+ # RT 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·Search_EOM_0:
+ λ: right
+ δ:
Q·initial
- Q·Setup_EOR:
- λ: right
- δ:
+ Q·Setup_EOR:
+ λ: right
+ δ:
Q·Write_EOR
- Q·Write_EOR:
- λ: write(σ ,EOR)
- δ:
+ Q·Write_EOR:
+ λ: write(σ ,EOR)
+ δ:
Q·Fetch_0
- # Phase 2: Fetch the next unprocessed symbol and check boundaries.
- Q·Fetch_0:
- λ: left
- δ:
+ # Phase 2: Fetch the next unprocessed symbol and check boundaries.
+ Q·Fetch_0:
+ λ: left
+ δ:
Q·Fetch_1
- Q·Fetch_1:
- λ: read(s)
- δ:
+ Q·Fetch_1:
+ λ: read(s)
+ δ:
(EOM: Q·Check_Boundary)
(SP: Q·Check_Boundary)
Q·Read_Data
- Q·Check_Boundary:
- λ: status
- δ:
+ Q·Check_Boundary:
+ λ: status
+ δ:
(leftmost: Q·Done)
Q·Fetch_0
- Q·Read_Data:
- λ: read(d)
- δ:
+ Q·Read_Data:
+ λ: read(d)
+ δ:
Q·Check_Last_Char
- Q·Check_Last_Char:
- λ: status
- δ:
+ 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)
- δ:
+ # 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_0:
+ λ: right
+ δ:
Q·Carry_1
- Q·Carry_1:
- λ: read(s)
- δ:
+ 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)
- δ:
+ # 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_0:
+ λ: right
+ δ:
Q·Advance_EOR_1
- Q·Advance_EOR_1:
- λ: write(σ ,EOR)
- δ:
+ 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
- δ:
+ # 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)
- δ:
+ 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)
- δ:
+ # 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_0:
+ λ: right
+ δ:
Q·Carry_Last_1
- Q·Carry_Last_1:
- λ: read(s)
- δ:
+ Q·Carry_Last_1:
+ λ: read(s)
+ δ:
(EOR: Q·Drop_Last)
Q·Carry_Last_0
- Q·Drop_Last:
- λ: write(d)
- δ:
+ Q·Drop_Last:
+ λ: write(d)
+ δ:
Q·Advance_EOR_Last_0
- Q·Advance_EOR_Last_0:
- λ: right
- δ:
+ Q·Advance_EOR_Last_0:
+ λ: right
+ δ:
Q·Advance_EOR_Last_1
- Q·Advance_EOR_Last_1:
- λ: write(σ ,EOR)
- δ:
+ 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·code>
+ Code <RT·counter·read snapshot="Code·RT-reverse_controller"></RT·counter·read>. <RT·name>The RT Machine string reverse controller</RT·name>
+ </RT·counter·step>
+
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·RT_reverse-machine">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·RT_reverse-machine"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="RT_style_TM_reverse.png" class="RT·diagram" alt="RTM reverse machine">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·RT_reverse-machine"></RT·counter·read>. <RT·name>The RT Machine that reverses a binary string</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
- <RT·name>Analysis of the TTCA reverse machine</RT·name>
-
- <p>The number of states is constant at 24 independent of how much data is to be reversed. No arc refers to a payload value.</p>
-
- <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·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){right(); read('s');}
- right();
- write('σ' ,EOR);
-
- while(true){
- // The Fetch Pivot: Locate the next unprocessed symbol
- left();
- read('s');
- while(s == EOM || s == SP){
+ <RT·name>Analysis of the RT reverse machine</RT·name>
+
+
<p>The number of states is constant at 24 independent of how much data is to be reversed. No arc refers to a payload value.</p>
+
+
<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·counter·step counter="RT·Code·counter" id="Code·RT-reverse_in_C">
+ <RT·counter·snapshot counter="RT·Code·counter" snapshot="Code·RT-reverse_in_C"></RT·counter·snapshot>
+ <RT·code>
+ void RT·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();
+ 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;
+
+ // 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);
+
+ left();
+ read('s');
+ while(s != EOM){left(); read('s');}
+ }
- read('d');
- status();
-
- // Center Break: Q·Check_Last_Char routes to the final chain
- if(s == leftmost) break;
-
- // 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);
-
- left();
- read('s');
- while(s != EOM){left(); read('s');}
- }
-
- // 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>
- 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·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>
+ // 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>
+ Code <RT·counter·read snapshot="Code·RT-reverse_in_C"></RT·counter·read>. <RT·name>The RT 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 RT Machine:</p>
+
+ <RT·counter·step counter="RT·Equation·counter" id="Equation·RT-reverse_step-count">
+ <RT·counter·snapshot counter="RT·Equation·counter" snapshot="Equation·RT-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·RT-reverse_step-count"></RT·counter·read> <RT·name>Steps taken by the RT reverse machine</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
<RT·name>Two-headed reverse string example</RT·name>
- <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>
+
<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·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
+ <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>
+ # RT Two-Head String Reverse
+ # input: (σ ∈ Σ)* EOM (starting on the leftmost cell)
+ # output: SP* EOM (σ ∈ Σ in reverse)* EOR
- halt: Q·Done
+ halt: Q·Done
- table:
- # Phase 1: Both heads scan right to the EOM pivot
- Q·initial:
- λ: read('s' ,0)
- δ:
+ 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_0:
+ λ: right(0)
+ δ:
Q·Scan_Right_1
- Q·Scan_Right_1:
- λ: right(1)
- δ:
+ Q·Scan_Right_1:
+ λ: right(1)
+ δ:
Q·initial
- # Phase 2: Setup pointers for reading and writing
- Q·Check_Empty:
- λ: status(0)
- δ:
+ # 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·Empty_Setup_1:
+ λ: right(1)
+ δ:
Q·Write_EOR_Done
- Q·Setup_Write_1:
- λ: right(1)
- δ:
+ Q·Setup_Write_1:
+ λ: right(1)
+ δ:
Q·Setup_Write_2
- Q·Setup_Write_2:
- λ: left(0)
- δ:
+ Q·Setup_Write_2:
+ λ: left(0)
+ δ:
Q·Copy_Read
- # Phase 3: The Linear Copy Loop
- Q·Copy_Read:
- λ: read('d' ,0)
- δ:
+ # Phase 3: The Linear Copy Loop
+ Q·Copy_Read:
+ λ: read('d' ,0)
+ δ:
Q·Copy_Status
- Q·Copy_Status:
- λ: status(0)
- δ:
+ Q·Copy_Status:
+ λ: status(0)
+ δ:
(leftmost: Q·Copy_Last_Erase)
Q·Copy_Erase
- Q·Copy_Erase:
- λ: write('σ' ,0 ,SP)
- δ:
+ Q·Copy_Erase:
+ λ: write('σ' ,0 ,SP)
+ δ:
Q·Copy_Write
- Q·Copy_Write:
- λ: write('d' ,1)
- δ:
+ Q·Copy_Write:
+ λ: write('d' ,1)
+ δ:
Q·Copy_Advance_1
- Q·Copy_Advance_1:
- λ: right(1)
- δ:
+ Q·Copy_Advance_1:
+ λ: right(1)
+ δ:
Q·Copy_Advance_0
- Q·Copy_Advance_0:
- λ: left(0)
- δ:
+ Q·Copy_Advance_0:
+ λ: left(0)
+ δ:
Q·Copy_Read
- # Phase 4: Final Symbol and Clean Halt
- Q·Copy_Last_Erase:
- λ: write('σ' ,0 ,SP)
- δ:
+ # 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_Write:
+ λ: write('d' ,1)
+ δ:
Q·Copy_Last_Advance
- Q·Copy_Last_Advance:
- λ: right(1)
- δ:
+ Q·Copy_Last_Advance:
+ λ: right(1)
+ δ:
Q·Write_EOR_Done
- Q·Write_EOR_Done:
- λ: write('σ' ,1 ,EOR)
- δ:
+ 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·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·RT_two-headed_reverse-machine">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·RT_two-headed_reverse-machine"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="RT_2_hd_reverse.png" class="RT·diagram" alt="RTM 2 hd reverse machine">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·RT_two-headed_reverse-machine"></RT·counter·read>. <RT·name>A two-headed RT Machine that reverses a binary string</RT·name>
+ </RT·counter·step>
</RT·section>
<RT·section>
<RT·name>Analysis of the two-headed reverse string machine</RT·name>
- <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·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·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;
- }
-
- right(1);
- left(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;
-
- 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);
-
- 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>
-
- <p>The time complexity of the longest compute time input of length <RT·math>n</RT·math> dropping from <RT·math>O(n^2)</RT·math> to <RT·math>O(n)</RT·math> is computation theoretic consequential, so we should make a choice as to which machine to use as a reference. Given that realized computers have multiple pointers into different memory contexts, the multi-head Turing Machine is the more suitable reference model.</p>
-
- <p>Adding heads functions as a specialized optimization rather than a universal method for improving performance complexity. Quadratic performance improvements manifest only under specific conditions. Even when they occur, the improvement remains insufficiently strong to alter the asymptotic performance if higher-order terms exist in the step-count polynomial. Furthermore, eliminating shuttling is structurally incapable of reducing a linear step-count to a constant-time step-count; the reason is that <RT·math>n</RT·math> is unbounded, while adding <RT·math>k</RT·math> heads only divides the work by a fixed constant <RT·math>k</RT·math>. Consequently, while the transformation is consequential in specific cases, it cannot change the broader time complexity class.
- </p>
+ <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 RT architecture:</p>
+
+
+ <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 RT 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·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 RT·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;
+ }
+
+ right(1);
+ left(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;
+
+ 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);
+
+ 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>
+
+
<p>The time complexity of the longest compute time input of length <RT·math>n</RT·math> dropping from <RT·math>O(n^2)</RT·math> to <RT·math>O(n)</RT·math> is computation theoretic consequential, so we should make a choice as to which machine to use as a reference. Given that realized computers have multiple pointers into different memory contexts, the multi-head Turing Machine is the more suitable reference model.</p>
+
+
<p>Adding heads functions as a specialized optimization rather than a universal method for improving performance complexity. Quadratic performance improvements manifest only under specific conditions. Even when they occur, the improvement remains insufficiently strong to alter the asymptotic performance if higher-order terms exist in the step-count polynomial. Furthermore, eliminating shuttling is structurally incapable of reducing a linear step-count to a constant-time step-count; the reason is that <RT·math>n</RT·math> is unbounded, while adding <RT·math>k</RT·math> heads only divides the work by a fixed constant <RT·math>k</RT·math>. Consequently, while the transformation is consequential in specific cases, it cannot change the broader time complexity class.
+ </p>
</RT·section>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section id="Section·TTCA_machine-design">
- <RT·name>The TTCA Machine design</RT·name>
+ <RT·section id="Section·RT_machine-design">
+ <RT·name>The RT Machine design</RT·name>
- <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>
+ <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, 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>The prior chapter on the computation theoretic RT Machine, chapter <RT·counter·read snapshot="Section·RT_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 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>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>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>The same can be said for space complexity. Suppose a program doubled its memory footprint each time its input string increased by one. If an individual proton could hold one bit of memory, say via its spin, an input increase of merely 270 characters for such a program would exhaust all the protons in the universe. Allocating a cell of space requires the machine to take a step, so time complexity is at least equal to space complexity. If a computer ran at 10 GHz and a step required <RT·math>10^{-10}</RT·math> seconds, this same extension would require <RT·math>6 \times 10^{63}</RT·math> years. For perspective, the universe is approximately <RT·math>1.4 \times 10^{10}</RT·math> years old.</p>
+
<p>The same can be said for space complexity. Suppose a program doubled its memory footprint each time its input string increased by one. If an individual proton could hold one bit of memory, say via its spin, an input increase of merely 270 characters for such a program would exhaust all the protons in the universe. Allocating a cell of space requires the machine to take a step, so time complexity is at least equal to space complexity. If a computer ran at 10 GHz and a step required <RT·math>10^{-10}</RT·math> seconds, this same extension would require <RT·math>6 \times 10^{63}</RT·math> years. For perspective, the universe is approximately <RT·math>1.4 \times 10^{10}</RT·math> years old.</p>
- <p>This book provides the transformational steps needed to go from the Turing Machine to realized machines, and one objective is to recover some correspondence between the machine steps of the model and the wall-clock time the machine takes to run. Given this, the system operator changing tapes creates a step that is disproportionately longer than the other steps, a factor that requires architectural mediation, but will always remain. For example, this structural penalty resurfaces in the form of cache misses causing a machine to reach into system memory, or worse, page faults, requiring a machine to go back to disk.</p>
+
<p>This book provides the transformational steps needed to go from the Turing Machine to realized machines, and one objective is to recover some correspondence between the machine steps of the model and the wall-clock time the machine takes to run. Given this, the system operator changing tapes creates a step that is disproportionately longer than the other steps, a factor that requires architectural mediation, but will always remain. For example, this structural penalty resurfaces in the form of cache misses causing a machine to reach into system memory, or worse, page faults, requiring a machine to go back to disk.</p>
- <p>As a possible practical solution, note that if the program does not exhaust the current tape, the operator will never be called. How much tape is required to ensure this? An analyst could choose worst-case operands and measure the footprint when the program runs. At first, this appears to be the familiar 'my number is bigger than your number, I'll tell you mine after you tell me yours' game, which can be viewed as the definition for the countable infinity. However, there is a loophole. Running the system once with the worst-case operands to establish time and space ceilings guarantees the program can be allocated sufficient resources later for other operands. This is a practical approach, provided the program is a workhorse utility rather than an algorithm searching for a solution to an unsolved problem, and thus only needs to be run once.</p>
+
<p>As a possible practical solution, note that if the program does not exhaust the current tape, the operator will never be called. How much tape is required to ensure this? An analyst could choose worst-case operands and measure the footprint when the program runs. At first, this appears to be the familiar 'my number is bigger than your number, I'll tell you mine after you tell me yours' game, which can be viewed as the definition for the countable infinity. However, there is a loophole. Running the system once with the worst-case operands to establish time and space ceilings guarantees the program can be allocated sufficient resources later for other operands. This is a practical approach, provided the program is a workhorse utility rather than an algorithm searching for a solution to an unsolved problem, and thus only needs to be run once.</p>
- <p>Another practical solution, one that also applies to the first run of the program, is to analyze the logic to compute the time per step and extrapolate the total execution time. This is structurally viable only for specific programs; for others, tracing a path through the execution logic is as computationally complex as running the program itself, taking us back to the analysis in the prior paragraph. However, this phenomenon restricts itself to specific programmatic classes. Consider the previously mentioned examples of the ten step machine, the machine bouncing between two cells, and the Hindu-Arabic counting machine. All of those programs can be, indeed were, analyzed before they were run.</p>
+
<p>Another practical solution, one that also applies to the first run of the program, is to analyze the logic to compute the time per step and extrapolate the total execution time. This is structurally viable only for specific programs; for others, tracing a path through the execution logic is as computationally complex as running the program itself, taking us back to the analysis in the prior paragraph. However, this phenomenon restricts itself to specific programmatic classes. Consider the previously mentioned examples of the ten step machine, the machine bouncing between two cells, and the Hindu-Arabic counting machine. All of those programs can be, indeed were, analyzed before they were run.</p>
- <p>Suppose a controller is not analyzed to determine its computation theoretic complexity, or even tested against worst-case inputs, but is instead run with random or everyday input to gather performance measurements. This process is called <RT·term>profiling</RT·term>. After many runs, a programmer might surmise the behavioral limits of the program. However, many programs are neither linear systems nor smooth functions. With a different set of inputs than those used for profiling, perhaps even values adjacent to prior inputs, the program behavior can shift drastically. Consider the Pentium divider. It did not matter how many millions of times the result was accurate; the fact remains that customers later found inputs that yielded wildly inaccurate results. Only by elevating the analysis to the structural logic of the code can such an eventuality from an erroneous program be categorically ruled out. <RT·endnote>This is why the K5 transcendental function development project included a proof writing phase; see Thomas Walker Lynch, A. Ahmed, M. Schulte, T. Callaway, and R. Tisdale, "The K5 Transcendental Functions," <em>Proceedings of the 12th IEEE Symposium on Computer Arithmetic</em>, 1995. DOI: 10.1109/ARITH.1995.465368.</RT·endnote></p>
+
<p>Suppose a controller is not analyzed to determine its computation theoretic complexity, or even tested against worst-case inputs, but is instead run with random or everyday input to gather performance measurements. This process is called <RT·term>profiling</RT·term>. After many runs, a programmer might surmise the behavioral limits of the program. However, many programs are neither linear systems nor smooth functions. With a different set of inputs than those used for profiling, perhaps even values adjacent to prior inputs, the program behavior can shift drastically. Consider the Pentium divider. It did not matter how many millions of times the result was accurate; the fact remains that customers later found inputs that yielded wildly inaccurate results. Only by elevating the analysis to the structural logic of the code can such an eventuality from an erroneous program be categorically ruled out. <RT·endnote>This is why the K5 transcendental function development project included a proof writing phase; see Thomas Walker Lynch, A. Ahmed, M. Schulte, T. Callaway, and R. Tisdale, "The K5 Transcendental Functions," <em>Proceedings of the 12th IEEE Symposium on Computer Arithmetic</em>, 1995. DOI: 10.1109/ARITH.1995.465368.</RT·endnote></p>
<RT·section>
<RT·name>Head Unit, <RT·code>HU</RT·code></RT·name>
- <p>An <RT·code>HU</RT·code> contains a head and a local controller. The local controller supports these instructions:</p>
+
<p>An <RT·code>HU</RT·code> contains a head and a local controller. The local controller supports these instructions:</p>
- <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>
+ <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>
+ <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 physical 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>
+
<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 physical 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>
+ <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>
+ <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>
+
<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>
- <p>For a realized <RT·code>TTU</RT·code>, data can only be read or written when there is relative motion between the head and the tape. Consequently, in an <RT·code>HU</RT·code> implementation, data and status registers are updated from an internal buffer that acquires data during head motion. Conversely, a write value is buffered until subsequent head motion provides the opportunity to write it to the tape.</p>
+
<p>For a realized <RT·code>TTU</RT·code>, data can only be read or written when there is relative motion between the head and the tape. Consequently, in an <RT·code>HU</RT·code> implementation, data and status registers are updated from an internal buffer that acquires data during head motion. Conversely, a write value is buffered until subsequent head motion provides the opportunity to write it to the tape.</p>
- <p>Because values can only be read or written to a tape when the tape is in motion, it is advantageous to exaggerate the motion of step instructions and to cache a small number of values. In addition, most architectures that make use of a tape drive will attempt to leverage high throughput in an effort to hide high latency by reading or writing blocks of symbols per tape access. Note, however, that the basic TTCA Machine organization lacks the core memory required for buffering blocks.</p>
+ <p>Because values can only be read or written to a tape when the tape is in motion, it is advantageous to exaggerate the motion of step instructions and to cache a small number of values. In addition, most architectures that make use of a tape drive will attempt to leverage high throughput in an effort to hide high latency by reading or writing blocks of symbols per tape access. Note, however, that the basic RT Machine organization lacks the core memory required for buffering blocks.</p>
</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>
-
- <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>
-
- <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 <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>
+
+ <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>
+ <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>
+
+ <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>
+ <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>
</RT·section>
<RT·section>
<RT·name>The customer programmed control unit, <RT·code>CPCU</RT·code></RT·name>
- <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·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 { } |
- +-----------------------------------+
- </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 |
- | ● ○ ○ ○ ○ ○ |
- halt | [/] [/] [/] [/] [/] [/] |
- +-------------------------------------------+
- def | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
- ● s0 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
- ○ s1 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
- ○ s2 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
- ○ s3 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
- ○ s4 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
- | |
- destination state | ( ) ( ) ( ) ( ) ( ) ( ) |
- +-------------------------------------------+
- </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 |
- Src | ( ) ( ) ( ) ( ) ( ) ( ) |
- +-----------------------------------+
- right | ( ) ( ) ( ) ( ) ( ) ( ) |
- left | ( ) ( ) ( ) ( ) ( ) ( ) |
- read('s') | ( ) ( ) ( ) ( ) ( ) ( ) |
- read('d') | ( ) ( ) ( ) ( ) ( ) ( ) |
- write('s')| ( ) ( ) ( ) ( ) ( ) ( ) |
- write('d')| ( ) ( ) ( ) ( ) ( ) ( ) |
- write('σ')| ( ) ( ) ( ) ( ) ( ) ( ) |
- +-----------------------------------+
- </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 |
- Src | ( ) ( ) ( ) ( ) ( ) ( ) |
- +-----------------------------------+
- s0 | ( ) ( ) ( ) ( ) ( ) ( ) |
- s1 | ( ) ( ) ( ) ( ) ( ) ( ) |
- s2 | ( ) ( ) ( ) ( ) ( ) ( ) |
- s3 | ( ) ( ) ( ) ( ) ( ) ( ) |
- s4 | ( ) ( ) ( ) ( ) ( ) ( ) |
- +-----------------------------------+
- </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>
-
- <p>The second section is the state transition panel. At the top of this panel are the state indicator lights and a row of halting toggles; if flipped closed, the corresponding state becomes a halting state. Below this is the transition condition matrix, consisting of holes that fit the banana plug ends of a patch cord. Each column corresponds to a current state, and each row corresponds to a status symbol.</p>
-
- <p>The transition condition matrix integrates the default fallback logic structurally. The <RT·code>def</RT·code> column on the left handles the status default transitions, providing a physical mechanism for routing a specific status symbol to a destination state when no active conditional patch cord is present. The <RT·code>def</RT·code> row above the status symbols handles the state default transitions. The single hole at the intersection of this default row and default column represents the global default transition.</p>
-
- <p>Below the transition condition matrix is the destination state row. If the fan-in for a state requires multiple patch cords, a special banana plug adapter can be used, or the patch cords themselves can feature stackable sockets on the back of the plugs, allowing multiple incoming transitions to bridge into a single destination hole.</p>
-
- <p>To program the controller, the programmer connects the patch cords. For example, routing a patch cord from the <RT·math>(q_2, s_2)</RT·math> intersection to the <RT·math>q_3</RT·math> destination hole physically realizes a conditional state transition arc for the controller for the tripple <RT·math>\langle q_2, s_2, q_3 \rangle</RT·math>. If the active status value has no patch cord plugged in at the specific state intersection, the machine evaluates the status default column. If that hole is also empty, the machine utilizes the state default transition hole for the current state. Finally, if no patch cord is plugged in across any of the prior layers, the global default patch cord located at the <RT·code>def</RT·code> intersection is followed.</p>
-
- <p>Below the transition panel are the instruction selection and symbol selection panels. To enforce the rule that each state executes exactly one instruction, each state column on the instruction panel features a single source hole at the top. The programmer routes a patch cord from this source hole down to the desired instruction row. If the selected instruction requires a symbol argument, such as <RT·code>write('σ' ,σ)</RT·code>, a similar routing is performed on the bottom symbol selection panel. Note that this describes the control panel for a single-head, single-<RT·code>TTU</RT·code> machine. Additional patch options would be required to add a <RT·code>TTU</RT·code> device specifier and a head specifier within each <RT·code>TTU</RT·code>.</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·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 -->
+ [ CONTROL PANEL ]
+ +-----------------------------------+
+ | POWER [—] ● ERROR ○ RESET { } |
+ +-----------------------------------+
+ +-----------------------------------+
+ | RUN/STEP [/] ○ STEP { } |
+ +-----------------------------------+
+ </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 -->
+ [ State Transition Table ]
+ +-------------------------------------------+
+ current state | def q0 q1 q2 q3 q4 q5 |
+ | ● ○ ○ ○ ○ ○ |
+ halt | [/] [/] [/] [/] [/] [/] |
+ +-------------------------------------------+
+ def | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
+ ● s0 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
+ ○ s1 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
+ ○ s2 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
+ ○ s3 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
+ ○ s4 | ( ) ( ) ( ) ( ) ( ) ( ) ( ) |
+ | |
+ destination state | ( ) ( ) ( ) ( ) ( ) ( ) |
+ +-------------------------------------------+
+ </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 -->
+ [ Instruction ]
+ +-----------------------------------+
+ | q0 q1 q2 q3 q4 q5 |
+ Src | ( ) ( ) ( ) ( ) ( ) ( ) |
+ +-----------------------------------+
+ right | ( ) ( ) ( ) ( ) ( ) ( ) |
+ left | ( ) ( ) ( ) ( ) ( ) ( ) |
+ read('s') | ( ) ( ) ( ) ( ) ( ) ( ) |
+ read('d') | ( ) ( ) ( ) ( ) ( ) ( ) |
+ write('s')| ( ) ( ) ( ) ( ) ( ) ( ) |
+ write('d')| ( ) ( ) ( ) ( ) ( ) ( ) |
+ write('σ')| ( ) ( ) ( ) ( ) ( ) ( ) |
+ +-----------------------------------+
+ </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 -->
+ [ Sigma Select for write('σ') ]
+ +-----------------------------------+
+ | q0 q1 q2 q3 q4 q5 |
+ Src | ( ) ( ) ( ) ( ) ( ) ( ) |
+ +-----------------------------------+
+ s0 | ( ) ( ) ( ) ( ) ( ) ( ) |
+ s1 | ( ) ( ) ( ) ( ) ( ) ( ) |
+ s2 | ( ) ( ) ( ) ( ) ( ) ( ) |
+ s3 | ( ) ( ) ( ) ( ) ( ) ( ) |
+ s4 | ( ) ( ) ( ) ( ) ( ) ( ) |
+ +-----------------------------------+
+ </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>
+
+
<p>The second section is the state transition panel. At the top of this panel are the state indicator lights and a row of halting toggles; if flipped closed, the corresponding state becomes a halting state. Below this is the transition condition matrix, consisting of holes that fit the banana plug ends of a patch cord. Each column corresponds to a current state, and each row corresponds to a status symbol.</p>
+
+
<p>The transition condition matrix integrates the default fallback logic structurally. The <RT·code>def</RT·code> column on the left handles the status default transitions, providing a physical mechanism for routing a specific status symbol to a destination state when no active conditional patch cord is present. The <RT·code>def</RT·code> row above the status symbols handles the state default transitions. The single hole at the intersection of this default row and default column represents the global default transition.</p>
+
+
<p>Below the transition condition matrix is the destination state row. If the fan-in for a state requires multiple patch cords, a special banana plug adapter can be used, or the patch cords themselves can feature stackable sockets on the back of the plugs, allowing multiple incoming transitions to bridge into a single destination hole.</p>
+
+
<p>To program the controller, the programmer connects the patch cords. For example, routing a patch cord from the <RT·math>(q_2, s_2)</RT·math> intersection to the <RT·math>q_3</RT·math> destination hole physically realizes a conditional state transition arc for the controller for the tripple <RT·math>\langle q_2, s_2, q_3 \rangle</RT·math>. If the active status value has no patch cord plugged in at the specific state intersection, the machine evaluates the status default column. If that hole is also empty, the machine utilizes the state default transition hole for the current state. Finally, if no patch cord is plugged in across any of the prior layers, the global default patch cord located at the <RT·code>def</RT·code> intersection is followed.</p>
+
+
<p>Below the transition panel are the instruction selection and symbol selection panels. To enforce the rule that each state executes exactly one instruction, each state column on the instruction panel features a single source hole at the top. The programmer routes a patch cord from this source hole down to the desired instruction row. If the selected instruction requires a symbol argument, such as <RT·code>write('σ' ,σ)</RT·code>, a similar routing is performed on the bottom symbol selection panel. Note that this describes the control panel for a single-head, single-<RT·code>TTU</RT·code> machine. Additional patch options would be required to add a <RT·code>TTU</RT·code> device specifier and a head specifier within each <RT·code>TTU</RT·code>.</p>
</RT·section>
<RT·section>
<RT·name>The machine block diagram</RT·name>
- <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. 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>
- <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
+ <RT·counter·step counter="RT·Figure·counter" id="Figure·RT_block-diagram">
+ <RT·counter·snapshot counter="RT·Figure·counter" snapshot="Figure·RT_block-diagram"></RT·counter·snapshot>
+ <!-- first edition: no number carried -->
+ <figure>
+ <img src="RT_machine.svg" class="RT·diagram" alt="Figure: RT block diagram">
+ </figure>
+ Figure <RT·counter·read snapshot="Figure·RT_block-diagram"></RT·counter·read>. <RT·name>The RT Machine block diagram</RT·name>
+ </RT·counter·step>
+
+ <p>This section describes the RT Machine organization. Figure <RT·counter·read snapshot="Figure·RT_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>
+ <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>mode control
+ <li>Control Panel
<ol>
- <li>power</li>
- <li>run/step</li>
+ <li>Power Switch, Single-Step Switch, Reset Button, Single-Step Button</li>
+ <li>patch cord matrices</li>
</ol>
</li>
- <li>staging
+ <li>Executor
<ol>
- <li>reset button</li>
- <li>reset logic and distribution lines</li>
- <li><RT·code>Halt Switch Bank</RT·code></li>
+ <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>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>
+ <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>
- </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>
+ 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>As described in chapter <RT·counter·read snapshot="Section·RT_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>
+
<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>
- <p>The output of the <RT·code>Instruction Table</RT·code> provides primary control of the running machine. Its output determines which of the <RT·code>TTU</RT·code>s will be active and which head in the <RT·code>TTU</RT·code> is to be used. The machine has an internal data bus. The output of the <RT·code>Instruction Table</RT·code> also determines which <RT·code>TTU</RT·code> register will drive that bus, and which register will receive data from the bus.</p>
+
<p>The output of the <RT·code>Instruction Table</RT·code> provides primary control of the running machine. Its output determines which of the <RT·code>TTU</RT·code>s will be active and which head in the <RT·code>TTU</RT·code> is to be used. The machine has an internal data bus. The output of the <RT·code>Instruction Table</RT·code> also determines which <RT·code>TTU</RT·code> register will drive that bus, and which register will receive data from the bus.</p>
- <p>The register file contains two registers, <RT·code>s</RT·code> and <RT·code>d</RT·code>. Both can receive values from the internal data bus or drive values onto that bus. The <RT·code>d</RT·code> register is not connected to any other units, so it can not participate in the next-state decision process. It can however, be an argument in a subsequent write instruction, causing its value to go back out on the data bus, then to an <RT·code>HU</RT·code>, and then be put back on the tape. The <RT·code>s</RT·code> register is connected directly to the <RT·code>Status Decode</RT·code>, and that in turn is connected directly to the next-state logic. The <RT·code>s</RT·code> register can also drive the data bus.</p>
+
<p>The register file contains two registers, <RT·code>s</RT·code> and <RT·code>d</RT·code>. Both can receive values from the internal data bus or drive values onto that bus. The <RT·code>d</RT·code> register is not connected to any other units, so it can not participate in the next-state decision process. It can however, be an argument in a subsequent write instruction, causing its value to go back out on the data bus, then to an <RT·code>HU</RT·code>, and then be put back on the tape. The <RT·code>s</RT·code> register is connected directly to the <RT·code>Status Decode</RT·code>, and that in turn is connected directly to the next-state logic. The <RT·code>s</RT·code> register can also drive the data bus.</p>
- <p>The symbols of the alphabet are enumerated such that each symbol corresponds to a specific row index on the control panel. The value of the <RT·code>s</RT·code> register is decoded, resulting in a one-hot encoding of the status symbol. This one-hot encoding then goes to the <RT·code>Next-State Table</RT·code> in the <RT·code>CPCU</RT·code> and illuminates one of the rows. The <RT·code>q</RT·code> register enumerates the columns. If a patch cord is plugged into that intersection point and leads to the destination state row below, then the state selected becomes the next-state for the machine.</p>
+
<p>The symbols of the alphabet are enumerated such that each symbol corresponds to a specific row index on the control panel. The value of the <RT·code>s</RT·code> register is decoded, resulting in a one-hot encoding of the status symbol. This one-hot encoding then goes to the <RT·code>Next-State Table</RT·code> in the <RT·code>CPCU</RT·code> and illuminates one of the rows. The <RT·code>q</RT·code> register enumerates the columns. If a patch cord is plugged into that intersection point and leads to the destination state row below, then the state selected becomes the next-state for the machine.</p>
- <p>The current state register <RT·code>q</RT·code> utilizes a one-hot encoding, allocating a discrete bit per state. A control line from each bit routes to the Halt Switch Bank within the executor, where the outputs are wire-ORed together to generate the master halt signal. Consequently, a halt condition asserts if and only if the currently active state bit corresponds to an enabled toggle in the switch bank. The output of the <RT·code>q</RT·code> register also selects a row in the <RT·code>Instruction Table</RT·code>, and this is key to controlling the machine.</p>
+
<p>The current state register <RT·code>q</RT·code> utilizes a one-hot encoding, allocating a discrete bit per state. A control line from each bit routes to the Halt Switch Bank within the executor, where the outputs are wire-ORed together to generate the master halt signal. Consequently, a halt condition asserts if and only if the currently active state bit corresponds to an enabled toggle in the switch bank. The output of the <RT·code>q</RT·code> register also selects a row in the <RT·code>Instruction Table</RT·code>, and this is key to controlling the machine.</p>
- <p>Upon reset, the current state register initializes to a one-hot configuration with the bit for state <RT·math>q_0</RT·math> asserted, while all other machine registers clear to zero. Uncontrolled power-up could trap the machine in an illegal configuration where it would ignore subsequent reset instructions or even induce physical hardware damage. To prevent initialization hazards, the power switch incorporates a capacitor timer that maintains an active reset signal until supply voltages fully stabilize. When in run mode, the machine will begin running after reset is released. In single-step mode, it will then wait for a push of the single-step button.</p>
+
<p>Upon reset, the current state register initializes to a one-hot configuration with the bit for state <RT·math>q_0</RT·math> asserted, while all other machine registers clear to zero. Uncontrolled power-up could trap the machine in an illegal configuration where it would ignore subsequent reset instructions or even induce physical hardware damage. To prevent initialization hazards, the power switch incorporates a capacitor timer that maintains an active reset signal until supply voltages fully stabilize. When in run mode, the machine will begin running after reset is released. In single-step mode, it will then wait for a push of the single-step button.</p>
- <p>
- The tape transport unit, <RT·code>TTU</RT·code>, handles mounting, unmounting, reading, writing, and moving the tape. In this volume, we treat head motion in a relative sense, recognizing that a physical <RT·code>TTU</RT·code> moves the magnetic tape beneath a stationary head rather than displacing the head across the tape. Our architecture allows a system to incorporate multiple <RT·code>TTU</RT·code> modules, each containing its own read buffer, status buffer, and head assembly. Tapes can be dynamically mounted, unmounted, shelved, and transferred between any <RT·code>TTU</RT·code> on the same machine or across distinct systems.
- </p>
+ The tape transport unit, <RT·code>TTU</RT·code>, handles mounting, unmounting, reading, writing, and moving the tape. In this volume, we treat head motion in a relative sense, recognizing that a physical <RT·code>TTU</RT·code> moves the magnetic tape beneath a stationary head rather than displacing the head across the tape. Our architecture allows a system to incorporate multiple <RT·code>TTU</RT·code> modules, each containing its own read buffer, status buffer, and head assembly. Tapes can be dynamically mounted, unmounted, shelved, and transferred between any <RT·code>TTU</RT·code> on the same machine or across distinct systems.
+ </p>
<RT·section>
<RT·name>Description of a <RT·code>read('s')</RT·code> instruction</RT·name>
- <p>The current state register, <RT·code>q</RT·code>, samples and holds on the rising edge of the clock. This then provides a stable state signal to the control panel next-state matrix columns for an entire cycle. The status register, <RT·code>s</RT·code>, is the phase inverse; when enabled it samples on the falling edge of the clock and holds for an entire cycle.</p>
+
<p>The current state register, <RT·code>q</RT·code>, samples and holds on the rising edge of the clock. This then provides a stable state signal to the control panel next-state matrix columns for an entire cycle. The status register, <RT·code>s</RT·code>, is the phase inverse; when enabled it samples on the falling edge of the clock and holds for an entire cycle.</p>
- <p>On the rising edge of the clock, the new current state signal ripples through the <RT·code>Instruction Table</RT·code>. As the <RT·code>q</RT·code> register is stored as a one-hot value, this happens very quickly. Rather than placing instructions in the <RT·code>Instruction Table</RT·code>, the decoded values to be used as control signals are programmed directly into the table. Among the decoded outputs is a control signal that enables the status register to sample when the clock falls.</p>
+
<p>On the rising edge of the clock, the new current state signal ripples through the <RT·code>Instruction Table</RT·code>. As the <RT·code>q</RT·code> register is stored as a one-hot value, this happens very quickly. Rather than placing instructions in the <RT·code>Instruction Table</RT·code>, the decoded values to be used as control signals are programmed directly into the table. Among the decoded outputs is a control signal that enables the status register to sample when the clock falls.</p>
- <p>A control signal from the decoded instruction coming from the <RT·code>Instruction Table</RT·code> then enables the selected <RT·code>TTU</RT·code> and provides it with its decoded instruction. Part of the decode will be the <RT·code>HU</RT·code> select line, and a signal to tell the <RT·code>HU</RT·code> status register to drive the machine's internal data bus.</p>
+
<p>A control signal from the decoded instruction coming from the <RT·code>Instruction Table</RT·code> then enables the selected <RT·code>TTU</RT·code> and provides it with its decoded instruction. Part of the decode will be the <RT·code>HU</RT·code> select line, and a signal to tell the <RT·code>HU</RT·code> status register to drive the machine's internal data bus.</p>
- <p>Thus the status register in the selected <RT·code>TTU</RT·code> and <RT·code>HU</RT·code> will be driving the data bus, and the machine <RT·code>s</RT·code> register is ready to sample the bus. Then the clock falls, the <RT·code>s</RT·code> register updates, and holds its value until the next time when it is enabled to update and the clock falls.</p>
+
<p>Thus the status register in the selected <RT·code>TTU</RT·code> and <RT·code>HU</RT·code> will be driving the data bus, and the machine <RT·code>s</RT·code> register is ready to sample the bus. Then the clock falls, the <RT·code>s</RT·code> register updates, and holds its value until the next time when it is enabled to update and the clock falls.</p>
- <p>The updated value in the <RT·code>s</RT·code> register then drives the <RT·code>Next-State Table</RT·code> rows. The column lines stabilized earlier in the cycle, immediately after the state updated. If a patch cord is plugged in at the intersection of the row and the column, then a signal will travel through that cord to the next-state row that is located below the state and status matrix. Then when the clock rises again, this signal, which is held steady by the driving status register, will be sampled and become the next-state.</p>
+
<p>The updated value in the <RT·code>s</RT·code> register then drives the <RT·code>Next-State Table</RT·code> rows. The column lines stabilized earlier in the cycle, immediately after the state updated. If a patch cord is plugged in at the intersection of the row and the column, then a signal will travel through that cord to the next-state row that is located below the state and status matrix. Then when the clock rises again, this signal, which is held steady by the driving status register, will be sampled and become the next-state.</p>
- <p>Then the clock rises, and the cycle repeats, though perhaps while selecting a different row from the instruction table, and thus performing a different instruction.</p>
+
<p>Then the clock rises, and the cycle repeats, though perhaps while selecting a different row from the instruction table, and thus performing a different instruction.</p>
- <p>In physical machine design, rather than triggering logic on both edges of a single clock and managing strict duty cycle constraints, designers often deploy two clocks separated by a 180-degree phase shift. This configuration, known as two-phase clocking, allows all registers to sample uniformly on a rising edge (or all on a falling edge) while permitting designers to adjust the phase separation to optimize timing margins. This approach can be used to accommodate any number of phase separated clocks. Alternatively, a single-edge-triggered clock can drive the entire control loop. In this design, the current state propagates through the instruction table, selects the driving status register in the TTU, passes through the status decoder, and resolves at the next-state matrix. Because the <RT·code>s</RT·code> and <RT·code>d</RT·code> registers are wired as appendages to this primary loop and also sample on the rising edge, the system must enforce strict hold-time requirements. This guarantees the registers capture the established state rather than the transient values newly propagating across the bus. Clocking designs that successfully maintain these opeRational margins across the extremes of manufacturing tolerances and thermal ranges are said to be <em>clean</em>.</p>
+
<p>In physical machine design, rather than triggering logic on both edges of a single clock and managing strict duty cycle constraints, designers often deploy two clocks separated by a 180-degree phase shift. This configuration, known as two-phase clocking, allows all registers to sample uniformly on a rising edge (or all on a falling edge) while permitting designers to adjust the phase separation to optimize timing margins. This approach can be used to accommodate any number of phase separated clocks. Alternatively, a single-edge-triggered clock can drive the entire control loop. In this design, the current state propagates through the instruction table, selects the driving status register in the TTU, passes through the status decoder, and resolves at the next-state matrix. Because the <RT·code>s</RT·code> and <RT·code>d</RT·code> registers are wired as appendages to this primary loop and also sample on the rising edge, the system must enforce strict hold-time requirements. This guarantees the registers capture the established state rather than the transient values newly propagating across the bus. Clocking designs that successfully maintain these opeRational margins across the extremes of manufacturing tolerances and thermal ranges are said to be <em>clean</em>.</p>
<RT·section id="Section·area-and-partitioning">
<RT·name>Area and partitioning</RT·name>
- <p>
- We call a subset of contiguous cells from a tape an <RT·term>area</RT·term>. An area with a single cell is called a <RT·term>singleton</RT·term>, one with two cells is called a <RT·term>pair</RT·term>. An area has a leftmost cell and a rightmost cell. For a singleton area, those will be the same cell.
- </p>
+ We call a subset of contiguous cells from a tape an <RT·term>area</RT·term>. An area with a single cell is called a <RT·term>singleton</RT·term>, one with two cells is called a <RT·term>pair</RT·term>. An area has a leftmost cell and a rightmost cell. For a singleton area, those will be the same cell.
+ </p>
- <p>The left neighbor cell to the leftmost cell of a given area is considered to be the left neighbor cell to the area. Similarly, the right neighbor cell to the rightmost cell of a given area is considered to be the right neighbor cell to the area. If the given area is located at the left end of the tape, then it has no left neighbor cell. If the given area is open on the right, then it has no right neighbor cell.
- </p>
+
<p>The left neighbor cell to the leftmost cell of a given area is considered to be the left neighbor cell to the area. Similarly, the right neighbor cell to the rightmost cell of a given area is considered to be the right neighbor cell to the area. If the given area is located at the left end of the tape, then it has no left neighbor cell. If the given area is open on the right, then it has no right neighbor cell.
+ </p>
- <p>A <RT·term>tape partition</RT·term> is a set of areas that completely span a tape. For any partition of a single-ended Turing Machine tape, at least one of the areas will necessarily be infinite.
- </p>
+
<p>A <RT·term>tape partition</RT·term> is a set of areas that completely span a tape. For any partition of a single-ended Turing Machine tape, at least one of the areas will necessarily be infinite.
+ </p>
<RT·section>
<RT·name>Head partition</RT·name>
- <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>
+ <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>
+ <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>
+
<p>If the head is on the leftmost cell, there is no left side area.</p>
</RT·section>
<RT·section>
<RT·name>Leftmost/remaining partition</RT·name>
- <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·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>
+ <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>
<RT·section>
<RT·name>Active area partition</RT·name>
- <p>
- A nonempty tape, one with at least one cell holding an alphabet symbol, can be partitioned into the following areas:
- </p>
+ A nonempty tape, one with at least one cell holding an alphabet symbol, can be partitioned into the following areas:
+ </p>
- <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>
+ <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>
+ <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>
- 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>
+ <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.
- </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 Peano 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.
+ </p>
</RT·section>
<RT·section>
<RT·name>Area implied partition</RT·name>
- <p>
- The existence of a finite given area implies a three area partition: the left side, the given area, and the right side. If the given area is located at the left end of the tape, there is no left side area. If the given area is open on the right, there is no right side area.
- </p>
+ The existence of a finite given area implies a three area partition: the left side, the given area, and the right side. If the given area is located at the left end of the tape, there is no left side area. If the given area is open on the right, there is no right side area.
+ </p>
</RT·section>
<RT·section>
<RT·name>The impossibility of recognizing an empty tape</RT·name>
- <p>
- <RT·term>Recognition</RT·term> is a process where a Turing Machine decides if a pattern is present on a tape solely by reading symbols found on the tape. No meta-information, such as a message communicating something about the area being examined or the nature of the program that wrote the symbols, can be taken into account.
- </p>
+ <RT·term>Recognition</RT·term> is a process where a Turing Machine decides if a pattern is present on a tape solely by reading symbols found on the tape. No meta-information, such as a message communicating something about the area being examined or the nature of the program that wrote the symbols, can be taken into account.
+ </p>
- <p>
- The active area partition of a tape only works for tapes that have at least one alphabet cell. As soon as a machine does its first write of an alphabet symbol, it is known the tape has at least one alphabet symbol. However, what if a tape of unknown status, whether completely empty or containing an alphabet cell, is mounted on a tape machine, and it is desired that the machine recognize if the tape is empty or has an alphabet cell? This is the equivalent problem of looking for the leftmost cell of an active area.
- </p>
+ The active area partition of a tape only works for tapes that have at least one alphabet cell. As soon as a machine does its first write of an alphabet symbol, it is known the tape has at least one alphabet symbol. However, what if a tape of unknown status, whether completely empty or containing an alphabet cell, is mounted on a tape machine, and it is desired that the machine recognize if the tape is empty or has an alphabet cell? This is the equivalent problem of looking for the leftmost cell of an active area.
+ </p>
- <p>
- Recognizing that a tape is empty is generally impossible. Suppose it were attempted, and a machine started scanning the tape rightward from the leftmost cell; for every cell that is discovered to be empty, the machine would have to scan further rightward to check for an alphabet cell. If the tape is truly empty, the recognizer would never stop scanning, so no decision would ever be rendered.
- </p>
+ Recognizing that a tape is empty is generally impossible. Suppose it were attempted, and a machine started scanning the tape rightward from the leftmost cell; for every cell that is discovered to be empty, the machine would have to scan further rightward to check for an alphabet cell. If the tape is truly empty, the recognizer would never stop scanning, so no decision would ever be rendered.
+ </p>
</RT·section>
<RT·section>
<RT·name>The impossibility of recognizing the rightmost cell of the active area</RT·name>
- <p>
- In general, a Turing Machine cannot step across a tape reading cells to recognize the rightmost cell of the active area, or equivalently, the leftmost cell of the right empty tail. Suppose a recognizer attempted this by starting in the active area and stepping right, and the machine discovered an empty cell. The machine would be unable to distinguish between the case of said empty cell being embedded within the active area (meaning more alphabet cells lie further to the right), or the case where said cell is genuinely the leftmost cell of the right tail. To resolve the ambiguity, the machine would be obligated to continue stepping right. Yet, there would never come a time where finding another empty cell would avoid leading back to the exact same case ambiguity, so the machine would forever step right without returning a decision.
- </p>
+ In general, a Turing Machine cannot step across a tape reading cells to recognize the rightmost cell of the active area, or equivalently, the leftmost cell of the right empty tail. Suppose a recognizer attempted this by starting in the active area and stepping right, and the machine discovered an empty cell. The machine would be unable to distinguish between the case of said empty cell being embedded within the active area (meaning more alphabet cells lie further to the right), or the case where said cell is genuinely the leftmost cell of the right tail. To resolve the ambiguity, the machine would be obligated to continue stepping right. Yet, there would never come a time where finding another empty cell would avoid leading back to the exact same case ambiguity, so the machine would forever step right without returning a decision.
+ </p>
- <p>
- It follows that if knowledge of the end of the active area is needed, this information must be encoded as a message. For example, a special symbol can be reserved in the alphabet specifically to serve as the end of active area marker. Each time a machine steps beyond the current end of active area marker and does a write, it writes the marker in the right neighbor cell, and goes back and erases the old mark. This method is related to communications theory and the science of signaling. Here, the active area marker is an out-of-band control signal.
- </p>
+ It follows that if knowledge of the end of the active area is needed, this information must be encoded as a message. For example, a special symbol can be reserved in the alphabet specifically to serve as the end of active area marker. Each time a machine steps beyond the current end of active area marker and does a write, it writes the marker in the right neighbor cell, and goes back and erases the old mark. This method is related to communications theory and the science of signaling. Here, the active area marker is an out-of-band control signal.
+ </p>
- <p>
- If a tape is written by an initializing tape machine, unmounted, and then mounted on a second analyzing tape machine, the analyzing tape machine is starting with a populated tape. Similarly, a mathematician can, by decree, define an initial tape that holds predefined alphabet symbols. In such a scenario, the initializing machine and the analyzing machine must use a shared communication protocol for signaling the end of the active area. They cannot operate independently or the analyzing machine would not be able to find the end of the active area. This shared protocol then represents information held by a mediator, said mediator could be used at a higher level to write the control for the two machines, or it could be consulted when the two machines are run. Hence, the mediator is either an author, or a service provider, or possibly both.
- </p>
+ If a tape is written by an initializing tape machine, unmounted, and then mounted on a second analyzing tape machine, the analyzing tape machine is starting with a populated tape. Similarly, a mathematician can, by decree, define an initial tape that holds predefined alphabet symbols. In such a scenario, the initializing machine and the analyzing machine must use a shared communication protocol for signaling the end of the active area. They cannot operate independently or the analyzing machine would not be able to find the end of the active area. This shared protocol then represents information held by a mediator, said mediator could be used at a higher level to write the control for the two machines, or it could be consulted when the two machines are run. Hence, the mediator is either an author, or a service provider, or possibly both.
+ </p>
- <p>
- By definition, a computation must finish in a finite number of steps. It follows that the active area when a Turing Machine halts a computation will always be finite. Consequently, if a Turing Machine initially starts working with a tape that was computed by another Turing Machine, the length of the input will be finite. Still, that input will be in the active area, so the receiving Turing Machine will need to read control data left on the tape under a common communication protocol to be able to find the bounds of the input area.
- </p>
+ By definition, a computation must finish in a finite number of steps. It follows that the active area when a Turing Machine halts a computation will always be finite. Consequently, if a Turing Machine initially starts working with a tape that was computed by another Turing Machine, the length of the input will be finite. Still, that input will be in the active area, so the receiving Turing Machine will need to read control data left on the tape under a common communication protocol to be able to find the bounds of the input area.
+ </p>
- <p>
- When an input tape is provided as a general mathematical object, either decreed by definition or perhaps abstracted from 'what a Turing Machine computation would produce in the limit of step-count', then the input can be either finite or infinite.
- </p>
+ When an input tape is provided as a general mathematical object, either decreed by definition or perhaps abstracted from 'what a Turing Machine computation would produce in the limit of step-count', then the input can be either finite or infinite.
+ </p>
</RT·section>
<RT·section>
<RT·name>In-band and out-of-band control</RT·name>
- <p>
- Because of the impossibility of recognizing certain tape features, when a tape is written by one Turing Machine, then used by another, there must be some sort of system for messaging control. There are two approaches for mixing data and control together: one is in-band signaling, while the other is out-of-band signaling.
- </p>
+ Because of the impossibility of recognizing certain tape features, when a tape is written by one Turing Machine, then used by another, there must be some sort of system for messaging control. There are two approaches for mixing data and control together: one is in-band signaling, while the other is out-of-band signaling.
+ </p>
- <p>
- <RT·term>In-band control</RT·term> occurs when control signals or structural metadata are mixed directly into the same channel and alphabet as the data payload. In-band signaling leads to ambiguities between what is control and what is data. As we saw, there are cases where a recognizer, i.e., merely examining the data, is completely incapable of resolving even the simplest of control questions. A conventional approach for resolving these ambiguities makes use of escape sequence schemes that grow in length as the levels of communication grow. This has always been an afterthought, a sort of hack.
- </p>
+ <RT·term>In-band control</RT·term> occurs when control signals or structural metadata are mixed directly into the same channel and alphabet as the data payload. In-band signaling leads to ambiguities between what is control and what is data. As we saw, there are cases where a recognizer, i.e., merely examining the data, is completely incapable of resolving even the simplest of control questions. A conventional approach for resolving these ambiguities makes use of escape sequence schemes that grow in length as the levels of communication grow. This has always been an afterthought, a sort of hack.
+ </p>
- <p>
- In contrast, <RT·term>out-of-band control</RT·term> communicates structural information through a strictly separate channel or by utilizing symbols definitively excluded from the programmer visible data alphabet. The rightmost tape marker is an out-of-band mechanism because it utilizes an expanded hardware tape alphabet strictly reserved for machine management, guaranteeing it can never be conflated with the user's data. Modern architectures often lack the luxury of inventing new symbols to serve as control rather than data. Another out-of-band signaling technique is to structure the data into channels; such structure is called <RT·term>formatting</RT·term>. We find formatting on hard drives, in frame based and packet based communication channels, and in data structures.
- </p>
+ In contrast, <RT·term>out-of-band control</RT·term> communicates structural information through a strictly separate channel or by utilizing symbols definitively excluded from the programmer visible data alphabet. The rightmost tape marker is an out-of-band mechanism because it utilizes an expanded hardware tape alphabet strictly reserved for machine management, guaranteeing it can never be conflated with the user's data. Modern architectures often lack the luxury of inventing new symbols to serve as control rather than data. Another out-of-band signaling technique is to structure the data into channels; such structure is called <RT·term>formatting</RT·term>. We find formatting on hard drives, in frame based and packet based communication channels, and in data structures.
+ </p>
</RT·section>
<RT·section>
<RT·name>Virtual cells</RT·name>
- <p>A given finite area that is not sitting on the end of the tape will have a left neighbor area and right neighbor area that are not in the area. If the given area is sitting on the end of the tape there will be no left neighbor area. If the area is open on the right, there will be no right neighbor area.</p>
+
<p>A given finite area that is not sitting on the end of the tape will have a left neighbor area and right neighbor area that are not in the area. If the given area is sitting on the end of the tape there will be no left neighbor area. If the area is open on the right, there will be no right neighbor area.</p>
- <p>Now imagine we define a Turing Machine such that when it steps right, it steps to the right neighbor area, and when it steps left, if there is a left area, it steps to that, otherwise it returns a <RT·code>left-of-leftmost</RT·code> symbol. The read instruction reads all of the cells in the area, and similarly the write instruction writes them all. Then for this machine the areas are virtual tape cells.
- </p>
+
<p>Now imagine we define a Turing Machine such that when it steps right, it steps to the right neighbor area, and when it steps left, if there is a left area, it steps to that, otherwise it returns a <RT·code>left-of-leftmost</RT·code> symbol. The read instruction reads all of the cells in the area, and similarly the write instruction writes them all. Then for this machine the areas are virtual tape cells.
+ </p>
- <p>An example of this from conventional computing is where memory is accessed in units of bytes, but a program works with units of words.</p>
+
<p>An example of this from conventional computing is where memory is accessed in units of bytes, but a program works with units of words.</p>
</RT·section>
<RT·section>
<RT·name>Virtual tape</RT·name>
- <p>As established, the Turing Machine head transport returns a distinct <RT·code>left-of-leftmost</RT·code> symbol when stepping left off the end of the tape. The programmed controller, the statement machine, then uses an arc defined specifically for this symbol. It is a distinct symbol that cannot be written to the tape.
- </p>
+
<p>As established, the Turing Machine head transport returns a distinct <RT·code>left-of-leftmost</RT·code> symbol when stepping left off the end of the tape. The programmed controller, the statement machine, then uses an arc defined specifically for this symbol. It is a distinct symbol that cannot be written to the tape.
+ </p>
- <p>Various portions of this text have mentioned calling a Turing Machine as a subroutine. This is described as unmounting the tape from the calling machine, mounting it on the subroutine machine, running the subroutine machine until it halts, then unmounting the tape from the subroutine machine, and mounting it back on the calling machine. However, this would be a manual process. To automate the process, we use a Universal Turing Machine. It has the definition for the calling machine and the subroutine machine on its tape. We can add an additional tape to the machine to hold the stack. Then a subroutine call happens much as it does in conventional software.
- </p>
+
<p>Various portions of this text have mentioned calling a Turing Machine as a subroutine. This is described as unmounting the tape from the calling machine, mounting it on the subroutine machine, running the subroutine machine until it halts, then unmounting the tape from the subroutine machine, and mounting it back on the calling machine. However, this would be a manual process. To automate the process, we use a Universal Turing Machine. It has the definition for the calling machine and the subroutine machine on its tape. We can add an additional tape to the machine to hold the stack. Then a subroutine call happens much as it does in conventional software.
+ </p>
- <p>A gasket machine is actually a set of subroutines with one corresponding to each of the tape transport instructions.
- </p>
+
<p>A gasket machine is actually a set of subroutines with one corresponding to each of the tape transport instructions.
+ </p>
- <p>
- There is a small problem, in that the <RT·code>left-of-leftmost</RT·code> symbol was stipulated as being separate from the alphabet, and only alphabet symbols and the empty symbol can be written to the tape. There are a couple of possible solutions. One solution is to add a symbol to the alphabet that is also taken to mean 'left of leftmost', say <RT·code>gasket-left-of-leftmost</RT·code>. Then machines that make use of gaskets can recognize this new symbol for its meaning. Another alternative, that will be used for the remainder of our discussion, is to define a separate control alphabet of symbols that are distinct from data alphabet symbols, but can also be written and read from the tape. We will add to this alphabet, <RT·code>empty</RT·code>, <RT·code>left-of-leftmost</RT·code>, and a new control symbol used by gaskets,<RT·code>right-of-rightmost</RT·code>.
- </p>
+ There is a small problem, in that the <RT·code>left-of-leftmost</RT·code> symbol was stipulated as being separate from the alphabet, and only alphabet symbols and the empty symbol can be written to the tape. There are a couple of possible solutions. One solution is to add a symbol to the alphabet that is also taken to mean 'left of leftmost', say <RT·code>gasket-left-of-leftmost</RT·code>. Then machines that make use of gaskets can recognize this new symbol for its meaning. Another alternative, that will be used for the remainder of our discussion, is to define a separate control alphabet of symbols that are distinct from data alphabet symbols, but can also be written and read from the tape. We will add to this alphabet, <RT·code>empty</RT·code>, <RT·code>left-of-leftmost</RT·code>, and a new control symbol used by gaskets,<RT·code>right-of-rightmost</RT·code>.
+ </p>
- <p>Now suppose defining a Turing Machine that initially has the head on the leftmost cell of a specific area. When step left is called, the tape transport immediately returns the left of leftmost symbol, independent of whether the area is actually at the physical left end of the tape or not.
- </p>
+
<p>Now suppose defining a Turing Machine that initially has the head on the leftmost cell of a specific area. When step left is called, the tape transport immediately returns the left of leftmost symbol, independent of whether the area is actually at the physical left end of the tape or not.
+ </p>
- <p>
-Now suppose defining a Turing Machine that initially has the head on the leftmost cell of a specific area. When step left is called, the tape transport immediately returns the left of leftmost symbol, independent of whether the area is actually at the physical left end of the tape or not.
- </p>
+ Now suppose defining a Turing Machine that initially has the head on the leftmost cell of a specific area. When step left is called, the tape transport immediately returns the left of leftmost symbol, independent of whether the area is actually at the physical left end of the tape or not.
+ </p>
- <p>Suppose further that this area is finite. If the machine attempts to step right from the rightmost cell of this finite area, the tape transport returns, in analogy, <RT·code>right-from-rightmost</RT·code> symbol. Such a machine defines a virtual tape over an area.
- </p>
+
<p>Suppose further that this area is finite. If the machine attempts to step right from the rightmost cell of this finite area, the tape transport returns, in analogy, <RT·code>right-from-rightmost</RT·code> symbol. Such a machine defines a virtual tape over an area.
+ </p>
</RT·section>
<RT·section>
<RT·name>Partitions on a finite virtual tape</RT·name>
- <p>
- 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>
+ 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>
- <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·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>
+ <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>
<RT·section>
<RT·name>Address defined area</RT·name>
- <p>We defined a tape as having a single feature, that of a leftmost cell, along with a linear neighbor topology. When a tape is mounted it gains a second feature, that of the cell the head is on. The leftmost cell was fixed in place, while any other single cell on the tape can be featured as the cell the head is on. When we introduced areas, we picked up two new features, that of the leftmost cell of the area, and the rightmost cell of the area. Again, those features could coincide with the former features. We noted that the features partitioned a tape thus defining more areas, and more features.
- </p>
+
<p>We defined a tape as having a single feature, that of a leftmost cell, along with a linear neighbor topology. When a tape is mounted it gains a second feature, that of the cell the head is on. The leftmost cell was fixed in place, while any other single cell on the tape can be featured as the cell the head is on. When we introduced areas, we picked up two new features, that of the leftmost cell of the area, and the rightmost cell of the area. Again, those features could coincide with the former features. We noted that the features partitioned a tape thus defining more areas, and more features.
+ </p>
- <p>
- When cells were defined we noted that they were sets, and that these sets had identity and could be referred to. We needed that to be the case so as to build the tape topology using neighbor properties. Had the tape been singly linked, perhaps we could have used the cells to represent themselves in the properties, but when we doubly linked it, a given cell had to appear in two places, as the right neighbor of its left neighbor, and the left neighbor of its right neighbor, so we stipulated the sets as being identifiable. Initially we did not say how they would be identified. This is common in mathematics, but we soon cleared this up by formalizing the concept of a symbol.
- </p>
+ When cells were defined we noted that they were sets, and that these sets had identity and could be referred to. We needed that to be the case so as to build the tape topology using neighbor properties. Had the tape been singly linked, perhaps we could have used the cells to represent themselves in the properties, but when we doubly linked it, a given cell had to appear in two places, as the right neighbor of its left neighbor, and the left neighbor of its right neighbor, so we stipulated the sets as being identifiable. Initially we did not say how they would be identified. This is common in mathematics, but we soon cleared this up by formalizing the concept of a symbol.
+ </p>
- <p>
- When discussing symbols we noted they could be Natural Numbers, and even went so far as to point out that addresses were symbols, though we had not yet defined them. They are familiar to anyone involved in computing, so again, it did not present a serious problem. Here we have now formalized them.
- </p>
+ When discussing symbols we noted they could be Peano Numbers, and even went so far as to point out that addresses were symbols, though we had not yet defined them. They are familiar to anyone involved in computing, so again, it did not present a serious problem. Here we have now formalized them.
+ </p>
- <p>
- 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>
+ 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 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>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.
- </p>
+ <p>With addresses we can now define an area with two addresses, two Peano Numbers, the address of the leftmost cell, and that of the rightmost cell. All Peano 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.
+ </p>
</RT·section>
<RT·section>
<RT·name>Distance and extent</RT·name>
- <p>The <RT·term>distance</RT·term> between two cells is the absolute difference in their addresses. When we talk about the distance between the leftmost cell of an area and the rightmost cell of an area, we call this number the area's <RT·neologism>extent</RT·neologism>.</p>
+
<p>The <RT·term>distance</RT·term> between two cells is the absolute difference in their addresses. When we talk about the distance between the leftmost cell of an area and the rightmost cell of an area, we call this number the area's <RT·neologism>extent</RT·neologism>.</p>
- <p>In an analogous manner to defining an address space for a tape, we can define an address space for an area. Accordingly, the leftmost cell of the area is assigned address zero, and the address increments cell by cell going to the right. A finite area will have a finite address space, with the address of the rightmost cell being the largest address in the address space.
- </p>
+
<p>In an analogous manner to defining an address space for a tape, we can define an address space for an area. Accordingly, the leftmost cell of the area is assigned address zero, and the address increments cell by cell going to the right. A finite area will have a finite address space, with the address of the rightmost cell being the largest address in the address space.
+ </p>
- <p>It is interesting that the extent of an area will be the same, whether it is calculated from the address space of the tape, or the address space of the area. In fact, the extent will always be identical to the largest address in the address space. We will use the Greek symbol omega, <RT·math>\omega</RT·math>, to symbolize an extent. We can give it a subscript with the name of an area if the correspondence is not already clear. The choice of <RT·math>\omega</RT·math> makes sense here because <RT·math>\omega</RT·math> is an inclusive bound, i.e. it is the rightmost letter included in the Greek alphabet. Thus it is the extent of the Greek alphabet.
- </p>
+
<p>It is interesting that the extent of an area will be the same, whether it is calculated from the address space of the tape, or the address space of the area. In fact, the extent will always be identical to the largest address in the address space. We will use the Greek symbol omega, <RT·math>\omega</RT·math>, to symbolize an extent. We can give it a subscript with the name of an area if the correspondence is not already clear. The choice of <RT·math>\omega</RT·math> makes sense here because <RT·math>\omega</RT·math> is an inclusive bound, i.e. it is the rightmost letter included in the Greek alphabet. Thus it is the extent of the Greek alphabet.
+ </p>
</RT·section>
<RT·section>
<RT·name>Length</RT·name>
- <p>If cells in an area are transacted, the cost of the area is the cost of a cell multiplied by the count of cells. Vincent Atanasoff probably found himself needing to know such a count when ordering capacitors. The count of cells in an area is also known as the area's <RT·term>length</RT·term>. We will use the Greek symbol <RT·math>ϡ</RT·math>, pronounced as sampi, to refer to the length. The length of an area, the count of its cells, will always be one greater than its extent, <RT·math>ϡ = \omega + 1</RT·math>. This symbol makes sense here, as the Greek number system fell short of letters, so the symbol <RT·math>ϡ</RT·math> was tacked on to the end of the alphabet, but did not belong to the alphabet.
- </p>
+
<p>If cells in an area are transacted, the cost of the area is the cost of a cell multiplied by the count of cells. Vincent Atanasoff probably found himself needing to know such a count when ordering capacitors. The count of cells in an area is also known as the area's <RT·term>length</RT·term>. We will use the Greek symbol <RT·math>ϡ</RT·math>, pronounced as sampi, to refer to the length. The length of an area, the count of its cells, will always be one greater than its extent, <RT·math>ϡ = \omega + 1</RT·math>. This symbol makes sense here, as the Greek number system fell short of letters, so the symbol <RT·math>ϡ</RT·math> was tacked on to the end of the alphabet, but did not belong to the alphabet.
+ </p>
- <p>The count of cells in an area, the length of an area, and the cardinality of the address space for an area are all the same number, <RT·math>ϡ</RT·math>. The extent of an area, <RT·math>\omega</RT·math>, is an address in an area's address space, whereas the cardinality of an area, <RT·math>ϡ</RT·math>, falls outside it. This has implications. Because extent is an address, extent and addresses can always use the same number representation. In contrast, there is no such guarantee for cardinality, <RT·math>ϡ</RT·math>. Take for example an area that contains 256 cells. The addresses run from zero to 255, and all can be represented with an 8 bit binary number. However, the number 256 requires 9 bits, and thus would not fit in an 8 bit address register. This one of the reasons that code will have fewer end-case problems when expressing the size of objects with extents, rather than with lengths.
- </p>
+
<p>The count of cells in an area, the length of an area, and the cardinality of the address space for an area are all the same number, <RT·math>ϡ</RT·math>. The extent of an area, <RT·math>\omega</RT·math>, is an address in an area's address space, whereas the cardinality of an area, <RT·math>ϡ</RT·math>, falls outside it. This has implications. Because extent is an address, extent and addresses can always use the same number representation. In contrast, there is no such guarantee for cardinality, <RT·math>ϡ</RT·math>. Take for example an area that contains 256 cells. The addresses run from zero to 255, and all can be represented with an 8 bit binary number. However, the number 256 requires 9 bits, and thus would not fit in an 8 bit address register. This one of the reasons that code will have fewer end-case problems when expressing the size of objects with extents, rather than with lengths.
+ </p>
</RT·section>
<RT·section>
- <RT·name>Is the cardinality of an open on the right area a Natural Number?</RT·name>
+ <RT·name>Is the cardinality of an open on the right area a Peano Number?</RT·name>
- <p>So we find an interesting situation with the cardinality of an address space for an area that is open on the right. It goes like this.</p>
+
<p>So we find an interesting situation with the cardinality of an address space for an area that is open on the right. It goes like this.</p>
<RT·section>
<RT·name>How cardinality is computed</RT·name>
- <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·counter·step counter="RT·List·counter" id="List·cardinality_procedure">
+ <RT·counter·snapshot counter="RT·List·counter" snapshot="List·cardinality_procedure"></RT·counter·snapshot>
+ <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>
<RT·section>
- <RT·name>Lemma 1, the A machine produces Natural Numbers</RT·name>
+ <RT·name>Lemma 1, the A machine produces Peano Numbers</RT·name>
- <p>This follows from its definition; it is literally the increment from the Natural Numbers Machine.</p>
+ <p>This follows from its definition; it is literally the increment from the Peano Numbers Machine.</p>
</RT·section>
<RT·section>
- <RT·name>Lemma 2, cardinality is a Natural Number</RT·name>
+ <RT·name>Lemma 2, cardinality is a Peano Number</RT·name>
- <p>Cardinality is produced by repeatedly calling the <RT·math>A</RT·math> machine, and the <RT·math>A</RT·math> machine produces Natural Numbers.</p>
+ <p>Cardinality is produced by repeatedly calling the <RT·math>A</RT·math> machine, and the <RT·math>A</RT·math> machine produces Peano Numbers.</p>
</RT·section>
<RT·section>
<RT·name>Lemma 3, cardinality is not in the address space</RT·name>
- <p>At the end of the second step in the procedure for producing the cardinality, the tape of the <RT·math>A</RT·math> machine held the extent of the address space. Then in step 3, <RT·math>A</RT·math> was called again, thus leaving a number one larger than the extent on its tape. The extent is the largest number in the address space, hence cardinality is larger than all numbers in the address space. Thus cardinality is not in the address space.</p>
+
<p>At the end of the second step in the procedure for producing the cardinality, the tape of the <RT·math>A</RT·math> machine held the extent of the address space. Then in step 3, <RT·math>A</RT·math> was called again, thus leaving a number one larger than the extent on its tape. The extent is the largest number in the address space, hence cardinality is larger than all numbers in the address space. Thus cardinality is not in the address space.</p>
</RT·section>
<RT·section>
- <RT·name>Lemma 4, the address space of an open on the right area is identical to the Natural Numbers.</RT·name>
+ <RT·name>Lemma 4, the address space of an open on the right area is identical to the Peano Numbers.</RT·name>
- <p>Composing the <RT·math>A</RT·math> machine with an unterminated loop call, where each result is written to a tape with a terminator between entries, results in the same machine as the Natural Numbers Machine.</p>
+ <p>Composing the <RT·math>A</RT·math> machine with an unterminated loop call, where each result is written to a tape with a terminator between entries, results in the same machine as the Peano Numbers Machine.</p>
</RT·section>
<RT·section>
<RT·name>The apparent contradiction.</RT·name>
- <p>By Lemma 2, cardinality is a Natural Number. By Lemma 3 cardinality is not in the address space. By Lemma 4 the address space is identical to the Natural Numbers.</p>
+ <p>By Lemma 2, cardinality is a Peano Number. By Lemma 3 cardinality is not in the address space. By Lemma 4 the address space is identical to the Peano Numbers.</p>
</RT·section>
<RT·section>
<RT·name>Resolution</RT·name>
- <p>The resolution lies in the computational reality of Step 2. For an area that is open on the right, the stepping of machine <RT·math>P</RT·math> never halts. Because Step 2 never terminates, Step 3 is never executed. The <RT·math>A</RT·math> machine never runs that final, additional time. Therefore, the cardinality of an open area is never actually produced by the machine. In the language of Computational Naturalism, Lemma 2 is false for an infinite area; the cardinality of an open on the right area is excluded from being a Natural Number because a Natural Number Machine cannot reach it in the first-order.</p>
+ <p>The resolution lies in the computational reality of Step 2. For an area that is open on the right, the stepping of machine <RT·math>P</RT·math> never halts. Because Step 2 never terminates, Step 3 is never executed. The <RT·math>A</RT·math> machine never runs that final, additional time. Therefore, the cardinality of an open area is never actually produced by the machine. In the language of Computational Naturalism, Lemma 2 is false for an infinite area; the cardinality of an open on the right area is excluded from being a Peano Number because a Peano Number Machine cannot reach it in the first-order.</p>
- <p>So then can we add a property to cardinality, such that a second-order analysis could use this property to continue downstream analysis? In short we could say that cardinality has no first-order value, but it has a second-order one. This is analogous to inventing a new type of number, analogous to a complex number with a second component. I.e., there is no 'real' solution, but there is an 'imaginary' one. Or analogous to error algebra, where a number value is replaced with a rule on how to handle downstream operations when it is given as an input.
- </p>
+
<p>So then can we add a property to cardinality, such that a second-order analysis could use this property to continue downstream analysis? In short we could say that cardinality has no first-order value, but it has a second-order one. This is analogous to inventing a new type of number, analogous to a complex number with a second component. I.e., there is no 'real' solution, but there is an 'imaginary' one. Or analogous to error algebra, where a number value is replaced with a rule on how to handle downstream operations when it is given as an input.
+ </p>
- <p>Such a value would be a new Turing Machine, one that composes a call to the never halting Natural Number machine followed by an increment operation. It cannot be run, but it perfectly explains the situation to an analyst. Perhaps we name this machine <RT·math>\aleph_0</RT·math>.
- </p>
+ <p>Such a value would be a new Turing Machine, one that composes a call to the never halting Peano Number machine followed by an increment operation. It cannot be run, but it perfectly explains the situation to an analyst. Perhaps we name this machine <RT·math>\aleph_0</RT·math>.
+ </p>
</RT·section>
<RT·section>
<RT·name>What if extent was used instead of cardinality?</RT·name>
- <p>
- Had extent been used instead of cardinality, we would lack the final increment step in the three step computing procedure. However, step 2 still cannot complete. Rather than a value, the result of the second-order analysis would be a machine that produces ever larger Natural Numbers. We can call this machine <RT·math>\aleph_{-1}</RT·math>.
- </p>
+ Had extent been used instead of cardinality, we would lack the final increment step in the three step computing procedure. However, step 2 still cannot complete. Rather than a value, the result of the second-order analysis would be a machine that produces ever larger Peano Numbers. We can call this machine <RT·math>\aleph_{-1}</RT·math>.
+ </p>
- <p>
- Now here is an interesting result:
- </p>
+ Now here is an interesting result:
+ </p>
- <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>
+ <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.
- </p>
+ Neither machine can be run. However we can compose the two machines, then simplify the composition. When we do so, the ever larger Peano Number machines annihilate each other, and the increment machine remains. The increment machine can be run, so we end up with an output value.
+ </p>
</RT·section>
<RT·section>
<RT·name>Size</RT·name>
- <p>Consider the case of a partitioned tape. Then consider that we write a gasket, such that we have a higher level Turing Machine that considers each of the areas of the partition as a cell. So then, initially the Turing Machine starts with its head on the leftmost area, stepping right steps to the right neighbor area etc. In this manner we abstract the concept of a cell to areas. A length then becomes a count of areas; however the <RT·term>size</RT·term> remains a count of the cells. Something similar is done in the C language, where the length of an array is a count of the elements in the array, but the size of the array is a count of bytes. A byte being an addressable unit in physical memory, and thus the underlying <em>cell</em> that everything is built up from.</p>
+
<p>Consider the case of a partitioned tape. Then consider that we write a gasket, such that we have a higher level Turing Machine that considers each of the areas of the partition as a cell. So then, initially the Turing Machine starts with its head on the leftmost area, stepping right steps to the right neighbor area etc. In this manner we abstract the concept of a cell to areas. A length then becomes a count of areas; however the <RT·term>size</RT·term> remains a count of the cells. Something similar is done in the C language, where the length of an array is a count of the elements in the array, but the size of the array is a count of bytes. A byte being an addressable unit in physical memory, and thus the underlying <em>cell</em> that everything is built up from.</p>
</RT·section>
</RT·section>
<RT·section>
- <RT·name>Natural Number</RT·name>
+ <RT·name>Peano Number</RT·name>
<RT·section>
<RT·name>Unary representation</RT·name>
- <p>
- A person can define a Turing Machine that is identical to the recursive definition of Natural Numbers as given by Peano. <RT·endnote>Giuseppe Peano, <em>Arithmetices principia, nova methodo exposita</em> (Turin: Fratres Bocca, 1889).</RT·endnote> If a person were to run the Natural Number Machine and observe as it writes to the tape, that person would watch as the Natural Numbers are printed one after another: '·s·ss·sss·ssss· ...'. Here '·' represents zero, and 's·' represents one, etc. Because the Natural Number Machine never halts, the machine cannot be used to initialize a tape, but an analyzer can evaluate the machine to make conclusions about what it would write if it were run.
- </p>
+ A person can define a Turing Machine that is identical to the recursive definition of Peano Numbers as given by Peano. <RT·endnote>Giuseppe Peano, <em>Arithmetices principia, nova methodo exposita</em> (Turin: Fratres Bocca, 1889).</RT·endnote> If a person were to run the Peano Number Machine and observe as it writes to the tape, that person would watch as the Peano Numbers are printed one after another: '·s·ss·sss·ssss· ...'. Here '·' represents zero, and 's·' represents one, etc. Because the Peano Number Machine never halts, the machine cannot be used to initialize a tape, but an analyzer can evaluate the machine to make conclusions about what it would write if it were run.
+ </p>
- <p>
- In contrast, a function extension version of the Natural Number sequence generator can be run. The function extension machine would be given as input a prior function extension result, or an initial empty tape. It would then modify the tape to contain the next Natural Number, as per the sequence that the Natural Number machine would write, if it could be run. This is accomplished through two subroutine calls: <RT·code>find_empty</RT·code> and <RT·code>increment</RT·code>. The <RT·code>find_empty</RT·code> machine checks the symbol under the head. Upon finding it is not the empty symbol, the machine steps right and checks the next cell, repeating until it finds the empty symbol, whereupon it halts. The <RT·code>increment</RT·code> machine then writes an 's' onto the tape and halts. Recurrent calls to the Natural Number extender then produce a sequence of result tapes: <RT·code>[], [s], [ss], …</RT·code>. Similarly, a programmer can write a machine called <RT·code>decrement</RT·code>, though the programmer must note that decrementing can return the <RT·code>left-of-leftmost</RT·code> symbol.
- </p>
+ In contrast, a function extension version of the Peano Number sequence generator can be run. The function extension machine would be given as input a prior function extension result, or an initial empty tape. It would then modify the tape to contain the next Peano Number, as per the sequence that the Peano Number machine would write, if it could be run. This is accomplished through two subroutine calls: <RT·code>find_empty</RT·code> and <RT·code>increment</RT·code>. The <RT·code>find_empty</RT·code> machine checks the symbol under the head. Upon finding it is not the empty symbol, the machine steps right and checks the next cell, repeating until it finds the empty symbol, whereupon it halts. The <RT·code>increment</RT·code> machine then writes an 's' onto the tape and halts. Recurrent calls to the Peano Number extender then produce a sequence of result tapes: <RT·code>[], [s], [ss], …</RT·code>. Similarly, a programmer can write a machine called <RT·code>decrement</RT·code>, though the programmer must note that decrementing can return the <RT·code>left-of-leftmost</RT·code> symbol.
+ </p>
- <p>
- To say that Natural Number A is smaller than Natural Number B is to say that A would occur on the Natural Number Machine tape to the left of B, if the machine were run. Conversely, if B were said to be greater than A, that would mean B occurs further to the right. It is a simple matter for a programmer to write a decider machine for this. The decider is given two input tapes for the two numbers to compare, and it keeps a head on each. It then steps forward until neither head has an 's' under it. If empty symbols are found simultaneously on both tapes, then the two numbers are equal; otherwise, the number with an empty symbol under the head is the lesser number.
- </p>
+ To say that Peano Number A is smaller than Peano Number B is to say that A would occur on the Peano Number Machine tape to the left of B, if the machine were run. Conversely, if B were said to be greater than A, that would mean B occurs further to the right. It is a simple matter for a programmer to write a decider machine for this. The decider is given two input tapes for the two numbers to compare, and it keeps a head on each. It then steps forward until neither head has an 's' under it. If empty symbols are found simultaneously on both tapes, then the two numbers are equal; otherwise, the number with an empty symbol under the head is the lesser number.
+ </p>
- <p>
- As such, a person can assign a Natural Number to each cell of a given tape by using a mechanical procedure. Given a machine, say <RT·code>P</RT·code>, and an address machine, say <RT·code>A_P</RT·code>, each time <RT·code>P</RT·code> is stepped right, a call is made to run <RT·code>increment</RT·code> on <RT·code>A_P</RT·code>. Similarly, each time <RT·code>P</RT·code> is stepped left, a call is made to run <RT·code>decrement</RT·code> on <RT·code>A_P</RT·code>. In this manner the tape on <RT·code>A_P</RT·code> will always hold the address that machine <RT·code>P</RT·code>'s head is on.
- </p>
+ As such, a person can assign a Peano Number to each cell of a given tape by using a mechanical procedure. Given a machine, say <RT·code>P</RT·code>, and an address machine, say <RT·code>A_P</RT·code>, each time <RT·code>P</RT·code> is stepped right, a call is made to run <RT·code>increment</RT·code> on <RT·code>A_P</RT·code>. Similarly, each time <RT·code>P</RT·code> is stepped left, a call is made to run <RT·code>decrement</RT·code> on <RT·code>A_P</RT·code>. In this manner the tape on <RT·code>A_P</RT·code> will always hold the address that machine <RT·code>P</RT·code>'s head is on.
+ </p>
- <p>
- The Natural Number found on <RT·code>A_P</RT·code> is then called the address for the cell that machine <RT·code>P</RT·code>'s head is on. As each increment and decrement of the address is a constant-time operation, keeping the address of the cell the head is on is computationally inconsequential.
- </p>
+ The Peano Number found on <RT·code>A_P</RT·code> is then called the address for the cell that machine <RT·code>P</RT·code>'s head is on. As each increment and decrement of the address is a constant-time operation, keeping the address of the cell the head is on is computationally inconsequential.
+ </p>
- <p>
- An <RT·term>address space</RT·term> is a set of addresses for contiguous cells. The tape's address space is the set of addresses for all the cells on the tape. Typically the address of 0 is given to the leftmost among the contiguous cells.
- </p>
+ An <RT·term>address space</RT·term> is a set of addresses for contiguous cells. The tape's address space is the set of addresses for all the cells on the tape. Typically the address of 0 is given to the leftmost among the contiguous cells.
+ </p>
</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>
+
<p>Charles Burnett published a very interesting book about the translation of Hindu-Arabic mathematics in Europe during the Middle Ages <RT·endnote>Charles Burnett, <em>Numerals and Arithmetic in the Middle Ages</em> (Farnham: Ashgate Variorum, 2010). DOI: 10.33137/aestimatio.v9i0.25990.</RT·endnote>. He describes a 9th-century treatise on Hindu-Arabic arithmetic authored by Muḥammad ibn Mūsā al-Khwārizmī, where "al-Khwārizmī" indicated he was from Khwarazm in Central Asia. When this manuscript was translated into Latin in the 12th century, European translators approximated his name as Algoritmi or Algorismi, thus giving us the word algorithm. He notes that the Arabs called such numbers "Indian Numbers". Another chapter, "Why we read Arabic numerals backwards," shows that the <RT·term>little-endian</RT·term> and <RT·term>big-endian</RT·term> debate that has plagued programmers for decades has its origin in the Middle Ages <RT·endnote>Danny Cohen, "On Holy Wars and a Plea for Peace," <em>IEEE Computer</em> 14, no. 10 (October 1981): 48-54. DOI: 10.1109/C-M.1981.220208</RT·endnote>.</p>
- <p>The topological structure of a Hindue-Arabic representation is found embodied in a simple gear based machine called an odometer. Multiple geared wheels occur in a reticulated structure. Pushing a toggle advances the least-significant digit wheel by 36 degrees of rotation. The wheel has a peg in it, such that if it rolls past 9 back to 0, it pushes the toggle on the next wheel in the reticulation sequence. The peg of the last wheel rotates through a toggle that raises the overflow error flag. By its very construction, this process establishes a one-to-one correspondence between each Natural Number and a sequence of symbols in Arabic Representation.</p>
+ <p>The topological structure of a Hindue-Arabic representation is found embodied in a simple gear based machine called an odometer. Multiple geared wheels occur in a reticulated structure. Pushing a toggle advances the least-significant digit wheel by 36 degrees of rotation. The wheel has a peg in it, such that if it rolls past 9 back to 0, it pushes the toggle on the next wheel in the reticulation sequence. The peg of the last wheel rotates through a toggle that raises the overflow error flag. By its very construction, this process establishes a one-to-one correspondence between each Peano Number and a sequence of symbols in Arabic Representation.</p>
- <p>
- For this discussion, the Hindu-Arabic representation address is variable precision, so it will grow as the count becomes larger. The empty symbol will serve as the terminator.
- </p>
+ For this discussion, the Hindu-Arabic representation address is variable precision, so it will grow as the count becomes larger. The empty symbol will serve as the terminator.
+ </p>
- <p>
- For <RT·code>Hindu-Arabic_increment</RT·code>, the machine reads the cell under the head; upon finding a 0 or the terminator, it writes a 1 and halts. Upon finding a 1, it writes a 0, steps right, and repeats the procedure.
- </p>
+ 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·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 == □:
+ <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. 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>
-
- <p>
- For an <RT·math>n</RT·math> bit counter, the sequence of costs follows a pattern. Half of the increments evaluate one bit (costing 2 steps), a quarter evaluate two bits (costing 4 steps), an eighth evaluate three bits (costing 6 steps), and so forth, over the <RT·math>2^n - 1</RT·math> increments required to reach the maximum <RT·math>n</RT·math> bit count:
- </p>
-
- <RT·math> \sum_{k=1}^{n} 2k · 2^{n-k} = 2^{n+2} - 2n - 4</RT·math>
-
- <p>
- To find the average cost per increment to reach each maximum, an analyst divides by the total number of increments, which is <RT·math>2^n - 1</RT·math>:
- </p>
-
- <RT·math> \text{Average Cost} = \frac{2^{n+2} - 2n - 4}{2^n - 1} = \frac{4(2^n-1)+4-2n-4}{2^n-1}</RT·math>
-
- <p>
- This simplifies algebraically to:
- </p>
-
- <RT·math> \text{Average Cost} = 4 - \frac{2n}{2^n - 1} </RT·math>
-
- <p>
- As the address space grows, the bit width <RT·math>n</RT·math> increases. The polynomial term <RT·math>2n</RT·math> is outpaced by the exponential denominator <RT·math>2^n - 1</RT·math>, causing the fractional terms to converge to zero. The average work done by the machine head converges to exactly four tape actions per increment. constant-time, same as for unary. This is a surprising counter intuitive result.
- </p>
-
- <p>
- Consequently, maintaining an Hindu-Arabic address on a secondary Address Machine remains a constant-time operation in the amortized sense, making it computationally inconsequential to the complexity class of the base machine. However, if a problem were to increment and decrement repeatedly around a binary power count, the behavior would be the limiting logarithmic time due to the length of the counter. An unlucky situation like this is called <RT·term>aliasing</RT·term>.
- </p>
+ 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 Peano 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>
+
+ 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 -->
+ <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>
+
+ 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>
+
+ For an <RT·math>n</RT·math> bit counter, the sequence of costs follows a pattern. Half of the increments evaluate one bit (costing 2 steps), a quarter evaluate two bits (costing 4 steps), an eighth evaluate three bits (costing 6 steps), and so forth, over the <RT·math>2^n - 1</RT·math> increments required to reach the maximum <RT·math>n</RT·math> bit count:
+ </p>
+
+ <RT·math> \sum_{k=1}^{n} 2k · 2^{n-k} = 2^{n+2} - 2n - 4</RT·math>
+
+ To find the average cost per increment to reach each maximum, an analyst divides by the total number of increments, which is <RT·math>2^n - 1</RT·math>:
+ </p>
+
+ <RT·math> \text{Average Cost} = \frac{2^{n+2} - 2n - 4}{2^n - 1} = \frac{4(2^n-1)+4-2n-4}{2^n-1}</RT·math>
+
+ This simplifies algebraically to:
+ </p>
+
+ <RT·math> \text{Average Cost} = 4 - \frac{2n}{2^n - 1} </RT·math>
+
+ As the address space grows, the bit width <RT·math>n</RT·math> increases. The polynomial term <RT·math>2n</RT·math> is outpaced by the exponential denominator <RT·math>2^n - 1</RT·math>, causing the fractional terms to converge to zero. The average work done by the machine head converges to exactly four tape actions per increment. constant-time, same as for unary. This is a surprising counter intuitive result.
+ </p>
+
+ Consequently, maintaining an Hindu-Arabic address on a secondary Address Machine remains a constant-time operation in the amortized sense, making it computationally inconsequential to the complexity class of the base machine. However, if a problem were to increment and decrement repeatedly around a binary power count, the behavior would be the limiting logarithmic time due to the length of the counter. An unlucky situation like this is called <RT·term>aliasing</RT·term>.
+ </p>
</RT·section>
<RT·section>
<RT·name>The Computability of Length and Unbounded Zeros</RT·name>
- <p>Consider the proposition of representing Natural Numbers with an unbounded sequence of leftward-trailing zero symbols, extending from the leftmost nonzero digit. If a Turing Machine attempts to evaluate the length of this number, or append a digit to the left of its most-significant digit, the machine encounters a structural failure. Any algorithm that starts at the right of the sequence (the least-significant digit) and scans leftward in search of the last non-zero digit can never be sure at any step that there isn't another non-zero digit further to the left, as those members of the sequence have not yet been examined.</p>
+ <p>Consider the proposition of representing Peano Numbers with an unbounded sequence of leftward-trailing zero symbols, extending from the leftmost nonzero digit. If a Turing Machine attempts to evaluate the length of this number, or append a digit to the left of its most-significant digit, the machine encounters a structural failure. Any algorithm that starts at the right of the sequence (the least-significant digit) and scans leftward in search of the last non-zero digit can never be sure at any step that there isn't another non-zero digit further to the left, as those members of the sequence have not yet been examined.</p>
- <p>Thus, an append function can never know where to write the appended digit, and a length function can never know when to end the count. Because these functions cannot be computed locally on a tape initialized with unbounded zeros, the viable Arabic Representation must strictly be a finite, growing sequence rather than an unbounded string of zeros. If an algorithm attempts to access an index greater than the extent of this finite sequence, the access function fails. This failure is itself a form of meta-information—information about the structure of the representation rather than the number it encodes.</p>
+
<p>Thus, an append function can never know where to write the appended digit, and a length function can never know when to end the count. Because these functions cannot be computed locally on a tape initialized with unbounded zeros, the viable Arabic Representation must strictly be a finite, growing sequence rather than an unbounded string of zeros. If an algorithm attempts to access an index greater than the extent of this finite sequence, the access function fails. This failure is itself a form of meta-information—information about the structure of the representation rather than the number it encodes.</p>
</RT·section>
<RT·section>
<RT·name>The Representation of Zero and Structural Emptiness</RT·name>
- <p>In the growing Arabic representation, counting acts as a mechanical mechanism. In the case of zero, before the first increment, the mechanism has not yet encountered a carry-in. At this stage, no digits have materialized in the representation. Any attempt to retrieve a digit in this state results in an access violation.</p>
-
- <p>This reveals a fundamental property of Arabic Representation: it encodes both the sequence of digit symbols (which map to a Natural Number) and the sequence's length (which exists at a meta level, governing computational operations). The representation of zero exposes a limitation. At zero, the representation retains length information necessary for computation but lacks an explicit numerical mapping to zero itself.</p>
-
- <p>Structurally, this forces a design choice between two options:</p>
- <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>In the growing Arabic representation, counting acts as a mechanical mechanism. In the case of zero, before the first increment, the mechanism has not yet encountered a carry-in. At this stage, no digits have materialized in the representation. Any attempt to retrieve a digit in this state results in an access violation.</p>
+
+ <p>This reveals a fundamental property of Arabic Representation: it encodes both the sequence of digit symbols (which map to a Peano 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>
+ <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>
+ <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>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>
</RT·section>
<RT·section>
<RT·name>Numeric value</RT·name>
- <p>An Hindu-Arabic number consists of a sequence of digits, <RT·math>d_0 d_1 d_2 \ldots</RT·math> where, in base 10, each digit has a value ranging from 0 to 9. In this section, these sequences are represented using sequence notation. For example, <RT·math>X = [7, 8, 9]</RT·math> is a sequence with three components. Its zero index component, <RT·math>x_0</RT·math>, is 7, etc. Note that <RT·math>X</RT·math> is written as a capital letter to denote that it is a container, while its individual members use small letters.</p>
+
<p>An Hindu-Arabic number consists of a sequence of digits, <RT·math>d_0 d_1 d_2 \ldots</RT·math> where, in base 10, each digit has a value ranging from 0 to 9. In this section, these sequences are represented using sequence notation. For example, <RT·math>X = [7, 8, 9]</RT·math> is a sequence with three components. Its zero index component, <RT·math>x_0</RT·math>, is 7, etc. Note that <RT·math>X</RT·math> is written as a capital letter to denote that it is a container, while its individual members use small letters.</p>
- <p>A person interprets these sequences as numbers by using a weighted sum.</p>
+
<p>A person interprets these sequences as numbers by using a weighted sum.</p>
- <RT·math>a = \sum_{i=0}^n x_i \cdot ten^i</RT·math>
+ <RT·math>a = \sum_{i=0}^n x_i \cdot ten^i</RT·math>
- <p>Here <RT·math>a</RT·math> is a numeric value, so it is written in lower case. Each <RT·math>x_i</RT·math> is the <RT·math>i</RT·math>th component of the sequence <RT·math>X</RT·math>. The value <RT·math>x_i</RT·math> is also known as the '<RT·math>i</RT·math>th digit' of the number. The value ten is called the base or the radix of the number. It is fortunate that ten is so well known that it has a name, because otherwise an author is tempted to write the base while using the exact representation that he is trying to define. Although this function gives numeric meaning to our digit sequences, performing the suggested computation is pointless. The result is a number, and a person must represent that number, resulting in the exact sequence that was given as the input to the function in the first place.</p>
+
<p>Here <RT·math>a</RT·math> is a numeric value, so it is written in lower case. Each <RT·math>x_i</RT·math> is the <RT·math>i</RT·math>th component of the sequence <RT·math>X</RT·math>. The value <RT·math>x_i</RT·math> is also known as the '<RT·math>i</RT·math>th digit' of the number. The value ten is called the base or the radix of the number. It is fortunate that ten is so well known that it has a name, because otherwise an author is tempted to write the base while using the exact representation that he is trying to define. Although this function gives numeric meaning to our digit sequences, performing the suggested computation is pointless. The result is a number, and a person must represent that number, resulting in the exact sequence that was given as the input to the function in the first place.</p>
- <p>In many contexts, a person drops the container notation without causing ambiguity. Conventionally, dropping the notation reverses the order of the components. The sequence from the prior example, <RT·math>X = [7, 8, 9]</RT·math>, becomes <RT·math>x = 987</RT·math>. To be clear, note that this number is 13 away from a thousand.</p>
+
<p>In many contexts, a person drops the container notation without causing ambiguity. Conventionally, dropping the notation reverses the order of the components. The sequence from the prior example, <RT·math>X = [7, 8, 9]</RT·math>, becomes <RT·math>x = 987</RT·math>. To be clear, note that this number is 13 away from a thousand.</p>
- <p>Independent of whether the number is represented with or without the bracket decoration, its most-significant digit is the one with the greatest weight. In this example, it is the digit with the value 9, i.e., <RT·math>x_2</RT·math>. Analogously, the least-significant digit is 7, i.e., <RT·math>x_0</RT·math>. Using a term from the previous chapter on arrays, the extent of our example number is 2. The digit count, or length, of this number is 3.</p>
+
<p>Independent of whether the number is represented with or without the bracket decoration, its most-significant digit is the one with the greatest weight. In this example, it is the digit with the value 9, i.e., <RT·math>x_2</RT·math>. Analogously, the least-significant digit is 7, i.e., <RT·math>x_0</RT·math>. Using a term from the previous chapter on arrays, the extent of our example number is 2. The digit count, or length, of this number is 3.</p>
</RT·section>
<RT·section>
<RT·name>Meaning of the word digital</RT·name>
- <p>The information about ENIAC in this chapter is found in a 1947 IRE article, "Electronic Computing Circuits of the ENIAC" by Arthur W. Burks <RT·endnote>Arthur W. Burks, "Electronic Computing Circuits of the ENIAC," <em>Proceedings of the IRE</em> 35, no. 8 (August 1947): 756-767. DOI: 10.1109/JRPROC.1947.234265</RT·endnote>. I found it interesting that some of the design issues for flip-flops made of vacuum tubes resemble those of designing static RAM cells in CMOS. Although ENIAC's implementation is electronic, its architecture is fundamentally that of a mechanical machine.</p>
+
<p>The information about ENIAC in this chapter is found in a 1947 IRE article, "Electronic Computing Circuits of the ENIAC" by Arthur W. Burks <RT·endnote>Arthur W. Burks, "Electronic Computing Circuits of the ENIAC," <em>Proceedings of the IRE</em> 35, no. 8 (August 1947): 756-767. DOI: 10.1109/JRPROC.1947.234265</RT·endnote>. I found it interesting that some of the design issues for flip-flops made of vacuum tubes resemble those of designing static RAM cells in CMOS. Although ENIAC's implementation is electronic, its architecture is fundamentally that of a mechanical machine.</p>
- <p>The first computing machines which performed discrete state computation made use of ten symbols for a digit’s potential values while mimicking how humans perform manual arithmetic. Examples include Pascal’s calculator, Babbage’s machine, the mechanical calculators that came after, Aiken’s Mark computers, and ENIAC.</p>
+
<p>The first computing machines which performed discrete state computation made use of ten symbols for a digit’s potential values while mimicking how humans perform manual arithmetic. Examples include Pascal’s calculator, Babbage’s machine, the mechanical calculators that came after, Aiken’s Mark computers, and ENIAC.</p>
- <p>Mechanical machines used physical gears with ten positions, each being 36 degrees apart. An index, such as a metal pointer, pointed at one of the marks, indicating which digit value had been registered on the gear. To change which digit value was registered, the gear turned until the index pointed at the mark corresponding to the desired digit value. Instead of gears, the electronic computer ENIAC used circular shift registers of ten vacuum-tube flip-flops. These were called ring counters or decade counters. ENIAC operated on ten-digit signed numbers, so there were ten such ring counters plus a flip-flop for each number. It is structurally important that a person does not conflate the number of available digit values with the length of the digit sequence.</p>
+
<p>Mechanical machines used physical gears with ten positions, each being 36 degrees apart. An index, such as a metal pointer, pointed at one of the marks, indicating which digit value had been registered on the gear. To change which digit value was registered, the gear turned until the index pointed at the mark corresponding to the desired digit value. Instead of gears, the electronic computer ENIAC used circular shift registers of ten vacuum-tube flip-flops. These were called ring counters or decade counters. ENIAC operated on ten-digit signed numbers, so there were ten such ring counters plus a flip-flop for each number. It is structurally important that a person does not conflate the number of available digit values with the length of the digit sequence.</p>
- <p>Mechanical machines, such as Howard Aiken’s Mark machines, gated rotational momentum with control linkages and clutches. ENIAC used an electronic analogy to the main rotating shaft: a central pulse clock. Pulses were sent to an electronic gate, and if the control to that gate allowed it, the pulses passed through to the corresponding ring counters to cause each flip-flop in the ring to flip in succession depending on the pulse count.</p>
+
<p>Mechanical machines, such as Howard Aiken’s Mark machines, gated rotational momentum with control linkages and clutches. ENIAC used an electronic analogy to the main rotating shaft: a central pulse clock. Pulses were sent to an electronic gate, and if the control to that gate allowed it, the pulses passed through to the corresponding ring counters to cause each flip-flop in the ring to flip in succession depending on the pulse count.</p>
- <p>To add digit values on a mechanical computer, the two gears in question were mechanically connected. When one rotated back to zero, the other rotated up to the sum, possibly tipping a carry bar along the way. On ENIAC, one ring counter gated pulses to its partner while counting down. While pulses were gated to it, the second ring counter counted up, optionally setting a carry flip-flop.</p>
+
<p>To add digit values on a mechanical computer, the two gears in question were mechanically connected. When one rotated back to zero, the other rotated up to the sum, possibly tipping a carry bar along the way. On ENIAC, one ring counter gated pulses to its partner while counting down. While pulses were gated to it, the second ring counter counted up, optionally setting a carry flip-flop.</p>
- <p>Hence the term digital initially meant both being discrete and making use of ten-state logic. If a person examines the control levers of the mechanical machines, or the control signals of ENIAC, he finds two-state switch logic, but computation units processed numbers consisting of ten-state digits, mimicking human computers. Early computing work gave us more than the techniques we take for granted today; it gave us words such as gate, register, and index.</p>
+
<p>Hence the term digital initially meant both being discrete and making use of ten-state logic. If a person examines the control levers of the mechanical machines, or the control signals of ENIAC, he finds two-state switch logic, but computation units processed numbers consisting of ten-state digits, mimicking human computers. Early computing work gave us more than the techniques we take for granted today; it gave us words such as gate, register, and index.</p>
- <p>Earlier, Claude Shannon and others wrote extensively on methods for simplifying switch logic, making it apparent that direct binary computation could be performed. The first electronic computer to do so was the Atanasoff-Berry machine developed in the late 1930s. Because there are two states in switch logic, it is maximally efficient to use a base two number system for arithmetic. In such an arithmetic system, each binary digit has the value of either zero or one. It is conventional to shorten the term binary digit to <RT·term>bit</RT·term>. John von Neumann assigned Atanasoff to audio work during World War II, so the Atanasoff-Berry machine remained unused in a basement at Iowa State University.</p>
+
<p>Earlier, Claude Shannon and others wrote extensively on methods for simplifying switch logic, making it apparent that direct binary computation could be performed. The first electronic computer to do so was the Atanasoff-Berry machine developed in the late 1930s. Because there are two states in switch logic, it is maximally efficient to use a base two number system for arithmetic. In such an arithmetic system, each binary digit has the value of either zero or one. It is conventional to shorten the term binary digit to <RT·term>bit</RT·term>. John von Neumann assigned Atanasoff to audio work during World War II, so the Atanasoff-Berry machine remained unused in a basement at Iowa State University.</p>
- <p>Binary computation prevailed. By the 1950s almost all discrete state computers used two-state switch logic for computation. Still, the term digital continued to describe them. This leads to some curious naming conventions. For example, the company Digital Equipment Corporation, which began shipping computers in 1959, exclusively built binary computers. As another example, an engineer who studies modern digital electronics will never see wheels or decade counters used to implement operations in an ALU. Though the term digital continues to refer to computing with discrete state digits, the term has lost the connotation that there must be exactly ten of those states.</p>
+
<p>Binary computation prevailed. By the 1950s almost all discrete state computers used two-state switch logic for computation. Still, the term digital continued to describe them. This leads to some curious naming conventions. For example, the company Digital Equipment Corporation, which began shipping computers in 1959, exclusively built binary computers. As another example, an engineer who studies modern digital electronics will never see wheels or decade counters used to implement operations in an ALU. Though the term digital continues to refer to computing with discrete state digits, the term has lost the connotation that there must be exactly ten of those states.</p>
- <p>Today, computing based on ten-state digits, such as what is found on handheld calculators, is known as decimal computing. If a machine made use of 256-state digits, it would be neither decimal nor binary. Because we lack a special name for the number 256, a person states that such a computer uses base 256 digits and that it is a base 256 computer. Decimal computing, binary computing, and base 256 computing are all examples of digital computing. Independent of the base for computation, control signals are almost universally on or off. We say these are Boolean or binary valued, sometimes referring to their values as one or zero, but note they represent logical states rather than numbers.</p>
+
<p>Today, computing based on ten-state digits, such as what is found on handheld calculators, is known as decimal computing. If a machine made use of 256-state digits, it would be neither decimal nor binary. Because we lack a special name for the number 256, a person states that such a computer uses base 256 digits and that it is a base 256 computer. Decimal computing, binary computing, and base 256 computing are all examples of digital computing. Independent of the base for computation, control signals are almost universally on or off. We say these are Boolean or binary valued, sometimes referring to their values as one or zero, but note they represent logical states rather than numbers.</p>
- <p>As computer implementations moved from ten-state logic to two-state logic, it was difficult to completely abandon base ten number systems, particularly in business applications where users expect dollars and cents results that match manual computations, even when fractions and rounding are involved. Hence, IBM designed a scheme whereby groups of 4 bits represent the decimal digits; this code is called binary coded decimal or BCD. A machine which processes numbers using BCD has a decimal architecture.</p>
+
<p>As computer implementations moved from ten-state logic to two-state logic, it was difficult to completely abandon base ten number systems, particularly in business applications where users expect dollars and cents results that match manual computations, even when fractions and rounding are involved. Hence, IBM designed a scheme whereby groups of 4 bits represent the decimal digits; this code is called binary coded decimal or BCD. A machine which processes numbers using BCD has a decimal architecture.</p>
- <p>Most computer users never see a memory dump. Instead, they see the output of print functions. By default, print functions render numbers in a decimal format familiar to the user, independent of the internal representation used for numbers. In contemporary computing, the time it takes to convert a binary number to a decimal number is negligible compared to the time required to execute a long computation, so decimal printing is practical.</p>
+
<p>Most computer users never see a memory dump. Instead, they see the output of print functions. By default, print functions render numbers in a decimal format familiar to the user, independent of the internal representation used for numbers. In contemporary computing, the time it takes to convert a binary number to a decimal number is negligible compared to the time required to execute a long computation, so decimal printing is practical.</p>
</RT·section>
<RT·section>
<RT·name>Scanning-Order and Digit-Order</RT·name>
- <p>Had this book been written in Hindu-Arabic, the text would be written right to left. Let us explore what that looks like by using an example where we start with an English sentence and then reverse it. Notice that in this right to left string, the sequence [9, 8, 7] without notation is 987. Both strings match.</p>
+
<p>Had this book been written in Hindu-Arabic, the text would be written right to left. Let us explore what that looks like by using an example where we start with an English sentence and then reverse it. Notice that in this right to left string, the sequence [9, 8, 7] without notation is 987. Both strings match.</p>
- <blockquote>
- Writing from right to left the sequence [7, 8, 9] without notation is 987.
- </blockquote>
+ Writing from right to left the sequence [7, 8, 9] without notation is 987.
+ </blockquote>
- <p>When reversed this becomes:</p>
+
<p>When reversed this becomes:</p>
- <blockquote>
- .987 si noitaton tuohtiw [9 ,8, 7] ecneuqes eht thgir ot tfel morf gnitirW
- </blockquote>
+ .987 si noitaton tuohtiw [9 ,8, 7] ecneuqes eht thgir ot tfel morf gnitirW
+ </blockquote>
- <p>Following the 1,000-year-old convention, I did not reverse the order of the digits of the number. For the reversed sentence to make sense, I changed 'tfel ot thgir' (right to left) to 'left to right', which is the sort of adaptation that Middle Ages translators did not universally apply. Also, I changed the brackets so that they still enclose the sequence components; otherwise, they point outward. When reading the number, the eye first lands on a digit of unknown weight. A person must scan further right to find the one’s place, then scan back while counting the digits to make sense of the number. Reversing the string is insufficient; a person must understand the sentence and change the phrase "right to left", to "left to right".</p>
+
<p>Following the 1,000-year-old convention, I did not reverse the order of the digits of the number. For the reversed sentence to make sense, I changed 'tfel ot thgir' (right to left) to 'left to right', which is the sort of adaptation that Middle Ages translators did not universally apply. Also, I changed the brackets so that they still enclose the sequence components; otherwise, they point outward. When reading the number, the eye first lands on a digit of unknown weight. A person must scan further right to find the one’s place, then scan back while counting the digits to make sense of the number. Reversing the string is insufficient; a person must understand the sentence and change the phrase "right to left", to "left to right".</p>
- <p>Now consider starting with the exact same right to left string as the early translators did, but instead of making an exception for numbers, we literally reverse the entire string:</p>
+
<p>Now consider starting with the exact same right to left string as the early translators did, but instead of making an exception for numbers, we literally reverse the entire string:</p>
- <blockquote>
- Writing from right to left the sequence [7, 8, 9] without notation is 789.
- </blockquote>
+ Writing from right to left the sequence [7, 8, 9] without notation is 789.
+ </blockquote>
- <p>Now both the scan order of the sequence and the digits are identical. This maintains the property designed into the original Indian Numbers. Note, that 789 here is still thirteen away from one thousand.</p>
+
<p>Now both the scan order of the sequence and the digits are identical. This maintains the property designed into the original Indian Numbers. Note, that 789 here is still thirteen away from one thousand.</p>
- <p>To make the structure uniform, Western writers must either start writing right to left like the Arabs do, or reverse the order of digits in numbers. Computer architects implemented this latter option; for example, Intel processors utilize it.</p>
+
<p>To make the structure uniform, Western writers must either start writing right to left like the Arabs do, or reverse the order of digits in numbers. Computer architects implemented this latter option; for example, Intel processors utilize it.</p>
- <p>In summary, this section defines two concepts: scanning-order when reading, and the digit-order of numbers. Changing the scanning-order without changing the digit-order effectively causes the number to be read in reverse.</p>
+
<p>In summary, this section defines two concepts: scanning-order when reading, and the digit-order of numbers. Changing the scanning-order without changing the digit-order effectively causes the number to be read in reverse.</p>
- <p>All conventional computers use low-to-high address scanning-order for writing and reading text. Human operators universally find that low-to-high address scanning-order for text feels natural. Relative to the low-to-high address scanning-order, Big-Endian computers follow the current Western ideal that the large digit comes first. In contrast, Little-Endian computers are more faithful to the design of Hindu-Arabic numbers, storing numbers consistently with the scanning-order matching the order of the digit weights.</p>
+
<p>All conventional computers use low-to-high address scanning-order for writing and reading text. Human operators universally find that low-to-high address scanning-order for text feels natural. Relative to the low-to-high address scanning-order, Big-Endian computers follow the current Western ideal that the large digit comes first. In contrast, Little-Endian computers are more faithful to the design of Hindu-Arabic numbers, storing numbers consistently with the scanning-order matching the order of the digit weights.</p>
- <p>Because a page of text is two-dimensional, there are additional writing direction conventions. However, computer memory is one-dimensional, so only the two discussed here are relevant to this architectural discussion. Programmers tasked with writing display drivers encounter the others.</p>
+
<p>Because a page of text is two-dimensional, there are additional writing direction conventions. However, computer memory is one-dimensional, so only the two discussed here are relevant to this architectural discussion. Programmers tasked with writing display drivers encounter the others.</p>
</RT·section>
<RT·section>
<RT·name>Binary, Octal, Hexadecimal, BCD</RT·name>
- <p>A person interprets a sequence of <RT·math>n</RT·math> bits as a number by using this function:</p>
+
<p>A person interprets a sequence of <RT·math>n</RT·math> bits as a number by using this function:</p>
- <RT·math>\sum_{i=0}^n x_i \cdot two^i</RT·math>
+ <RT·math>\sum_{i=0}^n x_i \cdot two^i</RT·math>
- <p>As with sequences of decimal digits, a person drops the sequence notation to yield strings of bits. Similar to decimal digit strings, there are two options for writing the string: most-significant-digit-first, or least-significant-digit-first.</p>
+
<p>As with sequences of decimal digits, a person drops the sequence notation to yield strings of bits. Similar to decimal digit strings, there are two options for writing the string: most-significant-digit-first, or least-significant-digit-first.</p>
- <p>Although both strings of binary digits and strings of decimal digits grow in length logarithmically when counting, binary strings grow more than twice as fast. The expansion to a length two string occurs immediately at the count of two. Length expands to three at a count of four, and then to a string of length four at a count of eight. While incrementing to eight, the binary digit string has already expanded to length four, yet for the exact same count, a decimal digit string remains one digit long.</p>
+
<p>Although both strings of binary digits and strings of decimal digits grow in length logarithmically when counting, binary strings grow more than twice as fast. The expansion to a length two string occurs immediately at the count of two. Length expands to three at a count of four, and then to a string of length four at a count of eight. While incrementing to eight, the binary digit string has already expanded to length four, yet for the exact same count, a decimal digit string remains one digit long.</p>
- <p>Writing such long strings is inefficient, so programmers group bits. When bits are grouped in threes, the base is eight instead of two. This is called octal notation, using one of the symbols 0, 1, 2, 3, 4, 5, 6, or 7 for the octal digit values.</p>
+
<p>Writing such long strings is inefficient, so programmers group bits. When bits are grouped in threes, the base is eight instead of two. This is called octal notation, using one of the symbols 0, 1, 2, 3, 4, 5, 6, or 7 for the octal digit values.</p>
- <RT·dictionary key="octal" definition="binary">
- <RT·entry key="0">000</RT·entry>
- <RT·entry key="1">001</RT·entry>
- <RT·entry key="2">010</RT·entry>
- <RT·entry key="3">011</RT·entry>
- <RT·entry key="4">100</RT·entry>
- <RT·entry key="5">101</RT·entry>
- <RT·entry key="6">110</RT·entry>
- <RT·entry key="7">111</RT·entry>
- </RT·dictionary>
+ <RT·dictionary key="octal" definition="binary">
+ <RT·entry key="0">000</RT·entry>
+ <RT·entry key="1">001</RT·entry>
+ <RT·entry key="2">010</RT·entry>
+ <RT·entry key="3">011</RT·entry>
+ <RT·entry key="4">100</RT·entry>
+ <RT·entry key="5">101</RT·entry>
+ <RT·entry key="6">110</RT·entry>
+ <RT·entry key="7">111</RT·entry>
+ </RT·dictionary>
- <p>In the 1960s, computer panels featured switches and lights organized in threes, and coding forms were filled out in octal. Today, documents showing bit strings universally use groups of fours. Such a digit has 16 values, utilizing 0 through 9, and continuing with the letters a, b, c, d, e, and f. This is known as the hexadecimal system, often shortened to hex.</p>
+
<p>In the 1960s, computer panels featured switches and lights organized in threes, and coding forms were filled out in octal. Today, documents showing bit strings universally use groups of fours. Such a digit has 16 values, utilizing 0 through 9, and continuing with the letters a, b, c, d, e, and f. This is known as the hexadecimal system, often shortened to hex.</p>
- <RT·dictionary key="hex" definition="binary">
- <RT·entry key="0">0000</RT·entry>
- <RT·entry key="1">0001</RT·entry>
- <RT·entry key="2">0010</RT·entry>
- <RT·entry key="3">0011</RT·entry>
- <RT·entry key="4">0100</RT·entry>
- <RT·entry key="5">0101</RT·entry>
- <RT·entry key="6">0110</RT·entry>
- <RT·entry key="7">0111</RT·entry>
- <RT·entry key="8">1000</RT·entry>
- <RT·entry key="9">1001</RT·entry>
- <RT·entry key="a">1010</RT·entry>
- <RT·entry key="b">1011</RT·entry>
- <RT·entry key="c">1100</RT·entry>
- <RT·entry key="d">1101</RT·entry> 8
- <RT·entry key="e">1110</RT·entry>
- <RT·entry key="f">1111</RT·entry>
- </RT·dictionary>
+ <RT·dictionary key="hex" definition="binary">
+ <RT·entry key="0">0000</RT·entry>
+ <RT·entry key="1">0001</RT·entry>
+ <RT·entry key="2">0010</RT·entry>
+ <RT·entry key="3">0011</RT·entry>
+ <RT·entry key="4">0100</RT·entry>
+ <RT·entry key="5">0101</RT·entry>
+ <RT·entry key="6">0110</RT·entry>
+ <RT·entry key="7">0111</RT·entry>
+ <RT·entry key="8">1000</RT·entry>
+ <RT·entry key="9">1001</RT·entry>
+ <RT·entry key="a">1010</RT·entry>
+ <RT·entry key="b">1011</RT·entry>
+ <RT·entry key="c">1100</RT·entry>
+ <RT·entry key="d">1101</RT·entry> 8
+ <RT·entry key="e">1110</RT·entry>
+ <RT·entry key="f">1111</RT·entry>
+ </RT·dictionary>
- <p>The table of hexadecimal digits is twice as long as the table of octal digits because each added bit doubles the table size.</p>
+
<p>The table of hexadecimal digits is twice as long as the table of octal digits because each added bit doubles the table size.</p>
- <p>Another common grouping is the <RT·term>byte</RT·term>. This name is word play on the term bit. Today a byte is universally a group of eight bits; however, historical computers used other lengths, ranging from six to twelve bits. Vestiges of that past remain. K&R’s "C Programming Language" leaves the length of a byte unspecified. The designers of UTF-8 sought clarity regarding groups of eight, naming such a group an octet rather than a byte.</p>
+
<p>Another common grouping is the <RT·term>byte</RT·term>. This name is word play on the term bit. Today a byte is universally a group of eight bits; however, historical computers used other lengths, ranging from six to twelve bits. Vestiges of that past remain. K&R’s "C Programming Language" leaves the length of a byte unspecified. The designers of UTF-8 sought clarity regarding groups of eight, naming such a group an octet rather than a byte.</p>
- <p>When a group of eight bits, i.e., an octet, functions as a digit of a number, the arithmetic operates in base 256. Note that octet and octal are distinct concepts. An octet is a group of 8 bits, whereas octal is a number system based on digits that have values running from 0 to 7.</p>
+
<p>When a group of eight bits, i.e., an octet, functions as a digit of a number, the arithmetic operates in base 256. Note that octet and octal are distinct concepts. An octet is a group of 8 bits, whereas octal is a number system based on digits that have values running from 0 to 7.</p>
- <p>Groups of bits become larger. The organization of early RISC microprocessors specified that memory was always moved in groups of 32 bits, called words. Today, address variables are generally 64-bit words, while Integer variables are either 32- or 64-bit words. Groups of bits found on internal buses scale larger yet.</p>
+
<p>Groups of bits become larger. The organization of early RISC microprocessors specified that memory was always moved in groups of 32 bits, called words. Today, address variables are generally 64-bit words, while Integer variables are either 32- or 64-bit words. Groups of bits found on internal buses scale larger yet.</p>
- <p>Bits are also grouped to construct numbers with bases that are not powers of two. In the BCD code, bits are grouped in fours to form decimal digits.</p>
+
<p>Bits are also grouped to construct numbers with bases that are not powers of two. In the BCD code, bits are grouped in fours to form decimal digits.</p>
- <RT·dictionary key="BCD" definition="binary">
- <RT·entry key="0">0000</RT·entry>
- <RT·entry key="1">0001</RT·entry>
- <RT·entry key="2">0010</RT·entry>
- <RT·entry key="3">0011</RT·entry>
- <RT·entry key="4">0100</RT·entry>
- <RT·entry key="5">0101</RT·entry>
- <RT·entry key="6">0110</RT·entry>
- <RT·entry key="7">0111</RT·entry>
- <RT·entry key="8">1000</RT·entry>
- <RT·entry key="9">1001</RT·entry>
- </RT·dictionary>
+ <RT·dictionary key="BCD" definition="binary">
+ <RT·entry key="0">0000</RT·entry>
+ <RT·entry key="1">0001</RT·entry>
+ <RT·entry key="2">0010</RT·entry>
+ <RT·entry key="3">0011</RT·entry>
+ <RT·entry key="4">0100</RT·entry>
+ <RT·entry key="5">0101</RT·entry>
+ <RT·entry key="6">0110</RT·entry>
+ <RT·entry key="7">0111</RT·entry>
+ <RT·entry key="8">1000</RT·entry>
+ <RT·entry key="9">1001</RT·entry>
+ </RT·dictionary>
- <p>In BCD, some possible bit value combinations are unused. This is an unavoidable consequence of emulating a number base in binary switch logic when that base is not a power of 2.</p>
+
<p>In BCD, some possible bit value combinations are unused. This is an unavoidable consequence of emulating a number base in binary switch logic when that base is not a power of 2.</p>
- <p>Octal and hexadecimal operate primarily as writing aids. Internally, the computer computes in binary, i.e., base 2. In contrast, BCD computation relies on the structural encoding boundaries. When two BCD digits are summed, the carry occurs when the sum of two digits reaches ten or more, which does not fall on a power-of-two boundary.</p>
+
<p>Octal and hexadecimal operate primarily as writing aids. Internally, the computer computes in binary, i.e., base 2. In contrast, BCD computation relies on the structural encoding boundaries. When two BCD digits are summed, the carry occurs when the sum of two digits reaches ten or more, which does not fall on a power-of-two boundary.</p>
- <p>Some processors lack native BCD computation, providing BCD to binary conversion operations instead. Consequently, numbers that appear as BCD in memory convert to binary before computation. Other computers, most notably many IBM machines, implement true BCD architectures featuring instructions for directly operating on BCD encoded numbers.</p>
+
<p>Some processors lack native BCD computation, providing BCD to binary conversion operations instead. Consequently, numbers that appear as BCD in memory convert to binary before computation. Other computers, most notably many IBM machines, implement true BCD architectures featuring instructions for directly operating on BCD encoded numbers.</p>
- <p>Although BCD encoding is less efficient, BCD encoded binary place values numbers still grow in length logarithmically while counting. Because numbers are represented in base ten, no number conversion is necessary when printing, though today this performance cost is insignificant. More importantly, BCD numbers divide by ten without generating infinite fractions.</p>
+
<p>Although BCD encoding is less efficient, BCD encoded binary place values numbers still grow in length logarithmically while counting. Because numbers are represented in base ten, no number conversion is necessary when printing, though today this performance cost is insignificant. More importantly, BCD numbers divide by ten without generating infinite fractions.</p>
</RT·section>
<RT·section>
<RT·name>Allocation</RT·name>
- <p>In most text documents, a number is written down once and remains unchanged. In contrast, a computing program frequently returns to the exact memory location and changes its value. This is equivalent to erasing an old value on a paper document and writing a new value in the same space.</p>
+
<p>In most text documents, a number is written down once and remains unchanged. In contrast, a computing program frequently returns to the exact memory location and changes its value. This is equivalent to erasing an old value on a paper document and writing a new value in the same space.</p>
- <p>Consider recording a count in real-time, where the system must routinely erase the current count value and write a new one. The process begins at zero. When an event occurs, the count increments to 1. The sequence remains a single digit. The count grows to two digits in length upon reaching ten. The count grows by another digit in length upon reaching a hundred, and again at a thousand. A digit sequence representing the count grows in length against the log of the count value. The log function grows without bound, but it does so slowly, allowing relatively short digit sequences to represent exceedingly large numbers. This structural observation is central to understanding contemporary computer architecture.</p>
+
<p>Consider recording a count in real-time, where the system must routinely erase the current count value and write a new one. The process begins at zero. When an event occurs, the count increments to 1. The sequence remains a single digit. The count grows to two digits in length upon reaching ten. The count grows by another digit in length upon reaching a hundred, and again at a thousand. A digit sequence representing the count grows in length against the log of the count value. The log function grows without bound, but it does so slowly, allowing relatively short digit sequences to represent exceedingly large numbers. This structural observation is central to understanding contemporary computer architecture.</p>
- <p>If a paper document only provides space for a single digit count, an error occurs when the count grows to ten, escalating when it reaches a thousand. If a programmer anticipates counts in the thousands, he allocates space for four digits in advance. Such an allocation minimizes wasted space because the digit sequences for massive numbers are not significantly longer than those for small numbers.</p>
+
<p>If a paper document only provides space for a single digit count, an error occurs when the count grows to ten, escalating when it reaches a thousand. If a programmer anticipates counts in the thousands, he allocates space for four digits in advance. Such an allocation minimizes wasted space because the digit sequences for massive numbers are not significantly longer than those for small numbers.</p>
- <p>For any allocated boundary, there remains the statistical possibility that a computed number will exceed the allocation, resulting in an overflow error. To establish rigorous allocations, a programmer must evaluate how much numbers grow via applied operations, and how many of those operations the system executes. This latter constraint ties directly to the projected lifespan of the task.</p>
+
<p>For any allocated boundary, there remains the statistical possibility that a computed number will exceed the allocation, resulting in an overflow error. To establish rigorous allocations, a programmer must evaluate how much numbers grow via applied operations, and how many of those operations the system executes. This latter constraint ties directly to the projected lifespan of the task.</p>
- <p>Universally, a program cannot analyze another arbitrary program and determine how many steps it will take before stopping, or if it will ever stop. Even in specific bounded cases, the analysis is highly complex, and the programmer frequently skips it unless the code drives a life-critical application. Because data lengths expand during runtime, users operate under the threat of allocation overflow. If the allocation overflows, there is a high probability the program will stop and emit an error, or it will continue executing while outputting garbage results. This failure mode does not surprise contemporary users. The real-time computer user experiences catastrophic failure, and the error emerges during accident analysis.</p>
+
<p>Universally, a program cannot analyze another arbitrary program and determine how many steps it will take before stopping, or if it will ever stop. Even in specific bounded cases, the analysis is highly complex, and the programmer frequently skips it unless the code drives a life-critical application. Because data lengths expand during runtime, users operate under the threat of allocation overflow. If the allocation overflows, there is a high probability the program will stop and emit an error, or it will continue executing while outputting garbage results. This failure mode does not surprise contemporary users. The real-time computer user experiences catastrophic failure, and the error emerges during accident analysis.</p>
- <p>Conventional system memory is an array of allocation units called bytes. The indexes into this array are system memory addresses. Serving as the minimum addressable allocation unit defines the term byte. The number of bits in a byte is a parameter of the computer architecture, not the compiler.</p>
+
<p>Conventional system memory is an array of allocation units called bytes. The indexes into this array are system memory addresses. Serving as the minimum addressable allocation unit defines the term byte. The number of bits in a byte is a parameter of the computer architecture, not the compiler.</p>
- <p>It follows that any larger allocation consists of multiple bytes. For a given allocation unit, the smallest address among the contained bytes establishes the address of the allocation unit. Each allocation unit is bounded by two parameters: its address, and its extent.</p>
+
<p>It follows that any larger allocation consists of multiple bytes. For a given allocation unit, the smallest address among the contained bytes establishes the address of the allocation unit. Each allocation unit is bounded by two parameters: its address, and its extent.</p>
- <p>Setting aside the scanning-order variable, a number logically begins with its least-significant digit. This is justified because an analyst must read a number starting with its least-significant digit to derive the weights of the subsequent digits. The allocation scheme where the address of the allocation maps to the address of the least-significant digit is called <RT·term>little-endian</RT·term>. The definition of <RT·term>big-endian</RT·term> involves zero-padding to fulfill the allocation width. Relative to starting at the least-significant digit, the big-endian allocation address resolves to either the most-significant digit or the final zero in the padding.</p>
+
<p>Setting aside the scanning-order variable, a number logically begins with its least-significant digit. This is justified because an analyst must read a number starting with its least-significant digit to derive the weights of the subsequent digits. The allocation scheme where the address of the allocation maps to the address of the least-significant digit is called <RT·term>little-endian</RT·term>. The definition of <RT·term>big-endian</RT·term> involves zero-padding to fulfill the allocation width. Relative to starting at the least-significant digit, the big-endian allocation address resolves to either the most-significant digit or the final zero in the padding.</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>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 <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>
+
<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>
- <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>
+ <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 <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>
+
<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>
- <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>
+ <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>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>Typically, processor registers and buses are one word in length, and a processor loads the entire contents of a memory word into a register as a single atomic operation. Contemporary processors are designed effectively for either little-endian or big-endian number representation; however, once designed for little-endian, the processor is fundamentally incompatible with big-endian, and vice-versa.</p>
+
<p>Typically, processor registers and buses are one word in length, and a processor loads the entire contents of a memory word into a register as a single atomic operation. Contemporary processors are designed effectively for either little-endian or big-endian number representation; however, once designed for little-endian, the processor is fundamentally incompatible with big-endian, and vice-versa.</p>
- <p>If an unconventional processor loads numbers sequentially as digit streams, the load instruction must possess a mechanism to detect the end of the loaded number, or it must receive the exact length prior to execution. This structural boundary is identical to the existing mechanism for loading character strings, where systems utilize length counts or explicit end terminators.</p>
+
<p>If an unconventional processor loads numbers sequentially as digit streams, the load instruction must possess a mechanism to detect the end of the loaded number, or it must receive the exact length prior to execution. This structural boundary is identical to the existing mechanism for loading character strings, where systems utilize length counts or explicit end terminators.</p>
- <p>For serial computation utilizing little-endian notation, the processor produces the first digit of the sum immediately after receiving the first digit of the operand. If big-endian is used, the least-significant digit arrives last, forcing the system to buffer the entire number before computing the first digit of the sum. Attempting to load from the far ends of the operands fails because the physical location of the sum's far end remains undefined until the carry propagates. Resolving big-endian serial addition requires implementing signed-digit arithmetic.</p>
+
<p>For serial computation utilizing little-endian notation, the processor produces the first digit of the sum immediately after receiving the first digit of the operand. If big-endian is used, the least-significant digit arrives last, forcing the system to buffer the entire number before computing the first digit of the sum. Attempting to load from the far ends of the operands fails because the physical location of the sum's far end remains undefined until the carry propagates. Resolving big-endian serial addition requires implementing signed-digit arithmetic.</p>
</RT·section>
<RT·section>
<RT·name>Bit Order Within Bytes</RT·name>
- <p>Data transports between hardware nodes over bundles of wires called buses. Bus specifications explicitly define the order of bits in bytes, and for contemporary machines, bytes are strictly octets. All compute processors, channel processors, and attached devices must conform to the bus’s specifications.</p>
+
<p>Data transports between hardware nodes over bundles of wires called buses. Bus specifications explicitly define the order of bits in bytes, and for contemporary machines, bytes are strictly octets. All compute processors, channel processors, and attached devices must conform to the bus’s specifications.</p>
- <p>Channel processors bridge the gap between a computer's system bus and a storage bus connected to storage devices. The storage device designers adhere strictly to the storage bus specification without evaluating the host computer architecture. The compatibility burden relies entirely on selecting a channel processor that respects the established standard. Consequently, unless a programmer explicitly designs bus standards or hardware interfaces, the physical bit order within bytes remains invisible.</p>
+
<p>Channel processors bridge the gap between a computer's system bus and a storage bus connected to storage devices. The storage device designers adhere strictly to the storage bus specification without evaluating the host computer architecture. The compatibility burden relies entirely on selecting a channel processor that respects the established standard. Consequently, unless a programmer explicitly designs bus standards or hardware interfaces, the physical bit order within bytes remains invisible.</p>
- <p>Some processors physically store bits into memory bytes in different orders. However, the data read and written into the respective memories routes through a bus, and at that boundary, the bit order aligns with the applicable bus specification.</p>
+
<p>Some processors physically store bits into memory bytes in different orders. However, the data read and written into the respective memories routes through a bus, and at that boundary, the bit order aligns with the applicable bus specification.</p>
- <p>On all contemporary computers, ALU hardware performs arithmetic on bytes. Carries propagate strictly from lower significant bits to more significant bits; therefore, the ALU imposes a logical bit order within bytes. That logical order conforms directly to the documentation for the processor’s internal bus, where bit 0 serves universally as the least-significant bit.</p>
+
<p>On all contemporary computers, ALU hardware performs arithmetic on bytes. Carries propagate strictly from lower significant bits to more significant bits; therefore, the ALU imposes a logical bit order within bytes. That logical order conforms directly to the documentation for the processor’s internal bus, where bit 0 serves universally as the least-significant bit.</p>
- <p>Because doing so is impossible in all but special cases, an address points at the entire byte, rather than pointing at the most-significant bit or the least-significant bit.</p>
+
<p>Because doing so is impossible in all but special cases, an address points at the entire byte, rather than pointing at the most-significant bit or the least-significant bit.</p>
</RT·section>
<RT·section>
<RT·name>Byte Order Within Words</RT·name>
- <p>A specific processor architecture features native support for byte data alongside varied word lengths, most commonly 16, 32, and 64 bits (or 4, 8, and 16 bytes).</p>
+
<p>A specific processor architecture features native support for byte data alongside varied word lengths, most commonly 16, 32, and 64 bits (or 4, 8, and 16 bytes).</p>
- <p>Communication channels and storage devices organize payloads strictly as octets, possessing no native structural support for words. Therefore, storing or transmitting a word requires serializing the word into a sequence of bytes, transferring the data, and subsequently reading the data while deserializing the byte stream back into the original word configuration.</p>
+
<p>Communication channels and storage devices organize payloads strictly as octets, possessing no native structural support for words. Therefore, storing or transmitting a word requires serializing the word into a sequence of bytes, transferring the data, and subsequently reading the data while deserializing the byte stream back into the original word configuration.</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>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>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>
+
<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>
- <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>
+ <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>
+
<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>
- <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>
+ <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>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>Byte order within words becomes an application level design consideration, even though it possesses no structural relevance to applications.</p>
+
<p>Byte order within words becomes an application level design consideration, even though it possesses no structural relevance to applications.</p>
- <p>In protocols like the Internet Protocol (IP), the specification explicitly defines the data offset for the packet header. Code executes stably and efficiently. However, IP lacks context regarding the word locations in the data payload it carries, so IP routes the payload up the abstraction stack, preserving all byte order conflicts.</p>
+
<p>In protocols like the Internet Protocol (IP), the specification explicitly defines the data offset for the packet header. Code executes stably and efficiently. However, IP lacks context regarding the word locations in the data payload it carries, so IP routes the payload up the abstraction stack, preserving all byte order conflicts.</p>
- <p>JSON provides a standard for expressing tagged structured data built from primitive types while using character-only data. The specification dictates how numeric character strings evaluate, allowing both little-endian and big-endian machines to safely exchange JSON character-encoded numeric data. However, converting all numbers to strings and back wastes computational overhead, and transmitting them over a channel consumes excess bandwidth. Both processes expend unnecessary energy.</p>
+
<p>JSON provides a standard for expressing tagged structured data built from primitive types while using character-only data. The specification dictates how numeric character strings evaluate, allowing both little-endian and big-endian machines to safely exchange JSON character-encoded numeric data. However, converting all numbers to strings and back wastes computational overhead, and transmitting them over a channel consumes excess bandwidth. Both processes expend unnecessary energy.</p>
- <p>Various file formats and data communications standards serve specific classes of applications by explicitly defining where words that require reversal are located during machine-to-machine data transfers.</p>
+
<p>Various file formats and data communications standards serve specific classes of applications by explicitly defining where words that require reversal are located during machine-to-machine data transfers.</p>
</RT·section>
<RT·section>
- <RT·name>TTCA</RT·name>
+ <RT·name>RT</RT·name>
- <p>The native Integer data type for TTCA utilizes a high radix online number system. This number system functions as an extension of online arithmetic. Similar to online arithmetic, it employs serial most-significant-digit-first signed-digit arithmetic. In contrast to standard signed arithmetic, the radix scales significantly higher, causing a digit to span at least a byte in length. The numbers are highly scalable, and the architecture mandates an analysis step at compile time to establish rigorous precision requirements and exact range bounds. This process is detailed in the next chapter. The architecture provides explicit conversion instructions to generate alternate number formats.</p>
+ <p>The native Integer data type for RT utilizes a high radix online number system. This number system functions as an extension of online arithmetic. Similar to online arithmetic, it employs serial most-significant-digit-first signed-digit arithmetic. In contrast to standard signed arithmetic, the radix scales significantly higher, causing a digit to span at least a byte in length. The numbers are highly scalable, and the architecture mandates an analysis step at compile time to establish rigorous precision requirements and exact range bounds. This process is detailed in the next chapter. The architecture provides explicit conversion instructions to generate alternate number formats.</p>
</RT·section>
</RT·section>
<RT·name>Address</RT·name>
- <p>
- Would it be computationally consequential if binary Hindu-Arabic representation were used instead of unary for addresses? For unary representation each increment was constant-time, but with Hindu-Arabic addresses, increments have a carry. Would the carry cause stepping to the right, combined with calling the address machine, to become slower and slower as the machine steps further and further?
- </p>
-
-
- <p>
- The model used here to define an address is analogous to keeping a pointer into memory. Each step then increments or decrements the pointer. Conventional processors do the converse of the Turing Machine model presented here. For a processor, the <em>address</em> is the base object, while the <em>head location</em> is what is implied by the address. On processors, pointers will be one word in width. In small geometries where computation element delay dominates, two operand adders tend towards logarithmic complexity evaluation times against bit width, and the constants are small. Because of this, it is practical to perform word width addition operations atomically in one machine cycle. In fact, for some machines, the adder time likely sets the clock period. Such an adder will be used for address arithmetic; consequently, a programmer cannot arrange a program to expose aliasing in the address increment time to the real world. It remains a theoretical observation.
- </p>
-
- <p>
- An address is sent on a trip through the memory hierarchy to locate the corresponding memory cell, ultimately landing on a memory decoder over a physically implemented memory. Address decoders resemble carry chains, and they also have logarithmic physical evaluation times as word width grows. Hence, a fixed-width word holding an address gets decoded in approximately constant-time measured in clock ticks. However, the trip through the memory hierarchy is not negligible.
- </p>
-
- <p>
- Direct address decoding operates independently of reference locality. This fundamentally differs from a Turing Machine head, which incurs a linear computation cost strictly proportional to the distance traveled. However, direct decoding is only the base of the memory hierarchy.
- </p>
-
- <p>
- It is possible that decoding occurs separately in a row and column manner, and changes in the lower bits of the address walk a buffered row that was found in a prior access. This makes access to neighbor cell addresses within a row a low expense operation. However, this depends on memory implementation. One layer up, it is common for memory to be made of interleaved banks, so neighbor access that remains in the leaf collection is generally faster than that which requires fetching a new leaf set.
- </p>
-
- <p>
- There will, however, be a more dominant effect. For programs with islands of locality of reference, instructions or data will be discovered in a cache. Caches bring in two types of locality: that of access within a cache line, which makes neighbor walks that stay in the line fast, and cache line prefetch and replacement policies, which assume for any given fetch address that a subsequent fetch will be nearby in memory. These effects lead to similar memory behavior as a head on tape, where a single-step to a neighbor is faster than taking many steps to find memory further away, but there is not a one to one correspondence.
- </p>
-
- <p>
- Memory accesses into the processor local memory file are even faster. If locality of reference, even in an abstract sense, remains tight, then memory cells can be accessed in a minimal amount of time.
- </p>
-
- <p>
- For programs with large memory footprints and sparse memory access patterns, the dominant factor becomes the virtual memory subsystem. Here locality again comes into play as the translation lookaside buffer provides stateful location context, and the neighbor relationship between pages is sometimes taken into account for performance reasons. However, once a program starts performing at virtual memory page fetch times instead of cache access, or even local system memory access times, the program is said to be <RT·term>page thrashing</RT·term>, and it becomes very slow. It is also possible for small programs to have memory access patterns that alias against the memory subsystem's heuristics and lead to page thrashing. For a typical system, a programmer can write a small program to demonstrate this.
- </p>
-
- <p>
- In summary then, using Hindu-Arabic representation for addressing is not statistically computationally consequential. On the other hand, the idea of using a decoded address in place of a tape head raises computational model issues. So much so that it would not be an exaggeration to say that the very goal of modern computer architecture is to ensure that, within an execution context, address decode does not become computationally consequential. Architects employ a memory hierarchy to do this, and that memory hierarchy rewards locality of reference, but access times are not linear in time relative to distance from prior access. Instead they are clumped into a constant-time access abstract concept of locality groups where the time to access each group grows exponentially with the distance from the processor.
- </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. 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>
+ <p>
+ Would it be computationally consequential if binary Hindu-Arabic representation were used instead of unary for addresses? For unary representation each increment was constant-time, but with Hindu-Arabic addresses, increments have a carry. Would the carry cause stepping to the right, combined with calling the address machine, to become slower and slower as the machine steps further and further?
+ </p>
- </RT·section>
+
+ <p>
+ The model used here to define an address is analogous to keeping a pointer into memory. Each step then increments or decrements the pointer. Conventional processors do the converse of the Turing Machine model presented here. For a processor, the <em>address</em> is the base object, while the <em>head location</em> is what is implied by the address. On processors, pointers will be one word in width. In small geometries where computation element delay dominates, two operand adders tend towards logarithmic complexity evaluation times against bit width, and the constants are small. Because of this, it is practical to perform word width addition operations atomically in one machine cycle. In fact, for some machines, the adder time likely sets the clock period. Such an adder will be used for address arithmetic; consequently, a programmer cannot arrange a program to expose aliasing in the address increment time to the real world. It remains a theoretical observation.
+ </p>
+
+ <p>
+ An address is sent on a trip through the memory hierarchy to locate the corresponding memory cell, ultimately landing on a memory decoder over a physically implemented memory. Address decoders resemble carry chains, and they also have logarithmic physical evaluation times as word width grows. Hence, a fixed-width word holding an address gets decoded in approximately constant-time measured in clock ticks. However, the trip through the memory hierarchy is not negligible.
+ </p>
+
+ <p>
+ Direct address decoding operates independently of reference locality. This fundamentally differs from a Turing Machine head, which incurs a linear computation cost strictly proportional to the distance traveled. However, direct decoding is only the base of the memory hierarchy.
+ </p>
+
+ <p>
+ It is possible that decoding occurs separately in a row and column manner, and changes in the lower bits of the address walk a buffered row that was found in a prior access. This makes access to neighbor cell addresses within a row a low expense operation. However, this depends on memory implementation. One layer up, it is common for memory to be made of interleaved banks, so neighbor access that remains in the leaf collection is generally faster than that which requires fetching a new leaf set.
+ </p>
+
+ <p>
+ There will, however, be a more dominant effect. For programs with islands of locality of reference, instructions or data will be discovered in a cache. Caches bring in two types of locality: that of access within a cache line, which makes neighbor walks that stay in the line fast, and cache line prefetch and replacement policies, which assume for any given fetch address that a subsequent fetch will be nearby in memory. These effects lead to similar memory behavior as a head on tape, where a single-step to a neighbor is faster than taking many steps to find memory further away, but there is not a one to one correspondence.
+ </p>
+
+ <p>
+ Memory accesses into the processor local memory file are even faster. If locality of reference, even in an abstract sense, remains tight, then memory cells can be accessed in a minimal amount of time.
+ </p>
+
+ <p>
+ For programs with large memory footprints and sparse memory access patterns, the dominant factor becomes the virtual memory subsystem. Here locality again comes into play as the translation lookaside buffer provides stateful location context, and the neighbor relationship between pages is sometimes taken into account for performance reasons. However, once a program starts performing at virtual memory page fetch times instead of cache access, or even local system memory access times, the program is said to be <RT·term>page thrashing</RT·term>, and it becomes very slow. It is also possible for small programs to have memory access patterns that alias against the memory subsystem's heuristics and lead to page thrashing. For a typical system, a programmer can write a small program to demonstrate this.
+ </p>
+
+ <p>
+ In summary then, using Hindu-Arabic representation for addressing is not statistically computationally consequential. On the other hand, the idea of using a decoded address in place of a tape head raises computational model issues. So much so that it would not be an exaggeration to say that the very goal of modern computer architecture is to ensure that, within an execution context, address decode does not become computationally consequential. Architects employ a memory hierarchy to do this, and that memory hierarchy rewards locality of reference, but access times are not linear in time relative to distance from prior access. Instead they are clumped into a constant-time access abstract concept of locality groups where the time to access each group grows exponentially with the distance from the processor.
+ </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. 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>
+
+ </RT·section>
<!--------------------------------------------------------------------------------->
<RT·section>
<RT·name>The Universal Turing Machine</RT·name>
- <p>The Computer Theoretic model chapter provided symbolic definitions for the Turing Machine and the TTCA variation. Those definitions were written as strings of characters, which the reader scanned, and presumably understood, thus demonstrating the ability of those text strings to convey meaning. Furthermore the text explained in detail how an executor could make use of those definitions so as to perform the input string transformations. As Turing originally noted, the executor could be a person. Alternatively, as the book continued on to describe in detail, the executor could be a machine that applied the input transformations automatically.</p>
-
- <p>In his original paper Alan Turing put these things together and explained that a Universal Turing Machine could read the definition of a Turing Machine from tape, and thus be a Turing Machine executor. Hence, say, a Turing Machine reads the symbolic definition of a Turing Machine from one tape, and then automatically performs the described input string transformations on another tape. Said Universal Turing Machine would then be chameleon-like, performing the function of any other Turing Machine so described on the first tape.</p>
-
- <p>The only information that the first tape of a Universal Machine need contain is the variable part, <RT·math>\mathit{MP}</RT·math>, which the text established as the <em>program</em>, as the remainder of the definition is common to all machines and can thus be built into the controller. <RT·math>\mathit{MP}</RT·math> describes a state controller, it lists the states, the symbols of the alphabet, the instruction to be issued from each state, the symbol gated next-state transitions, and the halting state. The Universal Machine control program would then have to interpret that information and send the universal machine through the same steps that a human executor would take while running the described machine.</p>
-
- <p>However, the controller can be simplified if the program encoding is changed from the raw definition. Notice that the only information that leaves the state controller while it runs are the instructions issued per state, with that list terminating when the controller reaches the halt state.</p>
-
- <p>Imagine then, mounting a tape on a given machine, running the machine, and recording the instructions that leave the controller up until it halts. Then taking that list of instructions, and the same input tape, and mounting them on a Playback Machine. The Playback Machine then takes the instructions from the list on the first tape and issues them out of its own controller one by one. The playback controller is quite simple. Though of course, this approach has the drawback of having to run the given machine first so as to observe it, thus making the playback run moot.</p>
-
- <p>Consider then, inserting jump table instructions to handle the next-state transitions. Then a state controller can be mechanically changed into an instruction sequence with embedded jump table instructions without having to run it and observe it. Accordingly, first examine the state diagram for the controller. Take all the sequential state runs, even those of length 1, from the controller, and list their instructions in the same sequence order. Then, after each such sequence, wherever a state has next-state transition arcs based on the value of the status register, insert a jump table instruction, so that it jumps to the appropriate instruction sequence.</p>
-
- <p>Applying this mechanical procedure to the TTCA two-headed reverse string example controller results in:</p>
-
- <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. 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>
+ <p>The Computer Theoretic model chapter provided symbolic definitions for the Turing Machine and the RT variation. Those definitions were written as strings of characters, which the reader scanned, and presumably understood, thus demonstrating the ability of those text strings to convey meaning. Furthermore the text explained in detail how an executor could make use of those definitions so as to perform the input string transformations. As Turing originally noted, the executor could be a person. Alternatively, as the book continued on to describe in detail, the executor could be a machine that applied the input transformations automatically.</p>
+
+
<p>In his original paper Alan Turing put these things together and explained that a Universal Turing Machine could read the definition of a Turing Machine from tape, and thus be a Turing Machine executor. Hence, say, a Turing Machine reads the symbolic definition of a Turing Machine from one tape, and then automatically performs the described input string transformations on another tape. Said Universal Turing Machine would then be chameleon-like, performing the function of any other Turing Machine so described on the first tape.</p>
+
+
<p>The only information that the first tape of a Universal Machine need contain is the variable part, <RT·math>\mathit{MP}</RT·math>, which the text established as the <em>program</em>, as the remainder of the definition is common to all machines and can thus be built into the controller. <RT·math>\mathit{MP}</RT·math> describes a state controller, it lists the states, the symbols of the alphabet, the instruction to be issued from each state, the symbol gated next-state transitions, and the halting state. The Universal Machine control program would then have to interpret that information and send the universal machine through the same steps that a human executor would take while running the described machine.</p>
+
+
<p>However, the controller can be simplified if the program encoding is changed from the raw definition. Notice that the only information that leaves the state controller while it runs are the instructions issued per state, with that list terminating when the controller reaches the halt state.</p>
+
+
<p>Imagine then, mounting a tape on a given machine, running the machine, and recording the instructions that leave the controller up until it halts. Then taking that list of instructions, and the same input tape, and mounting them on a Playback Machine. The Playback Machine then takes the instructions from the list on the first tape and issues them out of its own controller one by one. The playback controller is quite simple. Though of course, this approach has the drawback of having to run the given machine first so as to observe it, thus making the playback run moot.</p>
+
+
<p>Consider then, inserting jump table instructions to handle the next-state transitions. Then a state controller can be mechanically changed into an instruction sequence with embedded jump table instructions without having to run it and observe it. Accordingly, first examine the state diagram for the controller. Take all the sequential state runs, even those of length 1, from the controller, and list their instructions in the same sequence order. Then, after each such sequence, wherever a state has next-state transition arcs based on the value of the status register, insert a jump table instruction, so that it jumps to the appropriate instruction sequence.</p>
+
+ <p>Applying this mechanical procedure to the RT two-headed reverse string example controller results in:</p>
+
+ <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. 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 RT Machine program invocation.</p>
</RT·section>
<RT·section>
<RT·name>Symbol in mathematics</RT·name>
- <p>
- A <RT·term>symbol</RT·term> is a distinct mathematical object capable of being instantiated. Within a given context, any instance of a specific symbol evaluates as equal to any other instance of that identical symbol, and evaluates as not equal to any instance of a different symbol.
- </p>
+ A <RT·term>symbol</RT·term> is a distinct mathematical object capable of being instantiated. Within a given context, any instance of a specific symbol evaluates as equal to any other instance of that identical symbol, and evaluates as not equal to any instance of a different symbol.
+ </p>
- <p>
- Put more formally, given a set of instantiable objects and a collection of instances made from them, for these objects to be symbols, two conditions must be met. First, it must be possible to define an instance comparison operation, denoted <RT·math>=</RT·math>, that acts as an equivalence relation to partition the collection into discrete equivalence classes. There must be a one to one correspondence between the resulting equivalence classes and the original instantiable objects from which the member instances were derived.
- </p>
+ Put more formally, given a set of instantiable objects and a collection of instances made from them, for these objects to be symbols, two conditions must be met. First, it must be possible to define an instance comparison operation, denoted <RT·math>=</RT·math>, that acts as an equivalence relation to partition the collection into discrete equivalence classes. There must be a one to one correspondence between the resulting equivalence classes and the original instantiable objects from which the member instances were derived.
+ </p>
- <p>
- It follows from this definition that the distinct equivalence classes can be used as a proxy for the instantiable objects themselves. That is, a person can name either the instantiable object or the equivalence class, and then through this correspondence, find the other.
- </p>
+ It follows from this definition that the distinct equivalence classes can be used as a proxy for the instantiable objects themselves. That is, a person can name either the instantiable object or the equivalence class, and then through this correspondence, find the other.
+ </p>
</RT·section>
<RT·section id="Section·symbol_in-computing">
<RT·name>Symbol in computing</RT·name>
- <p>
- In the context of realized machines, the symbol itself can be defined as a factory that produces symbol instances. A new symbol instance of the given symbol is then made, say, by calling the factory's <RT·code>make</RT·code> function. All of the symbol instances made by the factory constitute the members of the corresponding equivalence class.
- </p>
+ In the context of realized machines, the symbol itself can be defined as a factory that produces symbol instances. A new symbol instance of the given symbol is then made, say, by calling the factory's <RT·code>make</RT·code> function. All of the symbol instances made by the factory constitute the members of the corresponding equivalence class.
+ </p>
- <p>
- A <RT·term>symbol instance</RT·term> newly minted by the factory is said to <RT·neologism>come direct from the factory</RT·neologism>. A symbol instance direct from the factory is also called an <RT·neologism>original</RT·neologism>.
- </p>
+ A <RT·term>symbol instance</RT·term> newly minted by the factory is said to <RT·neologism>come direct from the factory</RT·neologism>. A symbol instance direct from the factory is also called an <RT·neologism>original</RT·neologism>.
+ </p>
<RT·section>
<RT·name>Required properties of symbol factories</RT·name>
- <p>
- Any two symbol instances returned directly from two distinct factories will always evaluate to <RT·code>False</RT·code> during an equality comparison. In other words, two distinct originals will always be not equal.
- </p>
+ Any two symbol instances returned directly from two distinct factories will always evaluate to <RT·code>False</RT·code> during an equality comparison. In other words, two distinct originals will always be not equal.
+ </p>
- <p>
- Given an original, all copies <RT·neologism>stemming from</RT·neologism> it will be equal to each other and to the original. By <RT·neologism>stemming from</RT·neologism>, this definition includes all direct copies and copies of copies.
- </p>
+ Given an original, all copies <RT·neologism>stemming from</RT·neologism> it will be equal to each other and to the original. By <RT·neologism>stemming from</RT·neologism>, this definition includes all direct copies and copies of copies.
+ </p>
- <p>
- Given any two originals, say <var>A</var> and <var>B</var>, it is established that <var>A</var> is not equal to <var>B</var>, as discussed above. Note also that <var>A</var> is not equal to any copy stemming from <var>B</var>, and <var>B</var> is not equal to any copy stemming from <var>A</var>.
- </p>
+ Given any two originals, say <var>A</var> and <var>B</var>, it is established that <var>A</var> is not equal to <var>B</var>, as discussed above. Note also that <var>A</var> is not equal to any copy stemming from <var>B</var>, and <var>B</var> is not equal to any copy stemming from <var>A</var>.
+ </p>
- <p>
- Though symbol instances are Integer like in that copy and equality comparison operations can be used with them, symbol instances are disallowed from being used with other Integer operators. Symbols cannot be compared for greater than or less than; they cannot be incremented, added, nor subtracted, etc.
- </p>
+ Though symbol instances are Integer like in that copy and equality comparison operations can be used with them, symbol instances are disallowed from being used with other Integer operators. Symbols cannot be compared for greater than or less than; they cannot be incremented, added, nor subtracted, etc.
+ </p>
</RT·section>
<RT·section>
<RT·name>Instance implementation</RT·name>
- <p>
- Within a process, a reference to the factory can be used as a symbol instance, which will cause the factory to become trivial. Making a new instance will merely require copying the factory reference, and there will be nothing in memory that the base factory reference is pointing to.
- </p>
+ Within a process, a reference to the factory can be used as a symbol instance, which will cause the factory to become trivial. Making a new instance will merely require copying the factory reference, and there will be nothing in memory that the base factory reference is pointing to.
+ </p>
- <p>
- In general, memory addresses are built in symbol instances, hence within the context of a single process run, a program can make use of these symbols. However, this diminishes the size of the address space and leaves the memory at those addresses unused. A common hedge is then to use references into a dictionary, where the data looked up in the dictionary is the <RT·term>name</RT·term> of the symbol.
- </p>
+ In general, memory addresses are built in symbol instances, hence within the context of a single process run, a program can make use of these symbols. However, this diminishes the size of the address space and leaves the memory at those addresses unused. A common hedge is then to use references into a dictionary, where the data looked up in the dictionary is the <RT·term>name</RT·term> of the symbol.
+ </p>
- <p>
- Such symbol names are non structural strings, so they do not need to follow the rules of symbols. For example, a program written where references to strings were used as symbol instances, could give multiple, or all, strings the same name, and the program would function. Conventionally, the names are made to be distinct so as to avoid confusion. The hazard here is that a programmer will then conflate the string name with the symbol instance, and perform symbol operations with it.
- </p>
+ Such symbol names are non structural strings, so they do not need to follow the rules of symbols. For example, a program written where references to strings were used as symbol instances, could give multiple, or all, strings the same name, and the program would function. Conventionally, the names are made to be distinct so as to avoid confusion. The hazard here is that a programmer will then conflate the string name with the symbol instance, and perform symbol operations with it.
+ </p>
- <p>
- An alternative implementation is to have the factory return an Integer value. Each factory has a base Integer that is distinct from that of other factories. Calling <RT·code>make</RT·code> then returns the base Integer.
- </p>
+ An alternative implementation is to have the factory return an Integer value. Each factory has a base Integer that is distinct from that of other factories. Calling <RT·code>make</RT·code> then returns the base Integer.
+ </p>
- <p>
- As another alternative, each factory can be given a base string, and then <RT·code>make</RT·code> returns a copy of the base string. Here we refer literally to the string as the symbol instance. There is no separate name, and the string data, not the reference to the string, becomes the symbol instance. This is however merely an architectural constraint, under the hood an implementation could use string references as long as it always appears to the programmer that the string value is being used.
- </p>
+ As another alternative, each factory can be given a base string, and then <RT·code>make</RT·code> returns a copy of the base string. Here we refer literally to the string as the symbol instance. There is no separate name, and the string data, not the reference to the string, becomes the symbol instance. This is however merely an architectural constraint, under the hood an implementation could use string references as long as it always appears to the programmer that the string value is being used.
+ </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 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>
+ 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 id="Section·distinctness_across-contexts">
<RT·name>Distinctness across contexts</RT·name>
- <p>
- If a symbol persists across contexts (such as across scopes or processes), it must remain distinct from all other symbols in its new context.
- </p>
+ If a symbol persists across contexts (such as across scopes or processes), it must remain distinct from all other symbols in its new context.
+ </p>
- <p>
- One way to meet this requirement is to find a scope encompassing both contexts and to place the symbol factory there. Another solution is to give each context a distinct root symbol and to use an array of symbols in place of the imported symbol. Yet another approach is to associate an imported symbol with a new symbol in the given new context using a correspondence map.
- </p>
+ One way to meet this requirement is to find a scope encompassing both contexts and to place the symbol factory there. Another solution is to give each context a distinct root symbol and to use an array of symbols in place of the imported symbol. Yet another approach is to associate an imported symbol with a new symbol in the given new context using a correspondence map.
+ </p>
- <p>
- When utilizing memory addresses as symbols in a virtual memory environment, the convention is to disallow addresses in one process from being used in another. If that isolation is insufficient, it is often adequate to use indexes instead of addresses, taking the address to the base of the data structure. Though the absolute address of the data structure might differ across contexts, the relative offset remains constant. Another approach is to reserve memory address blocks and to guarantee imported pages have the exact same addresses as before, though they might be imported sequentially to reuse the memory block. In architecture, this is generally known as the <RT·term>pointer swizzling problem</RT·term>.
- </p>
+ When utilizing memory addresses as symbols in a virtual memory environment, the convention is to disallow addresses in one process from being used in another. If that isolation is insufficient, it is often adequate to use indexes instead of addresses, taking the address to the base of the data structure. Though the absolute address of the data structure might differ across contexts, the relative offset remains constant. Another approach is to reserve memory address blocks and to guarantee imported pages have the exact same addresses as before, though they might be imported sequentially to reuse the memory block. In architecture, this is generally known as the <RT·term>pointer swizzling problem</RT·term>.
+ </p>
</RT·section>
</RT·section>
<RT·section>
<RT·name>Symbol copy consequentiality</RT·name>
- <p>
- Copying symbol instances is an integral part of the operation of the Turing Machine. Typically the programmed control steps are used as a cost metric for running a program. Such steps integrate operations of copying symbols to and from the tape. Thus from a pure step-count perspective the cost of the symbol copy is inconsequential, not due to any behavior of a symbol copy, but rather due to the symbol copy being subsumed within the definition of the step.
- </p>
+ Copying symbol instances is an integral part of the operation of the Turing Machine. Typically the programmed control steps are used as a cost metric for running a program. Such steps integrate operations of copying symbols to and from the tape. Thus from a pure step-count perspective the cost of the symbol copy is inconsequential, not due to any behavior of a symbol copy, but rather due to the symbol copy being subsumed within the definition of the step.
+ </p>
- <p>
- However, this is feels unsatisfactory. Here we are tying to build a bridge from computation theory to architecture, and thus we want a step to be a constant-time occurrence at least in the average, or at least approximately. To model the symbol copy time, a symbol could be copied a tranche of bits per step, thus giving the copy a step-count. Then, if symbols were to grow in tranche count as a program ran longer, then symbol copy of ever longer symbols would be computationally consequential.
- </p>
+ However, this is feels unsatisfactory. Here we are tying to build a bridge from computation theory to architecture, and thus we want a step to be a constant-time occurrence at least in the average, or at least approximately. To model the symbol copy time, a symbol could be copied a tranche of bits per step, thus giving the copy a step-count. Then, if symbols were to grow in tranche count as a program ran longer, then symbol copy of ever longer symbols would be computationally consequential.
+ </p>
- <p>
- Fortunately, the Turing Machine is defined with a finite alphabet and a couple of additional symbols. As these are part of the machine definition, and thus do not change at run time, there is no growth in size, and the time to copy them is inconsequential.
- </p>
+ Fortunately, the Turing Machine is defined with a finite alphabet and a couple of additional symbols. As these are part of the machine definition, and thus do not change at run time, there is no growth in size, and the time to copy them is inconsequential.
+ </p>
- <p>
- On a realized machine, the factory would be used to make the data alphabet and a couple of additional symbols. As these are set up before the machine runs, and thus before we count steps, these actions are computationally inconsequential.
- </p>
+ On a realized machine, the factory would be used to make the data alphabet and a couple of additional symbols. As these are set up before the machine runs, and thus before we count steps, these actions are computationally inconsequential.
+ </p>
</RT·section>
<RT·section>
<RT·name>Alphabet</RT·name>
- <p>
- An alphabet is another name for 'a set of symbols'. Because it is simply a set, an infinite number of distinct alphabets can exist, and a set of symbols could be finite or infinite.</p>
+ An alphabet is another name for 'a set of symbols'. Because it is simply a set, an infinite number of distinct alphabets can exist, and a set of symbols could be finite or infinite.</p>
- <p>For a Turing Machine there are a fixed number of alphabets that are all finite. The set of data symbols, control symbols, and controller state name symbols, are all finite and set in advance.
- </p>
+
<p>For a Turing Machine there are a fixed number of alphabets that are all finite. The set of data symbols, control symbols, and controller state name symbols, are all finite and set in advance.
+ </p>
</RT·section>
<RT·section>
<RT·name>Symbol implementation examples</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·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·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;
- }
-
- Instance make_symbol(const char *name){
- if(!SYM_LIST.head) return make_list(name);
-
- Instance *pt = SYM_LIST.head;
- while(1){
+ 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·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>
+
+ 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·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;
+ }
+
+ Instance make_symbol(const char *name){
+ if(!SYM_LIST.head) return make_list(name);
+
+ Instance *pt = SYM_LIST.head;
+ while(1){
if( strcmp(*pt ,name) == 0 ) return *pt;
if(pt == SYM_LIST.extent){
- fprintf(stderr ,"symbol list overflow for %s\n" ,name);
- return NULL;
+ fprintf(stderr ,"symbol list overflow for %s\n" ,name);
+ return NULL;
}
if(pt == SYM_LIST.tail){
- *++SYM_LIST.tail = strdup(name);
- return *SYM_LIST.tail;
+ *++SYM_LIST.tail = strdup(name);
+ return *SYM_LIST.tail;
}
pt++;
- }
- }
-
- 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){
+ }
+ }
+
+ 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>
- 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>
+ if(e == NULL) printf("e is NULL\n");
+ }
+ </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·name>Property</RT·name>
- <p>
- A <RT·term>property</RT·term> is a pair, where the components are called the <RT·term-em>name</RT·term-em> and the <RT·term-em>value</RT·term-em>. A <RT·term>name</RT·term> is an instance of a symbol and it must uniquely identify the property within its context. The value is a variable that can be written then read back.
- </p>
+ A <RT·term>property</RT·term> is a pair, where the components are called the <RT·term-em>name</RT·term-em> and the <RT·term-em>value</RT·term-em>. A <RT·term>name</RT·term> is an instance of a symbol and it must uniquely identify the property within its context. The value is a variable that can be written then read back.
+ </p>
</RT·section>
<RT·section>
<RT·name>Dictionary and reference</RT·name>
- <p>A <RT·term>dictionary</RT·term> is a property context object. It is a set of properties, where a property may be selected from the set given its name, which is a symbol instance. The corresponding property value is then the <RT·term>referenced object</RT·term>.</p>
+
<p>A <RT·term>dictionary</RT·term> is a property context object. It is a set of properties, where a property may be selected from the set given its name, which is a symbol instance. The corresponding property value is then the <RT·term>referenced object</RT·term>.</p>
- <p>A <RT·term>reference</RT·term> is a dictionary key which uniquely identifies a property in the dictionary. A dictionary is also known as a symbol table. In hardware design, the symbols are often unsigned Integers, AKA Natural Numbers, and a symbol table is implemented using an array that is indexed into using the key.</p>
+ <p>A <RT·term>reference</RT·term> is a dictionary key which uniquely identifies a property in the dictionary. A dictionary is also known as a symbol table. In hardware design, the symbols are often unsigned Integers, AKA Peano Numbers, and a symbol table is implemented using an array that is indexed into using the key.</p>
- <p>Any programming object that holds other objects is a container, whereas a dictionary is a specific type of key access container.</p>
+
<p>Any programming object that holds other objects is a container, whereas a dictionary is a specific type of key access container.</p>
</RT·section>
<RT·section id="Section·tape-cell">
<RT·name>A Turing Machine tape cell</RT·name>
- <p>
- A <RT·term>cell</RT·term> is the <RT·term>square</RT·term> from Alan Turing's 1936 paper <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>. Mathematically, a cell is a referencable distinct identifiable set, with one to three property members depending on the type of cell.
- </p>
+ A <RT·term>cell</RT·term> is the <RT·term>square</RT·term> from Alan Turing's 1936 paper <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>. Mathematically, a cell is a referencable distinct identifiable set, with one to three property members depending on the type of cell.
+ </p>
- <p>
- A <RT·term>leftmost cell</RT·term> is a set of two properties named 'right neighbor' and 'data'. A <RT·term>rightmost cell</RT·term> is a set of two properties named 'left neighbor' and 'data'. An <RT·term>medial cell</RT·term> is a set holding three properties: a 'left neighbor', a 'right neighbor', and 'data'. While an <RT·term>island cell</RT·term> owns a single compulsory property, that of 'data'.
- </p>
+ A <RT·term>leftmost cell</RT·term> is a set of two properties named 'right neighbor' and 'data'. A <RT·term>rightmost cell</RT·term> is a set of two properties named 'left neighbor' and 'data'. An <RT·term>medial cell</RT·term> is a set holding three properties: a 'left neighbor', a 'right neighbor', and 'data'. While an <RT·term>island cell</RT·term> owns a single compulsory property, that of 'data'.
+ </p>
- <p>
- The value of a neighbor property is a non-null single reference to a cell. The value of a data property is strictly an instance of an alphabet symbol, or alternatively, an instance of the empty symbol.
- </p>
+ The value of a neighbor property is a non-null single reference to a cell. The value of a data property is strictly an instance of an alphabet symbol, or alternatively, an instance of the empty symbol.
+ </p>
</RT·section>
<RT·section>
<RT·name>Tape</RT·name>
- <p>
- A tape is a set containing exactly one leftmost cell and an infinite number of medial cells. For each cell in the set, called cell A, if cell A has a right neighbor that is cell B, then cell B's left neighbor is cell A. Similarly, if cell A has a left neighbor of cell B, then cell B's right neighbor is cell A. Furthermore, any cell in the set must be reachable by traversing right neighbors starting from the leftmost cell, in a finite number of steps.
- </p>
+ A tape is a set containing exactly one leftmost cell and an infinite number of medial cells. For each cell in the set, called cell A, if cell A has a right neighbor that is cell B, then cell B's left neighbor is cell A. Similarly, if cell A has a left neighbor of cell B, then cell B's right neighbor is cell A. Furthermore, any cell in the set must be reachable by traversing right neighbors starting from the leftmost cell, in a finite number of steps.
+ </p>
- <p>
- To say that a tape is infinite, and to simultaneously require that any cell can be reached in a finite number of steps, means that after reaching said cell, there will always be further cells to the right. Consequently, though <em>any</em> cell can be reached in finite hops starting at the leftmost cell, a finite traversal of the tape can not visit <em>all</em> of the cells. This seeming contradiction is at the very heart of the definition of the countable infinity in mathematics.
- </p>
+ To say that a tape is infinite, and to simultaneously require that any cell can be reached in a finite number of steps, means that after reaching said cell, there will always be further cells to the right. Consequently, though <em>any</em> cell can be reached in finite hops starting at the leftmost cell, a finite traversal of the tape can not visit <em>all</em> of the cells. This seeming contradiction is at the very heart of the definition of the countable infinity in mathematics.
+ </p>
- <p>
- In conventional computation theory, once a tape is defined, the cell neighbor properties values are fixed. Cells don't move, new cells cannot be added, and cells existing on the tape cannot be removed. This fits the definition of a <RT·term>space</RT·term>, so we can say that a Turing Machine tape has a constant, fixed, linear <RT·term>topology</RT·term>. This permanence of cells matches the reality of hardware memories. On the other hand, it does not track well with general memory containers such as linked lists where <RT·term>destructive</RT·term> operations are often permitted.
- </p>
+ In conventional computation theory, once a tape is defined, the cell neighbor properties values are fixed. Cells don't move, new cells cannot be added, and cells existing on the tape cannot be removed. This fits the definition of a <RT·term>space</RT·term>, so we can say that a Turing Machine tape has a constant, fixed, linear <RT·term>topology</RT·term>. This permanence of cells matches the reality of hardware memories. On the other hand, it does not track well with general memory containers such as linked lists where <RT·term>destructive</RT·term> operations are often permitted.
+ </p>
- <p>
- Nor can a cell data property be removed; however, unlike for cell neighbor property values, the cell data property value can be changed while the Turing Machine is running. In fact some people would say this is the whole point of running a Turing Machine.
- </p>
+ Nor can a cell data property be removed; however, unlike for cell neighbor property values, the cell data property value can be changed while the Turing Machine is running. In fact some people would say this is the whole point of running a Turing Machine.
+ </p>
- <p>
- An empty tape is filled with empty symbols. However, as we noted above, a Turing Machine cannot visit all the cells on a tape, so a Turing Machine cannot erase a tape in advance for another Turing Machine to use. Say a Turing Machine tried to erase a tape by writing the empty symbol, then stepping right, then repeating. At some point it must halt. When it halts some number of cells will have been written with the empty symbols, but there will be further cells to the right of the cell the machine halted at, which have not yet been erased. So for example, if a machine wrote 10 cells with the empty symbol, then it might be the case that the prior user of the tape had written data to 11 of the cells. Without historical knowledge the eraser machine can not know where to stop. So here we see another meaning of infinity, it speaks to the situation of not having historical knowledge. And thus, we are left to decree into existence an empty tape, or as the mathematicians say, empty tapes are available <em>by definition</em>.
- </p>
+ An empty tape is filled with empty symbols. However, as we noted above, a Turing Machine cannot visit all the cells on a tape, so a Turing Machine cannot erase a tape in advance for another Turing Machine to use. Say a Turing Machine tried to erase a tape by writing the empty symbol, then stepping right, then repeating. At some point it must halt. When it halts some number of cells will have been written with the empty symbols, but there will be further cells to the right of the cell the machine halted at, which have not yet been erased. So for example, if a machine wrote 10 cells with the empty symbol, then it might be the case that the prior user of the tape had written data to 11 of the cells. Without historical knowledge the eraser machine can not know where to stop. So here we see another meaning of infinity, it speaks to the situation of not having historical knowledge. And thus, we are left to decree into existence an empty tape, or as the mathematicians say, empty tapes are available <em>by definition</em>.
+ </p>
- <p>
- Mathematically, a Turing Machine tape is a specialized path graph. The neighbor properties are the edges. In this special form, properties are attached to the edges. A Turing Machine has a clock based state controller. Taking a step is an atomic operation. The machine is either in state <RT·math>q_i</RT·math> or in state <RT·math>q_{i+1}</RT·math>, there is no mathematical meaning given to the concept of <em>during a step</em>, which is why no properties are added to the edges of the tape path graph. This is not to say that some analysis of a Turing Machine program won't take pairs of nodes from the path graph and give them meaning, thus effectively giving properties to the arcs. However, this would not be part of the machine definition, such a program must go through the additional effort of making node pairs, because the machine itself does not provide the program with a feature for attaching properties directly to the neighbor property itself.</p>
+ Mathematically, a Turing Machine tape is a specialized path graph. The neighbor properties are the edges. In this special form, properties are attached to the edges. A Turing Machine has a clock based state controller. Taking a step is an atomic operation. The machine is either in state <RT·math>q_i</RT·math> or in state <RT·math>q_{i+1}</RT·math>, there is no mathematical meaning given to the concept of <em>during a step</em>, which is why no properties are added to the edges of the tape path graph. This is not to say that some analysis of a Turing Machine program won't take pairs of nodes from the path graph and give them meaning, thus effectively giving properties to the arcs. However, this would not be part of the machine definition, such a program must go through the additional effort of making node pairs, because the machine itself does not provide the program with a feature for attaching properties directly to the neighbor property itself.</p>
- <p>An example of a non-Turing tape like model is the Emacs vertical line cursor model, where a cursor is said to be between characters. An ASCII file offers no such feature as 'in between' characters. Like a Turing Machine tape, a medial character in an ASCII file has a left neighbor and a right neighbor character. Any attempt to represent an in between cursor within the file itself would require inserting more characters into the file under the same model of every medial character having a left and a right character. Consequently, though emacs presents a model where cursor is located in between two characters, this model is only due to the interpretation of the functions' actual effects presented to users in the documentation. For example, instead of saying a cursor is located upon a character, and that inserting a character inserts the character to the right of the given character, the manual gives the description that the new character is inserted at the cursor location, where said cursor is in between the given character and its right neighbor. Thus the documentation presents the user with one model, which by necessity of using standard library calls to work with files, is built upon another model.</p>
+
<p>An example of a non-Turing tape like model is the Emacs vertical line cursor model, where a cursor is said to be between characters. An ASCII file offers no such feature as 'in between' characters. Like a Turing Machine tape, a medial character in an ASCII file has a left neighbor and a right neighbor character. Any attempt to represent an in between cursor within the file itself would require inserting more characters into the file under the same model of every medial character having a left and a right character. Consequently, though emacs presents a model where cursor is located in between two characters, this model is only due to the interpretation of the functions' actual effects presented to users in the documentation. For example, instead of saying a cursor is located upon a character, and that inserting a character inserts the character to the right of the given character, the manual gives the description that the new character is inserted at the cursor location, where said cursor is in between the given character and its right neighbor. Thus the documentation presents the user with one model, which by necessity of using standard library calls to work with files, is built upon another model.</p>
</RT·section>
</RT·section>
- <!--------------------------------------------------------------------------------->
+ <!--------------------------------------------------------------------------------->
<RT·section id="Section·computational-analysis">
<RT·name>Computational Analysis</RT·name>
<RT·section>
<RT·name>Definition</RT·name>
- <p>
- In mathematics, <RT·term>analysis</RT·term> is the rigorous study of limits, continuity, rates of change, and bounds. It encompasses several specialized branches. Real analysis studies the behavior of real numbers, sequences, and continuous functions. Complex analysis extends these principles to functions of complex variables. Functional analysis examines vector spaces where the elements themselves are functions. Numerical analysis focuses on the design of algorithms to yield approximate solutions for continuous mathematical problems. Harmonic analysis studies the representation of functions or signals as the superposition of basic waves, such as Fourier series. Across all these branches, analysis provides a formal framework for evaluating mathematical objects.
- </p>
+ In mathematics, <RT·term>analysis</RT·term> is the rigorous study of limits, continuity, rates of change, and bounds. It encompasses several specialized branches. Real analysis studies the behavior of real numbers, sequences, and continuous functions. Complex analysis extends these principles to functions of complex variables. Functional analysis examines vector spaces where the elements themselves are functions. Numerical analysis focuses on the design of algorithms to yield approximate solutions for continuous mathematical problems. Harmonic analysis studies the representation of functions or signals as the superposition of basic waves, such as Fourier series. Across all these branches, analysis provides a formal framework for evaluating mathematical objects.
+ </p>
- <p>
- In computation theory, <RT·term>computational analysis</RT·term> is defined as the static evaluation of a formal system or machine definition to deduce its absolute boundaries and properties. This process remains entirely distinct from dynamically executing the machine to yield a computed result.
- </p>
+ In computation theory, <RT·term>computational analysis</RT·term> is defined as the static evaluation of a formal system or machine definition to deduce its absolute boundaries and properties. This process remains entirely distinct from dynamically executing the machine to yield a computed result.
+ </p>
- <p>
- 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>
+ 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>
- 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>
+ 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>
- As an analyzer does not run the machine being analyzed, 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.
- </p>
+ As an analyzer does not run the machine being analyzed, 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.
+ </p>
</RT·section>
<RT·section>
<RT·name>second-order Arithmetic</RT·name>
- <p>
- In their 1990 paper, "Exact Real Arithmetic: Formulating Real Numbers as Functions," Hans-Juergen Boehm and Robert Cartwright presented a system using Turing Machines to represent 'constructive real numbers', or exact real arithmetic. This directly implements a core concept from Alan Turing's 1936 paper of the "computable number." <RT·endnote>Hans-J. Boehm and Robert Cartwright, "Exact Real Arithmetic: Formulating Real Numbers as Functions," in <em>Design and Implementation of Symbolic Computation Systems</em> (Berlin: Springer, 1990), 43 52.</RT·endnote> Boehm translated this computation theory into a practical software architecture. Instead of storing a real number as a fixed-width floating-point approximation, Boehm's system represents a real number as a lazy evaluation function.
- </p>
-
- <p>
- Let us employ Boehm and Cartwright's constructive real numbers, though in <RT·term>second-order arithmetic</RT·term> rather than a lazy evaluation system. Because we are doing second-order arithmetic, our programs need not be in the form of generators that yield a new value when called, but can be arbitrary programs containing complex control logic. If run, they evaluate physical conditions and produce results. As we are in the second-order, however, we will not run them, but rather analyze and manipulate their structural logic.
- </p>
-
- <p>
- Consider an illustrative example. We start by defining a fundamental language for communicating with the head and tape transport unit. The statements we communicate to our tape transport unit will be explicit physical instructions: <RT·code>(step)</RT·code>, <RT·code>(left)</RT·code>, <RT·code>(read)</RT·code>, and <RT·code>(write symbol)</RT·code>. In the first-order, evaluating these instructions physically actuates the tape.
- </p>
-
- <p>
- 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·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·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.
- </p>
-
- <p>
- 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·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
+ In their 1990 paper, "Exact Real Arithmetic: Formulating Real Numbers as Functions," Hans-Juergen Boehm and Robert Cartwright presented a system using Turing Machines to represent 'constructive real numbers', or exact real arithmetic. This directly implements a core concept from Alan Turing's 1936 paper of the "computable number." <RT·endnote>Hans-J. Boehm and Robert Cartwright, "Exact Real Arithmetic: Formulating Real Numbers as Functions," in <em>Design and Implementation of Symbolic Computation Systems</em> (Berlin: Springer, 1990), 43 52.</RT·endnote> Boehm translated this computation theory into a practical software architecture. Instead of storing a real number as a fixed-width floating-point approximation, Boehm's system represents a real number as a lazy evaluation function.
+ </p>
+
+ Let us employ Boehm and Cartwright's constructive real numbers, though in <RT·term>second-order arithmetic</RT·term> rather than a lazy evaluation system. Because we are doing second-order arithmetic, our programs need not be in the form of generators that yield a new value when called, but can be arbitrary programs containing complex control logic. If run, they evaluate physical conditions and produce results. As we are in the second-order, however, we will not run them, but rather analyze and manipulate their structural logic.
+ </p>
+
+ Consider an illustrative example. We start by defining a fundamental language for communicating with the head and tape transport unit. The statements we communicate to our tape transport unit will be explicit physical instructions: <RT·code>(step)</RT·code>, <RT·code>(left)</RT·code>, <RT·code>(read)</RT·code>, and <RT·code>(write symbol)</RT·code>. In the first-order, evaluating these instructions physically actuates the tape.
+ </p>
+
+ 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·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 Peano Number five</RT·name>
+ </RT·counter·step>
+
+
<p>Similarly, the AST for the number 3:</p>
+
+ <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 Peano Number three</RT·name>
+ </RT·counter·step>
+
+ 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.
+ </p>
+
+ 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·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))
- ))
+ (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
+ 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))
- )
+ (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·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.
- </p>
-
- <p>
- Because of the purity of the Lisp syntax, we are able to present a remedial simplifier example here. A <RT·code>(step)</RT·code> followed by a <RT·code>(left)</RT·code> annihilate each other, resulting in zero net movement of the tape head. Similarly, on an initially empty tape, a <RT·code>(write s)</RT·code> followed immediately by overwriting with the empty symbol <RT·code>(write □)</RT·code> annihilate each other.
- </p>
-
- <p>
- 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·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
+ ,@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 Peano Number ASTs to this composer, and we get as a result a newly synthesized AST.</p>
+
+ <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>
+
+ 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.
+ </p>
+
+ Because of the purity of the Lisp syntax, we are able to present a remedial simplifier example here. A <RT·code>(step)</RT·code> followed by a <RT·code>(left)</RT·code> annihilate each other, resulting in zero net movement of the tape head. Similarly, on an initially empty tape, a <RT·code>(write s)</RT·code> followed immediately by overwriting with the empty symbol <RT·code>(write □)</RT·code> annihilate each other.
+ </p>
+
+ 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 Peano 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·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) '(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)))
+ (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*
+ t
+ (cons
+ (first cmds)
+ (remove-annihilations (cdr cmds))
+ ))))
+
+ (defun simplify-machine (ast)
+ (let*
(
- (cmds (rest ast))
- (reduced (remove-annihilations cmds))
- )
+ (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·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>
+ (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·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>
</RT·section>
<RT·section>
<RT·name>The multiplicative inverse of the additive identity</RT·name>
- <p>
- Generally it is more efficient to perform arithmetic in the first-order. Also, it is easier to write Turing Machine control programs if we take Natural Number arithmetic as already available, say, from a subroutine library. On processors fixed word length arithmetic is built into the hardware. Where second-order computation becomes useful is in places where a result cannot be computed in the first-order.
- </p>
-
- <p>
- The IEEE 754 floating-point standard includes error algebra tags. These are explored in depth by Popova, Evgenija D. "On a Formally Correct Implementation of IEEE Computer Arithmetic." Journal of Universal Computer Science 1, no. 7 (1995): 560 569. This is a form of second-order arithmetic, because each of the error tags is standing in for a machine that did not complete. When a computation fails to result in a first-order object, this becomes a gateway for replacing the result with a second-order object.
- </p>
-
- <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·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·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·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.
- </p>
-
- <p>
- The divide machine cannot be run to produce a value, as any value from the field assigned to it would lead to contradictions. Stated more precisely, for <RT·math>x · y = q</RT·math> operations, when given an <RT·math>x</RT·math> and a <RT·code>q</RT·code> value, there is only one possible <RT·math>y</RT·math> value, and it can be recovered with <RT·math>q/x</RT·math>. However, when <RT·math>x</RT·math> is zero, and only when it is zero, <RT·code>q</RT·code> is solely determined by <RT·math>x</RT·math> independent of <RT·math>y</RT·math>, so <RT·math>y</RT·math> is ignored; it could be any value. There is no way to recover it from <RT·math>q/x</RT·math>.
- </p>
+ Generally it is more efficient to perform arithmetic in the first-order. Also, it is easier to write Turing Machine control programs if we take Peano Number arithmetic as already available, say, from a subroutine library. On processors fixed word length arithmetic is built into the hardware. Where second-order computation becomes useful is in places where a result cannot be computed in the first-order.
+ </p>
+
+ The IEEE 754 floating-point standard includes error algebra tags. These are explored in depth by Popova, Evgenija D. "On a Formally Correct Implementation of IEEE Computer Arithmetic." Journal of Universal Computer Science 1, no. 7 (1995): 560 569. This is a form of second-order arithmetic, because each of the error tags is standing in for a machine that did not complete. When a computation fails to result in a first-order object, this becomes a gateway for replacing the result with a second-order object.
+ </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·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·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·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>
+
+ There is no special help here. Hence, <RT·code>(divide 0 0)</RT·code> remains as an error flag.
+ </p>
+
+ The divide machine cannot be run to produce a value, as any value from the field assigned to it would lead to contradictions. Stated more precisely, for <RT·math>x · y = q</RT·math> operations, when given an <RT·math>x</RT·math> and a <RT·code>q</RT·code> value, there is only one possible <RT·math>y</RT·math> value, and it can be recovered with <RT·math>q/x</RT·math>. However, when <RT·math>x</RT·math> is zero, and only when it is zero, <RT·code>q</RT·code> is solely determined by <RT·math>x</RT·math> independent of <RT·math>y</RT·math>, so <RT·math>y</RT·math> is ignored; it could be any value. There is no way to recover it from <RT·math>q/x</RT·math>.
+ </p>
</RT·section>
<RT·section>
<RT·name>Evaluating and Extending</RT·name>
- <p>
- When a machine is 1) programmed to perform a function <RT·math>f</RT·math>, 2) has its tape initialized with a constant input value, say <RT·math>t</RT·math> (which can be a vector of values), and 3) is then run, writing the result <RT·math>f(t)</RT·math> and halting; we say that the run <RT·term>evaluates</RT·term> the function at <RT·math>t</RT·math>.
- </p>
-
- <p>
- When an evaluator erases the input and leaves only the result in its place, we say it is a substitution evaluator. It is an inconsequential modification to add multiple tapes each with their own tape head to a Turing Machine, so it is possible that an evaluator will have a dedicated tape for the input, a dedicated tape for the output, and have zero or more additional tapes for scratch work. In which case, instead of substitution, one tape is mounted as an input, the machine is run until it halts, and then separately the result tape can be unmounted to potentially be used in a downstream computation.
- </p>
-
- <p>
- In a variation of analytical evaluation, we can instead mount an initial value for a function, and call a machine to repeatedly <RT·term>extend</RT·term> the function. To state this more precisely, when a machine tape is given the initial value of <RT·math>f(t_i)</RT·math> on its input tape, and then when run until it halts having written the result <RT·math>f(t_{i+1})</RT·math> to the tape, we say that running the machine extends the function. Typically extension machines are designed so they can be used recurrently to extend the function indefinitely, thus producing a sequence of function values, <RT·math>f(t_0), f(t_1), f(t_2), \ldots</RT·math>.
- </p>
-
- <p>
- The difference between adjacent function values in the above sequence is called the first finite difference. The forward first difference is defined as:
- <RT·math>δ_i = f(t_{i+1}) - f(t_i)</RT·math>.
- While the backwards first difference is
- <RT·math>δ_i = f(t_i) - f(t_{i-1})</RT·math>.
- If 'forward' or 'backwards' is not specified, then the difference is taken to be 'forward'. Hence, extending a function is identical to adding the first difference. Thus a sequence of function values implies a sequence of first differences.
- </p>
-
- <p>
- A second difference can be defined as the difference between two adjacent first differences. A second difference can be added to a prior first difference to create the next first difference, which could then be added to a prior function value to extend the function to its next value. This pattern can be extended to any number of levels.
- </p>
-
- <p>
- The mechanical application of finite differences was famously leveraged by Charles Babbage in the design of his Difference Engine. By examining the discrete changes between consecutive outputs of a polynomial function, a person can observe that the higher-order differences eventually reduce to a constant. This structure allows the computation of subsequent sequential values using only addition, bypassing the need for complex multiplication machinery.
- </p>
-
- <p>
- Let us construct a forward difference pyramid for the polynomial <RT·math>f(t) = t^2</RT·math>.
- </p>
-
- <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.
- </p>
-
- <p>
- 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·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.
- </p>
-
- <p>
- For Call 2, the input tape is the result tape from Call 1. Execution then proceeds identically to Call 1. This pattern repeats for all successive calls. A person can see the values of <RT·math>t^2</RT·math> as the first number on each result tape. Any polynomial can be computed in this manner, and the only ALU required is an adder that is also capable of subtraction.
- </p>
+ When a machine is 1) programmed to perform a function <RT·math>f</RT·math>, 2) has its tape initialized with a constant input value, say <RT·math>t</RT·math> (which can be a vector of values), and 3) is then run, writing the result <RT·math>f(t)</RT·math> and halting; we say that the run <RT·term>evaluates</RT·term> the function at <RT·math>t</RT·math>.
+ </p>
+
+ When an evaluator erases the input and leaves only the result in its place, we say it is a substitution evaluator. It is an inconsequential modification to add multiple tapes each with their own tape head to a Turing Machine, so it is possible that an evaluator will have a dedicated tape for the input, a dedicated tape for the output, and have zero or more additional tapes for scratch work. In which case, instead of substitution, one tape is mounted as an input, the machine is run until it halts, and then separately the result tape can be unmounted to potentially be used in a downstream computation.
+ </p>
+
+ In a variation of analytical evaluation, we can instead mount an initial value for a function, and call a machine to repeatedly <RT·term>extend</RT·term> the function. To state this more precisely, when a machine tape is given the initial value of <RT·math>f(t_i)</RT·math> on its input tape, and then when run until it halts having written the result <RT·math>f(t_{i+1})</RT·math> to the tape, we say that running the machine extends the function. Typically extension machines are designed so they can be used recurrently to extend the function indefinitely, thus producing a sequence of function values, <RT·math>f(t_0), f(t_1), f(t_2), \ldots</RT·math>.
+ </p>
+
+ The difference between adjacent function values in the above sequence is called the first finite difference. The forward first difference is defined as:
+ <RT·math>δ_i = f(t_{i+1}) - f(t_i)</RT·math>.
+ While the backwards first difference is
+ <RT·math>δ_i = f(t_i) - f(t_{i-1})</RT·math>.
+ If 'forward' or 'backwards' is not specified, then the difference is taken to be 'forward'. Hence, extending a function is identical to adding the first difference. Thus a sequence of function values implies a sequence of first differences.
+ </p>
+
+ A second difference can be defined as the difference between two adjacent first differences. A second difference can be added to a prior first difference to create the next first difference, which could then be added to a prior function value to extend the function to its next value. This pattern can be extended to any number of levels.
+ </p>
+
+ The mechanical application of finite differences was famously leveraged by Charles Babbage in the design of his Difference Engine. By examining the discrete changes between consecutive outputs of a polynomial function, a person can observe that the higher-order differences eventually reduce to a constant. This structure allows the computation of subsequent sequential values using only addition, bypassing the need for complex multiplication machinery.
+ </p>
+
+ Let us construct a forward difference pyramid for the polynomial <RT·math>f(t) = t^2</RT·math>.
+ </p>
+
+ <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 -->
+ <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>
+
+ 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.
+ </p>
+
+ 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·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>
+
+ 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.
+ </p>
+
+ For Call 2, the input tape is the result tape from Call 1. Execution then proceeds identically to Call 1. This pattern repeats for all successive calls. A person can see the values of <RT·math>t^2</RT·math> as the first number on each result tape. Any polynomial can be computed in this manner, and the only ALU required is an adder that is also capable of subtraction.
+ </p>
<RT·section>
<RT·name>Lemma: Only row 0 is needed</RT·name>
- <p>
- The extension function can be called any number of times when the initial tape is identical to row 0 of the table of finite differences. No other row is needed from the table of finite differences.
- </p>
+ The extension function can be called any number of times when the initial tape is identical to row 0 of the table of finite differences. No other row is needed from the table of finite differences.
+ </p>
- <p>
- This follows from the mechanical procedure given above for computing the next row of the table from any given row.
- </p>
+ This follows from the mechanical procedure given above for computing the next row of the table from any given row.
+ </p>
</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>
- Let the <RT·term>extent</RT·term> refer to the maximum index for accessing a component of a vector; the extent is often denoted as <RT·math>\omega</RT·math>. Performing extensions to calculate the function value at call <RT·math>\omega</RT·math> makes use of the initial tape up to index <RT·math>\omega</RT·math>, or as many nonzero values as are available up to that extent.
- </p>
-
- <p>
- To make this precise, let us define the <RT·term>difference vector</RT·term> at call <RT·math>k</RT·math> as <RT·math>D_k</RT·math>. The components of this vector are <RT·math>D_{k, 0}, D_{k, 1}, \ldots</RT·math> up to the maximum available difference. The first component, <RT·math>D_{k, 0}</RT·math>, is the function value itself. The component <RT·math>D_{k, 1}</RT·math> is the first difference, and so on.
- </p>
-
- <p>
- Thus, this lemma claims that to compute <RT·math>D_{\omega, 0}</RT·math>, the highest component index accessed from the initial tape vector <RT·math>D_{0, i}</RT·math> will be <RT·math>i = \omega</RT·math>.
- </p>
-
- <p>
- Note that to compute the <RT·math>D_{k, 0}</RT·math> result by the mechanical procedure given above requires adding the input tape first difference to the prior difference. That is, <RT·math>D_{k, 0} = D_{k-1, 0} + D_{k-1, 1}</RT·math>. Hence we see immediately the lemma holds for the first call where <RT·math>k = \omega = 1</RT·math>.
- </p>
-
- <p>
- For an arbitrary <RT·math>k</RT·math> value we discovered that the highest index required of the <RT·math>D_{k-1, i}</RT·math> vector is <RT·math>i=1</RT·math>.
- The value <RT·math>D_{k-1, 1}</RT·math> is computed from our mechanical procedure as
- <RT·math>D_{k-1, 1} = D_{k-2, 1} + D_{k-2, 2}</RT·math>. Given we already know that to compute the value merely requires the prior value and first difference, we find that the largest index needed from vector <RT·math>D_{k-2, i}</RT·math> is 2.
- </p>
-
- <p>
- There is a strict linear progression here. The computation of any component <RT·math>D_{k, i}</RT·math> inherently requires <RT·math>D_{k-1, i}</RT·math> and <RT·math>D_{k-1, i+1}</RT·math>. Therefore, each step backwards in time <RT·math>k</RT·math> expands the required index <RT·math>i</RT·math> by exactly one. By induction, computing the base value <RT·math>D_{\omega, 0}</RT·math> at call <RT·math>\omega</RT·math> requires tracing back <RT·math>\omega</RT·math> steps to the initial tape at <RT·math>k=0</RT·math>, which forces the maximum accessed index to be <RT·math>0 + \omega = \omega</RT·math>. Thus, the highest required component from the initial tape is <RT·math>D_{0, \omega}</RT·math>.
- </p>
-
- <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·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·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.
- </p>
+ Let the <RT·term>extent</RT·term> refer to the maximum index for accessing a component of a vector; the extent is often denoted as <RT·math>\omega</RT·math>. Performing extensions to calculate the function value at call <RT·math>\omega</RT·math> makes use of the initial tape up to index <RT·math>\omega</RT·math>, or as many nonzero values as are available up to that extent.
+ </p>
+
+ To make this precise, let us define the <RT·term>difference vector</RT·term> at call <RT·math>k</RT·math> as <RT·math>D_k</RT·math>. The components of this vector are <RT·math>D_{k, 0}, D_{k, 1}, \ldots</RT·math> up to the maximum available difference. The first component, <RT·math>D_{k, 0}</RT·math>, is the function value itself. The component <RT·math>D_{k, 1}</RT·math> is the first difference, and so on.
+ </p>
+
+ Thus, this lemma claims that to compute <RT·math>D_{\omega, 0}</RT·math>, the highest component index accessed from the initial tape vector <RT·math>D_{0, i}</RT·math> will be <RT·math>i = \omega</RT·math>.
+ </p>
+
+ Note that to compute the <RT·math>D_{k, 0}</RT·math> result by the mechanical procedure given above requires adding the input tape first difference to the prior difference. That is, <RT·math>D_{k, 0} = D_{k-1, 0} + D_{k-1, 1}</RT·math>. Hence we see immediately the lemma holds for the first call where <RT·math>k = \omega = 1</RT·math>.
+ </p>
+
+ For an arbitrary <RT·math>k</RT·math> value we discovered that the highest index required of the <RT·math>D_{k-1, i}</RT·math> vector is <RT·math>i=1</RT·math>.
+ The value <RT·math>D_{k-1, 1}</RT·math> is computed from our mechanical procedure as
+ <RT·math>D_{k-1, 1} = D_{k-2, 1} + D_{k-2, 2}</RT·math>. Given we already know that to compute the value merely requires the prior value and first difference, we find that the largest index needed from vector <RT·math>D_{k-2, i}</RT·math> is 2.
+ </p>
+
+ There is a strict linear progression here. The computation of any component <RT·math>D_{k, i}</RT·math> inherently requires <RT·math>D_{k-1, i}</RT·math> and <RT·math>D_{k-1, i+1}</RT·math>. Therefore, each step backwards in time <RT·math>k</RT·math> expands the required index <RT·math>i</RT·math> by exactly one. By induction, computing the base value <RT·math>D_{\omega, 0}</RT·math> at call <RT·math>\omega</RT·math> requires tracing back <RT·math>\omega</RT·math> steps to the initial tape at <RT·math>k=0</RT·math>, which forces the maximum accessed index to be <RT·math>0 + \omega = \omega</RT·math>. Thus, the highest required component from the initial tape is <RT·math>D_{0, \omega}</RT·math>.
+ </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·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>
+
+ 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·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>
+
+ 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.
+ </p>
</RT·section>
<RT·section>
<RT·name>Lemma: A polynomial function of degree <RT·math>\omega</RT·math> will have a <RT·math>D_0</RT·math> vector of extent <RT·math>\omega</RT·math></RT·name>
- <p>
- A polynomial of degree <RT·math>\omega</RT·math> is defined by a highest order term <RT·math>a_\omega t^\omega</RT·math>. The first forward difference operator, <RT·math>δ f(t) = f(t+1) - f(t)</RT·math>, inherently cancels the <RT·math>t^\omega</RT·math> term. The binomial expansion of <RT·math>(t+1)^\omega</RT·math> yields <RT·math>t^\omega</RT·math> as its leading term, which subtracts out, leaving a new polynomial of exactly degree <RT·math>\omega - 1</RT·math>.
- </p>
+ A polynomial of degree <RT·math>\omega</RT·math> is defined by a highest order term <RT·math>a_\omega t^\omega</RT·math>. The first forward difference operator, <RT·math>δ f(t) = f(t+1) - f(t)</RT·math>, inherently cancels the <RT·math>t^\omega</RT·math> term. The binomial expansion of <RT·math>(t+1)^\omega</RT·math> yields <RT·math>t^\omega</RT·math> as its leading term, which subtracts out, leaving a new polynomial of exactly degree <RT·math>\omega - 1</RT·math>.
+ </p>
- <p>
- Taking successive finite differences reduces the degree of the polynomial by exactly one at each step. Consequently, the <RT·math>\omega</RT·math>th difference evaluates to a constant, and the next difference evaluates to exactly zero.
- </p>
+ Taking successive finite differences reduces the degree of the polynomial by exactly one at each step. Consequently, the <RT·math>\omega</RT·math>th difference evaluates to a constant, and the next difference evaluates to exactly zero.
+ </p>
</RT·section>
<RT·section>
<RT·name>Lemma: A <RT·math>D_0</RT·math> vector of finite extent <RT·math>\omega</RT·math> generates a polynomial function of degree <RT·math>\omega</RT·math></RT·name>
- <p>
- If an initial difference vector <RT·math>D_0</RT·math> has an extent of <RT·math>\omega</RT·math>, the sequence of function values generated by the machine corresponds to a polynomial of exactly degree <RT·math>\omega</RT·math>. A person can demonstrate this by algebraically recovering the polynomial constants, <RT·math>a_i</RT·math>, directly from the initial tape components, <RT·math>D_{0, i}</RT·math>.
- </p>
-
- <p>
- Consider an extent of <RT·math>\omega = 0</RT·math>, forming a polynomial of degree 0, <RT·math>f(t) = a_0</RT·math>. Evaluating at <RT·math>t = 0</RT·math> yields <RT·math>f(0) = a_0</RT·math>. Because the machine's initial value is <RT·math>D_{0,0}</RT·math>, a person establishes <RT·math>a_0 = D_{0,0}</RT·math>.
- </p>
-
- <p>
- When a person extends the extent to <RT·math>\omega = 1</RT·math>, the next term is added to form <RT·math>f(t) = a_0 + a_1 t</RT·math>. The first forward difference at <RT·math>t = 0</RT·math> is <RT·math>D_{0,1} = f(1) - f(0) = (a_0 + a_1) - a_0 = a_1</RT·math>. Therefore, <RT·math>a_1 = D_{0,1}</RT·math>. Note that the addition of the linear term did not change the evaluation at <RT·math>t = 0</RT·math>; the <RT·math>a_0</RT·math> constant remains firmly anchored to <RT·math>D_{0,0}</RT·math>.
- </p>
-
- <p>
- Extending to <RT·math>\omega = 2</RT·math>, the polynomial becomes <RT·math>f(t) = a_0 + a_1 t + a_2 t^2</RT·math>. The second difference at <RT·math>t = 0</RT·math> is calculated as <RT·math>D_{0,2} = f(2) - 2f(1) + f(0)</RT·math>. Substituting the polynomial yields <RT·math>D_{0,2} = (a_0 + 2a_1 + 4a_2) - 2(a_0 + a_1 + a_2) + a_0 = 2a_2</RT·math>. Thus, a person recovers <RT·math>a_2 = D_{0,2} / 2</RT·math>. The lower coefficient then adjusts to <RT·math>a_1 = D_{0,1} - a_2</RT·math>.
- </p>
-
- <p>
- Continuing to <RT·math>\omega = 3</RT·math>, the polynomial is <RT·math>f(t) = a_0 + a_1 t + a_2 t^2 + a_3 t^3</RT·math>. Evaluating the third difference <RT·math>D_{0,3}</RT·math> isolates the highest order term, yielding <RT·math>D_{0,3} = 6a_3</RT·math>. This allows immediate recovery of the highest constant: <RT·math>a_3 = D_{0,3} / 6</RT·math>.
- </p>
-
- <p>
- Once <RT·math>a_3</RT·math> is known, the shifting nature of the lower-order constants becomes apparent through back substitution. The second difference equation expands to <RT·math>D_{0,2} = 2a_2 + 6a_3</RT·math>. Substituting the known <RT·math>a_3</RT·math> allows recovery of <RT·math>a_2 = (D_{0,2} - 6a_3) / 2</RT·math>. Similarly, the first difference equation expands to <RT·math>D_{0,1} = a_1 + a_2 + a_3</RT·math>, which resolves to <RT·math>a_1 = D_{0,1} - a_2 - a_3</RT·math>. Through all of this shifting, <RT·math>a_0 = D_{0,0}</RT·math> remains entirely unperturbed.
- </p>
-
- <p>
- 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>
-
- <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.
- </p>
-
- <p>
- 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·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, section <RT·counter·read snapshot="Section·appendix_Stirling-numbers"></RT·counter·read>).
- </p>
-
- <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>.
- </p>
-
- <p>
- 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·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>.
- </p>
+ If an initial difference vector <RT·math>D_0</RT·math> has an extent of <RT·math>\omega</RT·math>, the sequence of function values generated by the machine corresponds to a polynomial of exactly degree <RT·math>\omega</RT·math>. A person can demonstrate this by algebraically recovering the polynomial constants, <RT·math>a_i</RT·math>, directly from the initial tape components, <RT·math>D_{0, i}</RT·math>.
+ </p>
+
+ Consider an extent of <RT·math>\omega = 0</RT·math>, forming a polynomial of degree 0, <RT·math>f(t) = a_0</RT·math>. Evaluating at <RT·math>t = 0</RT·math> yields <RT·math>f(0) = a_0</RT·math>. Because the machine's initial value is <RT·math>D_{0,0}</RT·math>, a person establishes <RT·math>a_0 = D_{0,0}</RT·math>.
+ </p>
+
+ When a person extends the extent to <RT·math>\omega = 1</RT·math>, the next term is added to form <RT·math>f(t) = a_0 + a_1 t</RT·math>. The first forward difference at <RT·math>t = 0</RT·math> is <RT·math>D_{0,1} = f(1) - f(0) = (a_0 + a_1) - a_0 = a_1</RT·math>. Therefore, <RT·math>a_1 = D_{0,1}</RT·math>. Note that the addition of the linear term did not change the evaluation at <RT·math>t = 0</RT·math>; the <RT·math>a_0</RT·math> constant remains firmly anchored to <RT·math>D_{0,0}</RT·math>.
+ </p>
+
+ Extending to <RT·math>\omega = 2</RT·math>, the polynomial becomes <RT·math>f(t) = a_0 + a_1 t + a_2 t^2</RT·math>. The second difference at <RT·math>t = 0</RT·math> is calculated as <RT·math>D_{0,2} = f(2) - 2f(1) + f(0)</RT·math>. Substituting the polynomial yields <RT·math>D_{0,2} = (a_0 + 2a_1 + 4a_2) - 2(a_0 + a_1 + a_2) + a_0 = 2a_2</RT·math>. Thus, a person recovers <RT·math>a_2 = D_{0,2} / 2</RT·math>. The lower coefficient then adjusts to <RT·math>a_1 = D_{0,1} - a_2</RT·math>.
+ </p>
+
+ Continuing to <RT·math>\omega = 3</RT·math>, the polynomial is <RT·math>f(t) = a_0 + a_1 t + a_2 t^2 + a_3 t^3</RT·math>. Evaluating the third difference <RT·math>D_{0,3}</RT·math> isolates the highest order term, yielding <RT·math>D_{0,3} = 6a_3</RT·math>. This allows immediate recovery of the highest constant: <RT·math>a_3 = D_{0,3} / 6</RT·math>.
+ </p>
+
+ Once <RT·math>a_3</RT·math> is known, the shifting nature of the lower-order constants becomes apparent through back substitution. The second difference equation expands to <RT·math>D_{0,2} = 2a_2 + 6a_3</RT·math>. Substituting the known <RT·math>a_3</RT·math> allows recovery of <RT·math>a_2 = (D_{0,2} - 6a_3) / 2</RT·math>. Similarly, the first difference equation expands to <RT·math>D_{0,1} = a_1 + a_2 + a_3</RT·math>, which resolves to <RT·math>a_1 = D_{0,1} - a_2 - a_3</RT·math>. Through all of this shifting, <RT·math>a_0 = D_{0,0}</RT·math> remains entirely unperturbed.
+ </p>
+
+ 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>
+
+ <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 -->
+ <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>
+
+ 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.
+ </p>
+
+ 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·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>
+
+ 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>
+
+ 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·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>
+
+ 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>.
+ </p>
+
+ 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·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>
+
+ 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>.
+ </p>
</RT·section>
</RT·section>
<RT·section>
<RT·name>Difference table for an exponential function</RT·name>
- <p>
- Here is the table of finite differences for the function <RT·math>2^t</RT·math>.
- </p>
-
- <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>
- Instead of attempting to write an infinite sequence to a physical tape, a person can encapsulate the generation logic within a dedicated Turing Machine. In the tradition of constructive arithmetic associated with Boehm, this generator machine acts as a virtual tape. When the primary extension machine requires the next difference component, it queries the generator machine, which computes and yields the value on demand. This lazy evaluation strategy elegantly handles functions with infinite difference sequences without exhausting finite memory.
- </p>
+ Here is the table of finite differences for the function <RT·math>2^t</RT·math>.
+ </p>
+
+ <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 -->
+ <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>
+
+ 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>
+
+ Instead of attempting to write an infinite sequence to a physical tape, a person can encapsulate the generation logic within a dedicated Turing Machine. In the tradition of constructive arithmetic associated with Boehm, this generator machine acts as a virtual tape. When the primary extension machine requires the next difference component, it queries the generator machine, which computes and yields the value on demand. This lazy evaluation strategy elegantly handles functions with infinite difference sequences without exhausting finite memory.
+ </p>
</RT·section>
<RT·section>
<RT·name>Composition of recurrence functions</RT·name>
- <p>If we desire to compose recurrence functions, in the first-order or the second-order, the call counts must first be synchronized.</p>
+
<p>If we desire to compose recurrence functions, in the first-order or the second-order, the call counts must first be synchronized.</p>
- <p>Say for example, we have a machine called fizz that adds 3 to the input on the tape, and another machine called buzz that adds 5 to the input on the tape, and we wanted to compose the two machines. We would have to define what a call to the resultant machine means to the machines in composition.</p>
+
<p>Say for example, we have a machine called fizz that adds 3 to the input on the tape, and another machine called buzz that adds 5 to the input on the tape, and we wanted to compose the two machines. We would have to define what a call to the resultant machine means to the machines in composition.</p>
- <p>If one call to the resultant machine makes the equivalent of one call to the fizz, and one to buzz, the the resultant machine can be simplified to add 8 to its input tape each time it is called. In contrast if one call to the resultant machine makes the equivalent of 5 calls to fizz, and 3 calls to buzz, then the resultant machine reduces to adding 30 to the input tape per call. The two machines are very different.</p>
+
<p>If one call to the resultant machine makes the equivalent of one call to the fizz, and one to buzz, the the resultant machine can be simplified to add 8 to its input tape each time it is called. In contrast if one call to the resultant machine makes the equivalent of 5 calls to fizz, and 3 calls to buzz, then the resultant machine reduces to adding 30 to the input tape per call. The two machines are very different.</p>
- <p>Performing operations with recurrence functions requires integrating a call algebra in addition to integrating the machines. Often this is handled by considering the machines being composed to be subroutines, and the outer controller than explicitly calls them. The call algebra can then be dynamic depending on the input. Calls can be skipped due to being inside conditionals, or performed an arbitrary number of times in loops. Though simple control structures that are static are more math like, and are more likely to be more affected by optimizations (simplifications).</p>
+
<p>Performing operations with recurrence functions requires integrating a call algebra in addition to integrating the machines. Often this is handled by considering the machines being composed to be subroutines, and the outer controller than explicitly calls them. The call algebra can then be dynamic depending on the input. Calls can be skipped due to being inside conditionals, or performed an arbitrary number of times in loops. Though simple control structures that are static are more math like, and are more likely to be more affected by optimizations (simplifications).</p>
</RT·section>
<RT·section>
<RT·name>A pole and zero cancellation</RT·name>
- <p>
- Here we circle back to the division by zero problem, though this time while extending functions. Let us begin with the two functions, <RT·math>f(t) = 2^t - 32</RT·math> and <RT·math>g(u) = u - 15</RT·math>. Both have <RT·math>D_0</RT·math> vectors, though the one for the exponential function is defined by a machine rather than by a value on a tape.
- </p>
-
- <p>
- We cannot do function based arithmetic on these until we synchronize them. Suppose that for each call of the <RT·math>f</RT·math> machine, there will be three calls to the <RT·code>g</RT·code> machine. So we can make a new machine that is called once, each time <RT·math>f</RT·math> is called, <RT·math>g(t) = 3t - 15</RT·math>.
- </p>
-
- <p>
- Now suppose we want to express the quotient of these two functions.
- </p>
-
- <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>
-
- <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>
- Evaluating this form in the first-order at the point <RT·math>t=5</RT·math> returns a <RT·code>(divide 0 0)</RT·code>. It is a strange thing, because when we plot <RT·math>h(t)</RT·math> values, against <RT·math>t</RT·math> there is an obvious correct value on the curve at <RT·math>t=5</RT·math>. There is no special feature that would make it questionable.
- </p>
-
- <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>
-
- <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 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>.
- </p>
-
- <p>
- Perhaps if we were performing nonstandard analysis, and extending by increments of epsilon in the domain at each step, the nonstandard analysis naturalization function would find that the differential value can be used as the value at the singularity. But here we are discussing finite differences <RT·endnote>H. Jerome Keisler, <em>Elementary Calculus: An Infinitesimal Approach</em>, 2nd ed. (Boston: Prindle, Weber and Schmidt, 1986).</RT·endnote>. We are not doing a local analysis here so as to derive a principle, but rather are trying to evaluate a function in the macro view.
- </p>
-
- <p>
- 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>
-
- <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·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>.
- </p>
-
- <p>
- As the second-order evaluation returned <RT·code>(divide f(k)|k=5 g(k)|k=5)</RT·code>, we can use L'Hôpital evaluator to resolve this indeterminate form <RT·math>D_{0,5}</RT·math>. Note this is during the creation of the <RT·math>D_0</RT·math> vector, so it is part of the simplification step, rather than being part of the evaluation of the quotient. The result will thus be used in producing an extension machine that extends through the singularity, so the user will not see any exceptional higher-order values while extending <RT·math>h(t)</RT·math>.
- </p>
-
- <p>
- 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·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>
-
- <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>
-
- <p>
- So the value of <RT·math>h(5)</RT·math> is transcendental, but all the machinery we were using, up until using L'Hôpital evaluator, was closed over the Rational field. That is why no matter how we tried to organize the difference tables, there was no way to find <RT·math>h(5)</RT·math>, or to find a <RT·math>D</RT·math> table for extending through it. This situation occurred due to introducing the <RT·math>2^t</RT·math> function. Had we remained with finite length <RT·math>D</RT·math> tables, i.e. finite degree polynomials, we could have used deconvolution of the <RT·math>D_0</RT·math> vectors, or synthetic division on the polynomials, to create the quotient.
- </p>
-
-
- <p>And for the victory lap, evaluation versus higher-order computation and function extension:</p>
-
- <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>
+ Here we circle back to the division by zero problem, though this time while extending functions. Let us begin with the two functions, <RT·math>f(t) = 2^t - 32</RT·math> and <RT·math>g(u) = u - 15</RT·math>. Both have <RT·math>D_0</RT·math> vectors, though the one for the exponential function is defined by a machine rather than by a value on a tape.
+ </p>
+
+ We cannot do function based arithmetic on these until we synchronize them. Suppose that for each call of the <RT·math>f</RT·math> machine, there will be three calls to the <RT·code>g</RT·code> machine. So we can make a new machine that is called once, each time <RT·math>f</RT·math> is called, <RT·math>g(t) = 3t - 15</RT·math>.
+ </p>
+
+ Now suppose we want to express the quotient of these two functions.
+ </p>
+
+ <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>
+
+ <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>
+
+
+ Evaluating this form in the first-order at the point <RT·math>t=5</RT·math> returns a <RT·code>(divide 0 0)</RT·code>. It is a strange thing, because when we plot <RT·math>h(t)</RT·math> values, against <RT·math>t</RT·math> there is an obvious correct value on the curve at <RT·math>t=5</RT·math>. There is no special feature that would make it questionable.
+ </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>
+
+ <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 -->
+ <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>
+
+ 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>
+
+ 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>.
+ </p>
+
+ Perhaps if we were performing nonstandard analysis, and extending by increments of epsilon in the domain at each step, the nonstandard analysis naturalization function would find that the differential value can be used as the value at the singularity. But here we are discussing finite differences <RT·endnote>H. Jerome Keisler, <em>Elementary Calculus: An Infinitesimal Approach</em>, 2nd ed. (Boston: Prindle, Weber and Schmidt, 1986).</RT·endnote>. We are not doing a local analysis here so as to derive a principle, but rather are trying to evaluate a function in the macro view.
+ </p>
+
+ 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>
+
+ <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>
+
+
+ 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·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>
+
+ 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>.
+ </p>
+
+ As the second-order evaluation returned <RT·code>(divide f(k)|k=5 g(k)|k=5)</RT·code>, we can use L'Hôpital evaluator to resolve this indeterminate form <RT·math>D_{0,5}</RT·math>. Note this is during the creation of the <RT·math>D_0</RT·math> vector, so it is part of the simplification step, rather than being part of the evaluation of the quotient. The result will thus be used in producing an extension machine that extends through the singularity, so the user will not see any exceptional higher-order values while extending <RT·math>h(t)</RT·math>.
+ </p>
+
+ 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·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>
+
+ <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>
+
+ 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>
+
+ So the value of <RT·math>h(5)</RT·math> is transcendental, but all the machinery we were using, up until using L'Hôpital evaluator, was closed over the Rational field. That is why no matter how we tried to organize the difference tables, there was no way to find <RT·math>h(5)</RT·math>, or to find a <RT·math>D</RT·math> table for extending through it. This situation occurred due to introducing the <RT·math>2^t</RT·math> function. Had we remained with finite length <RT·math>D</RT·math> tables, i.e. finite degree polynomials, we could have used deconvolution of the <RT·math>D_0</RT·math> vectors, or synthetic division on the polynomials, to create the quotient.
+ </p>
+
+
+
<p>And for the victory lap, evaluation versus higher-order computation and function extension:</p>
+
+ <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 -->
+ <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>
<RT·section>
<RT·name>Chapter discussion</RT·name>
- <p>The fundamental claim of computational analysis is that all functions can be viewed as discrete entities. Take this simple function:</p>
+
<p>The fundamental claim of computational analysis is that all functions can be viewed as discrete entities. Take this simple function:</p>
- <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>
+ <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>
+
<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>
- <p>The point of this chapter is to state that computational analysis exists, rather than to present a comprehensive computational analysis system. If a person is looking for practical systems for extending functions that expand precision, or for second-order computation, there are options.</p>
+
<p>The point of this chapter is to state that computational analysis exists, rather than to present a comprehensive computational analysis system. If a person is looking for practical systems for extending functions that expand precision, or for second-order computation, there are options.</p>
- <p>Hans J. Boehm and Robert Cartwright's work of expanding the precision of a computation on demand continued to mature. Boehm, while working at Google, authored a Java constructive reals library that powers the bundled Android calculator. When a person types in an expression, the system builds an Abstract Syntax Tree (AST) of the expression. The display interface determines how many digits fit on the screen and demands exactly that much precision from the root of the tree. The root function then recursively demands progressively higher precision from its operand functions until it achieves the strict error bounds required to guarantee every digit displayed on the screen is mathematically correct <RT·endnote>Hans J. Boehm, "Small data computing: Correct calculator arithmetic," Google Research, 2015. This library uses constructive real arithmetic to guarantee fully accurate results through demand driven evaluation.</RT·endnote>.
- </p>
+
<p>Hans J. Boehm and Robert Cartwright's work of expanding the precision of a computation on demand continued to mature. Boehm, while working at Google, authored a Java constructive reals library that powers the bundled Android calculator. When a person types in an expression, the system builds an Abstract Syntax Tree (AST) of the expression. The display interface determines how many digits fit on the screen and demands exactly that much precision from the root of the tree. The root function then recursively demands progressively higher precision from its operand functions until it achieves the strict error bounds required to guarantee every digit displayed on the screen is mathematically correct <RT·endnote>Hans J. Boehm, "Small data computing: Correct calculator arithmetic," Google Research, 2015. This library uses constructive real arithmetic to guarantee fully accurate results through demand driven evaluation.</RT·endnote>.
+ </p>
- <p>Wolfram Mathematica utilizes a true second-order computation system by keeping expressions in their exact symbolic form for as long as possible. An expression like <RT·code>Sqrt[2] + Pi</RT·code> remains an AST of symbols. It then relies on an extensive library of algebraic rewrite rules to simplify the tree. However, unlike Boehm and Cartwright's method of pulling precision through back propagating extension calls, when a numeric result is required, Mathematica runs the computation forward using significance arithmetic. Should there be insufficient precision at the result, it employs an adaptive retry loop <RT·endnote>Fredrik Johansson, "The significance of arithmetic," 2008. Mathematica implements significance arithmetic by approximating numbers as a floating-point value with an attached error estimate, allowing dynamic adaptation and iteration if precision falls below the required threshold. See also: Wolfram Language Documentation, "Arbitrary Precision Numbers" (https://reference.wolfram.com/language/tutorial/ArbitraryPrecisionNumbers.html).</RT·endnote>.
- </p>
+
<p>Wolfram Mathematica utilizes a true second-order computation system by keeping expressions in their exact symbolic form for as long as possible. An expression like <RT·code>Sqrt[2] + Pi</RT·code> remains an AST of symbols. It then relies on an extensive library of algebraic rewrite rules to simplify the tree. However, unlike Boehm and Cartwright's method of pulling precision through back propagating extension calls, when a numeric result is required, Mathematica runs the computation forward using significance arithmetic. Should there be insufficient precision at the result, it employs an adaptive retry loop <RT·endnote>Fredrik Johansson, "The significance of arithmetic," 2008. Mathematica implements significance arithmetic by approximating numbers as a floating-point value with an attached error estimate, allowing dynamic adaptation and iteration if precision falls below the required threshold. See also: Wolfram Language Documentation, "Arbitrary Precision Numbers" (https://reference.wolfram.com/language/tutorial/ArbitraryPrecisionNumbers.html).</RT·endnote>.
+ </p>
- <p>The approach I used differs from both of these approaches. Like them, the first step is to build the AST, but then the tree is evaluated in two phases. The first phase analyzes the tree, while creating error propagation expressions either per computation step or for atomic computation blocks. These take the form of symbolic expressions with error <RT·math>\epsilon</RT·math> in and error <RT·math>δ</RT·math> out, over the domain of the input. Then instead of back propagation of precision requests at run time, there is a back propagation of precision requirements at analysis time. This approach was used on the AMD K5 processor transcendental microcode to guarantee that computations yielded specified accuracy. The method is also well suited for setting the bus widths for application specific processors, because the analysis step can occur once at design time. <RT·endnote>Thomas Walker Lynch, A. Ahmed, M. Schulte, T. Callaway, and R. Tisdale, "The K5 Transcendental Functions," <em>Proceedings of the 12th IEEE Symposium on Computer Arithmetic</em>, 1995. DOI: 10.1109/ARITH.1995.465368.</RT·endnote> <RT·endnote>Thomas Walker Lynch, "Numerical Analysis of Computer Approximations," September 2018. DOI: 10.13140/RG.2.2.10906.49601. License CC BY 4.0. https://www.researchgate.net/publication/329402329_Numerical_Analysis_of_Computer_Approximations</RT·endnote>.
- </p>
+
<p>The approach I used differs from both of these approaches. Like them, the first step is to build the AST, but then the tree is evaluated in two phases. The first phase analyzes the tree, while creating error propagation expressions either per computation step or for atomic computation blocks. These take the form of symbolic expressions with error <RT·math>\epsilon</RT·math> in and error <RT·math>δ</RT·math> out, over the domain of the input. Then instead of back propagation of precision requests at run time, there is a back propagation of precision requirements at analysis time. This approach was used on the AMD K5 processor transcendental microcode to guarantee that computations yielded specified accuracy. The method is also well suited for setting the bus widths for application specific processors, because the analysis step can occur once at design time. <RT·endnote>Thomas Walker Lynch, A. Ahmed, M. Schulte, T. Callaway, and R. Tisdale, "The K5 Transcendental Functions," <em>Proceedings of the 12th IEEE Symposium on Computer Arithmetic</em>, 1995. DOI: 10.1109/ARITH.1995.465368.</RT·endnote> <RT·endnote>Thomas Walker Lynch, "Numerical Analysis of Computer Approximations," September 2018. DOI: 10.13140/RG.2.2.10906.49601. License CC BY 4.0. https://www.researchgate.net/publication/329402329_Numerical_Analysis_of_Computer_Approximations</RT·endnote>.
+ </p>
- <p>None of these computation systems, that of Boehm and Cartwright, Mathematica, nor my error analysis approach, makes use of the IEEE 754 standard floating-point arithmetic. Rather they all require the use of variable precision. In the case of Boehm and Cartwright's this occurs through the serialization implied through lazy calls for more precision. In the case of Mathematica it is explicit in the significance arithmetic. In my error analysis approach, the means for variable precision was the High Radix Online Arithmetic <RT·endnote>Thomas W. Lynch, "High Radix On Line Arithmetic for Credible and Accurate Computing," Real Numbers and Computers, École des Mines de Saint Étienne, France, 1995, pp. 78 89.</RT·endnote> <RT·endnote>Thomas W. Lynch and Michael J. Schulte, "Software for High Radix On Line Arithmetic," Reliable Computing, vol. 2, no. 2, 1996, pp. 133 138. DOI: 10.1007/BF02425915.</RT·endnote>.
- </p>
+
<p>None of these computation systems, that of Boehm and Cartwright, Mathematica, nor my error analysis approach, makes use of the IEEE 754 standard floating-point arithmetic. Rather they all require the use of variable precision. In the case of Boehm and Cartwright's this occurs through the serialization implied through lazy calls for more precision. In the case of Mathematica it is explicit in the significance arithmetic. In my error analysis approach, the means for variable precision was the High Radix Online Arithmetic <RT·endnote>Thomas W. Lynch, "High Radix On Line Arithmetic for Credible and Accurate Computing," Real Numbers and Computers, École des Mines de Saint Étienne, France, 1995, pp. 78 89.</RT·endnote> <RT·endnote>Thomas W. Lynch and Michael J. Schulte, "Software for High Radix On Line Arithmetic," Reliable Computing, vol. 2, no. 2, 1996, pp. 133 138. DOI: 10.1007/BF02425915.</RT·endnote>.
+ </p>
- <p>Hence what would be useful for a replacement of the IEEE 754, would be a variable precision number standard. There is one being proposed by John Gustafson called the Posit number representation <RT·endnote>John L. Gustafson, <em>The End of Error: Unum Computing</em>, Chapman and Hall/CRC, 2015. Posits serve as a hardware friendly alternative to IEEE 754 floating-point numbers, providing variable precision mechanics.</RT·endnote>.
- </p>
+
<p>Hence what would be useful for a replacement of the IEEE 754, would be a variable precision number standard. There is one being proposed by John Gustafson called the Posit number representation <RT·endnote>John L. Gustafson, <em>The End of Error: Unum Computing</em>, Chapman and Hall/CRC, 2015. Posits serve as a hardware friendly alternative to IEEE 754 floating-point numbers, providing variable precision mechanics.</RT·endnote>.
+ </p>
- <p>This section reviewed finite difference methods as a means to implement function extensions. A person should notice that finite differences are one among many methods for extending functions, and they are not always the best choice. In modern computing it is not common to implement function extensions. Rather it is more common to increment a value across a domain, while completely repeating the evaluation for each new domain value, for example when computing values to place on a plot. However, independent of their importance in applied computing, function extension and difference methods are of theoretical importance for analysis, particularly when applied to nonstandard analysis. These concepts speak directly to the thesis of computational naturalism—deriving mathematics from computational logic—rather than merely proposing practical methods for implementing software.
- </p>
+
<p>This section reviewed finite difference methods as a means to implement function extensions. A person should notice that finite differences are one among many methods for extending functions, and they are not always the best choice. In modern computing it is not common to implement function extensions. Rather it is more common to increment a value across a domain, while completely repeating the evaluation for each new domain value, for example when computing values to place on a plot. However, independent of their importance in applied computing, function extension and difference methods are of theoretical importance for analysis, particularly when applied to nonstandard analysis. These concepts speak directly to the thesis of computational naturalism—deriving mathematics from computational logic—rather than merely proposing practical methods for implementing software.
+ </p>
-<!-- rest of book goes here --->
+ <!-- rest of book goes here --->
</RT·section>
</RT·section>
- <!--------------------------------------------------------------------------------->
+ <!--------------------------------------------------------------------------------->
<RT·section>
<RT·name>Appendix: The Tension Between Formal Methods and Practical Architecture</RT·name>
<RT·section>
<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. 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>
+ 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 -->
+ <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>
- <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.
- </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.
+ </p>
- <p>
- The primary data structure of Lisp is the list, and its programs are designed fundamentally around list traversal. In this sense, the language closely mirrors the pure formal execution of a Turing Machine. Throughout the 1980s, companies such as Symbolics, Lisp Machines Incorporated, Texas Instruments, and Xerox produced computers based on architectures designed specifically to run Lisp natively. However, when Sun Microsystems introduced their workstations, the industry discovered these general-purpose machines were relatively inexpensive and offered higher performance for the exact same Lisp programs. The commercial mandate to execute programs quickly decisively defeated formal architectural purity.
- </p>
+ The primary data structure of Lisp is the list, and its programs are designed fundamentally around list traversal. In this sense, the language closely mirrors the pure formal execution of a Turing Machine. Throughout the 1980s, companies such as Symbolics, Lisp Machines Incorporated, Texas Instruments, and Xerox produced computers based on architectures designed specifically to run Lisp natively. However, when Sun Microsystems introduced their workstations, the industry discovered these general-purpose machines were relatively inexpensive and offered higher performance for the exact same Lisp programs. The commercial mandate to execute programs quickly decisively defeated formal architectural purity.
+ </p>
- <p>
- A counterexample to this trend occurred during the 1980s when two competing floating-point standards emerged. The proposal from DEC allowed for optimally fast computation provided the behavior was well documented. Under this model, the bottom few bits of a computation could be imprecise, and following an interrupt, a program would be required to do diagnostic work to determine the specific instruction that caused the fault. The reasoning was that floating-point computation is approximate by its very nature, and because end-case interrupts occur infrequently, it makes no sense to sacrifice performance on workhorse computations to accelerate rare anomalies.
- </p>
+ A counterexample to this trend occurred during the 1980s when two competing floating-point standards emerged. The proposal from DEC allowed for optimally fast computation provided the behavior was well documented. Under this model, the bottom few bits of a computation could be imprecise, and following an interrupt, a program would be required to do diagnostic work to determine the specific instruction that caused the fault. The reasoning was that floating-point computation is approximate by its very nature, and because end-case interrupts occur infrequently, it makes no sense to sacrifice performance on workhorse computations to accelerate rare anomalies.
+ </p>
- <p>
- The competing standard, initially backed by Intel and soon adopted as the IEEE standard, demanded accuracy to the last bit for each operation, alongside synchronized interrupts. This predictable structure permitted a program to overflow, promote the value, and seamlessly continue an operation. It also specified the use of error tags that participate in a higher-order error algebra. This standard ultimately prevailed because its precision guarantees and deterministic predictability provided the necessary foundation for the formal analysis of programs.
- </p>
+ The competing standard, initially backed by Intel and soon adopted as the IEEE standard, demanded accuracy to the last bit for each operation, alongside synchronized interrupts. This predictable structure permitted a program to overflow, promote the value, and seamlessly continue an operation. It also specified the use of error tags that participate in a higher-order error algebra. This standard ultimately prevailed because its precision guarantees and deterministic predictability provided the necessary foundation for the formal analysis of programs.
+ </p>
- <p>
- This continuous tension between pure formal models and practical execution speed remains a defining characteristic of the field, driving the structural logic behind modern mechanisms dealing with instruction pipelines, branch prediction, and memory aliasing.
- </p>
+ This continuous tension between pure formal models and practical execution speed remains a defining characteristic of the field, driving the structural logic behind modern mechanisms dealing with instruction pipelines, branch prediction, and memory aliasing.
+ </p>
</RT·section>
</RT·section>
<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>
+ 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 begin by defining the tape cell as a location in a physical memory, which provides us with arrays of charge configurations.
- </p>
+ We begin by defining the tape cell as a location in a physical memory, which provides us with arrays of charge configurations.
+ </p>
- <p>
- 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>
+ 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>
- Logic is then defined on top of relay switch logic, as Shannon and others have already done. A machine that requires all inputs to be the '1' symbol to produce a '1' symbol output is a conjunction machine, and so forth.
- </p>
+ Logic is then defined on top of relay switch logic, as Shannon and others have already done. A machine that requires all inputs to be the '1' symbol to produce a '1' symbol output is a conjunction machine, and so forth.
+ </p>
- <p>
- On top of this we can define the Peano Machine, a counter, and then use that machine as the definition of Natural Numbers.
- </p>
+ On top of this we can define the Peano Machine, a counter, and then use that machine as the definition of Peano Numbers.
+ </p>
- <p>
- Where Gödel reduced logic to Natural Numbers, we go the other direction to expand upon logic from Natural Numbers.
- </p>
+ Where Gödel reduced logic to Peano Numbers, we go the other direction to expand upon logic from Peano Numbers.
+ </p>
- <p>
- An axiomatic proof is then a decider that is built up from subroutine calls to the axioms. We might then quantify over all possible compositions of our subroutines in analysis and ask if it is possible that a contradiction decider would return Y or N.
- </p>
+ An axiomatic proof is then a decider that is built up from subroutine calls to the axioms. We might then quantify over all possible compositions of our subroutines in analysis and ask if it is possible that a contradiction decider would return Y or N.
+ </p>
- <p>
- Frege's set theory is then the analysis of a logic program against an enumeration of inputs to choose if a proposed symbol is in a set. Perhaps executing such a program is left to first-order analysis, or perhaps execution is not practical, and evaluation is left to second-order analysis.
- </p>
+ Frege's set theory is then the analysis of a logic program against an enumeration of inputs to choose if a proposed symbol is in a set. Perhaps executing such a program is left to first-order analysis, or perhaps execution is not practical, and evaluation is left to second-order analysis.
+ </p>
- <p>
- Russell's Paradox will then be expressed as a Turing Machine that can be analyzed in the second-order, but cannot be analyzed in the first-order. That is, the paradox exists merely in the first-order as it will never halt when run. However, it is not a paradox in the second-order. It is, of course, through second-order analysis that we are able to describe why Russell's Set description does not resolve in the first-order.
- </p>
+ Russell's Paradox will then be expressed as a Turing Machine that can be analyzed in the second-order, but cannot be analyzed in the first-order. That is, the paradox exists merely in the first-order as it will never halt when run. However, it is not a paradox in the second-order. It is, of course, through second-order analysis that we are able to describe why Russell's Set description does not resolve in the first-order.
+ </p>
- <p>
- With the language of Computational Naturalism it is possible to restate every statement ever made by any mathematician; we might say that the mere fact that a mathematician was able to state something qualifies its membership into Zermelo's S set.
- </p>
+ With the language of Computational Naturalism it is possible to restate every statement ever made by any mathematician; we might say that the mere fact that a mathematician was able to state something qualifies its membership into Zermelo's S set.
+ </p>
- <p>
- Given our knowledge that a universal halting problem analyzer that decides if a Turing Machine program halts does not exist, it is desirable to have rules that guide our writing only Turing Machine programs that are known to halt. This can be done through construction, as proposed by Russell, or through axioms of separation, mapping, and choice, as proposed by Zermelo and others. But then we know from the completeness and correctness theorems, that when such guiding rules are applied, there will exist Turing Machine programs that do halt, but whose definition cannot be constructed, nor surmised using the said axioms.
- </p>
+ Given our knowledge that a universal halting problem analyzer that decides if a Turing Machine program halts does not exist, it is desirable to have rules that guide our writing only Turing Machine programs that are known to halt. This can be done through construction, as proposed by Russell, or through axioms of separation, mapping, and choice, as proposed by Zermelo and others. But then we know from the completeness and correctness theorems, that when such guiding rules are applied, there will exist Turing Machine programs that do halt, but whose definition cannot be constructed, nor surmised using the said axioms.
+ </p>
- <p>
- This brings us back to the reference from the Zermelo discussion in the introduction. Specifically, the question posed is if our finding through second-order analysis that Russell's paradoxical set formulation will not run in the first-order and define a set, does this mean that we are merely using S to state that we are tossing out sets that cannot be defined? The answer is it is not quite this simple. Had Frege said, 'we merely dismiss such sets', we would not have the formalization for the second-order analysis. Throwing out Russell's paradox simply because we ran it and it never halted is not a practical approach. Instead, we omit it specifically from S because analyzing R reveals that it fails to define a first-order halting machine, and S, by definition, only holds first-order halting machines. Zermelo's language is precise and formal. However, it is this bothersome nuance, now articulated here, which caused us to scratch our heads when reading Zermelo the first time.
- </p>
+ This brings us back to the reference from the Zermelo discussion in the introduction. Specifically, the question posed is if our finding through second-order analysis that Russell's paradoxical set formulation will not run in the first-order and define a set, does this mean that we are merely using S to state that we are tossing out sets that cannot be defined? The answer is it is not quite this simple. Had Frege said, 'we merely dismiss such sets', we would not have the formalization for the second-order analysis. Throwing out Russell's paradox simply because we ran it and it never halted is not a practical approach. Instead, we omit it specifically from S because analyzing R reveals that it fails to define a first-order halting machine, and S, by definition, only holds first-order halting machines. Zermelo's language is precise and formal. However, it is this bothersome nuance, now articulated here, which caused us to scratch our heads when reading Zermelo the first time.
+ </p>
- <p>
- Russell's set formulation, R, can be analyzed to determine that it would not halt if it were run. We still keep it as a second-order object, and have even given it a name, R. However, this begs the question, are there machines that cannot even be analyzed in the second-order to ascertain if they would return a result in first-order analysis, i.e., when they are run? If Gödel has a say here, a person would wager that such machines exist. But then, is there an option for analysis in the third-order? Is Turing's halting proof a third-order analysis as it reasons about running the second-order analyzer? Or is it merely a recursive application of second-order analysis?
- </p>
+ Russell's set formulation, R, can be analyzed to determine that it would not halt if it were run. We still keep it as a second-order object, and have even given it a name, R. However, this begs the question, are there machines that cannot even be analyzed in the second-order to ascertain if they would return a result in first-order analysis, i.e., when they are run? If Gödel has a say here, a person would wager that such machines exist. But then, is there an option for analysis in the third-order? Is Turing's halting proof a third-order analysis as it reasons about running the second-order analyzer? Or is it merely a recursive application of second-order analysis?
+ </p>
</RT·section>
<RT·section id="Section·appendix_Stirling-numbers">
<RT·name>Appendix: Stirling Numbers</RT·name>
- <p>
- James Stirling introduced these numbers in his 1730 publication, <em>Methodus Differentialis</em>, a text that directly expanded upon the foundational work laid by Newton.
- </p>
+ James Stirling introduced these numbers in his 1730 publication, <em>Methodus Differentialis</em>, a text that directly expanded upon the foundational work laid by Newton.
+ </p>
- <p>
- The profound utility of Stirling numbers lies in their function as the definitive translation layer between continuous mathematics and discrete mathematics. In the context of the Turing Machine architecture, they are the exact mechanisms that bridge the continuous abstract polynomial with the discrete mechanical steps of the machine.
- </p>
+ The profound utility of Stirling numbers lies in their function as the definitive translation layer between continuous mathematics and discrete mathematics. In the context of the Turing Machine architecture, they are the exact mechanisms that bridge the continuous abstract polynomial with the discrete mechanical steps of the machine.
+ </p>
- <p>
- To understand their mechanical role, a person must look at the mathematical basis used in each domain.
- </p>
+ To understand their mechanical role, a person must look at the mathematical basis used in each domain.
+ </p>
<RT·section>
<RT·name>The Continuous vs. Discrete Basis</RT·name>
- <p>
- In continuous calculus, the natural basis for polynomials is standard exponentiation, <RT·math>t^n</RT·math>. The continuous derivative operator, <RT·math>D</RT·math>, interacts beautifully with this basis, dropping the degree by exactly one: <RT·math>D(t^n) = n t^{n - 1}</RT·math>.
- </p>
+ In continuous calculus, the natural basis for polynomials is standard exponentiation, <RT·math>t^n</RT·math>. The continuous derivative operator, <RT·math>D</RT·math>, interacts beautifully with this basis, dropping the degree by exactly one: <RT·math>D(t^n) = n t^{n - 1}</RT·math>.
+ </p>
- <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>
+ 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·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>
+ <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>.
- </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>.
+ </p>
</RT·section>
<RT·section>
<RT·name>Stirling Numbers of the Second Kind, <RT·math>S(n, k)</RT·math></RT·name>
- <p>
- The Stirling numbers of the second kind are the coefficients required to project the continuous basis onto the discrete basis. They express standard powers as a sum of falling factorials:
- </p>
+ The Stirling numbers of the second kind are the coefficients required to project the continuous basis onto the discrete basis. They express standard powers as a sum of falling factorials:
+ </p>
- <p>
- <RT·math>t^n = \sum_{k=0}^n S(n,k) t^{\underline{k}}</RT·math>
- </p>
+ <RT·math>t^n = \sum_{k=0}^n S(n,k) t^{\underline{k}}</RT·math>
+ </p>
- <p>
- In combinatorics, <RT·math>S(n,k)</RT·math> represents the number of distinct ways to partition a set of <RT·math>n</RT·math> items into <RT·math>k</RT·math> non empty subsets.
- </p>
+ In combinatorics, <RT·math>S(n,k)</RT·math> represents the number of distinct ways to partition a set of <RT·math>n</RT·math> items into <RT·math>k</RT·math> non empty subsets.
+ </p>
- <p>
- In the Turing Machine architecture, the polynomial coefficients <RT·math>a_i</RT·math> represent the abstract continuous function. The initial tape components <RT·math>D_{0, k}</RT·math> represent the discrete physical realization of that function. Because the Turing Machine operates in discrete Integer steps, mapping the abstract polynomial onto the physical tape forces the conversion from standard powers to falling factorials. This is why <RT·math>S(n,k)</RT·math> governs the upper triangular matrix in the preceding lemma.
- </p>
+ In the Turing Machine architecture, the polynomial coefficients <RT·math>a_i</RT·math> represent the abstract continuous function. The initial tape components <RT·math>D_{0, k}</RT·math> represent the discrete physical realization of that function. Because the Turing Machine operates in discrete Integer steps, mapping the abstract polynomial onto the physical tape forces the conversion from standard powers to falling factorials. This is why <RT·math>S(n,k)</RT·math> governs the upper triangular matrix in the preceding lemma.
+ </p>
</RT·section>
<RT·section>
<RT·name>Stirling Numbers of the First Kind, <RT·math>s(n, k)</RT·math></RT·name>
- <p>
- The signed Stirling numbers of the first kind perform the exact inverse operation. They reconstruct standard continuous powers from falling factorials:
- </p>
-
- <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.
- </p>
-
- <p>
- In the context of the quotient machine or the coefficient recovery matrix, taking the inverse of the matrix formed by the second kind inherently generates a matrix composed of the first kind. This provides the direct algorithmic path to extract the continuous polynomial identity from the discrete mechanical state of the tape.
- </p>
-
- <p>
- They essentially prove that no information is lost when moving a polynomial from the abstract realm into the physical constraints of a stepping machine.
- </p>
+ The signed Stirling numbers of the first kind perform the exact inverse operation. They reconstruct standard continuous powers from falling factorials:
+ </p>
+
+ <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>
+
+ 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.
+ </p>
+
+ In the context of the quotient machine or the coefficient recovery matrix, taking the inverse of the matrix formed by the second kind inherently generates a matrix composed of the first kind. This provides the direct algorithmic path to extract the continuous polynomial identity from the discrete mechanical state of the tape.
+ </p>
+
+ They essentially prove that no information is lost when moving a polynomial from the abstract realm into the physical constraints of a stepping machine.
+ </p>
</RT·section>
</RT·section>
- <RT·endnotes></RT·endnotes>
+ <RT·endnotes></RT·endnotes>
</RT·article>
</body>
<!-- LocalWords: Hopcroft Ullman endnote unformatted dereference
LocalWords: computable cardinality uniquifier namespace
- -->
+ -->
projects / TM-2026 / commitdiff