Carried into this volume and already placed:
- Unsigned integer representation, TTCA 204, now chapter 20, Peano Number.
+ Unsigned integer representation, TTCA 204, now chapter 20, Counting Number.
Orders of analysis, TTCA 19, now section 9.1.
Addresses and cells, TTCA 21, now chapters 18 and 19.
Conventional Turing Machine variations, TTCA 37, now chapter 10.
<RT·article>
- <RT·Counter·make counter="RT·Figure·counter" style="CountingNumber" mode="scoped"></RT·Counter·make>
- <RT·Counter·make counter="RT·Table·counter" style="CountingNumber" mode="scoped"></RT·Counter·make>
- <RT·Counter·make counter="RT·List·counter" style="CountingNumber" mode="scoped"></RT·Counter·make>
- <RT·Counter·make counter="RT·Equation·counter" style="CountingNumber" mode="scoped"></RT·Counter·make>
- <RT·Counter·make counter="RT·Code·counter" style="CountingNumber" mode="scoped"></RT·Counter·make>
-
- <RT·title
- title="Computational Naturalism"
- author="Thomas Long"
- date="2026-06-01 08:28:00Z"
- copyright="2026 Reasoning Technology">
- </RT·title>
-
+ <RT·page no-number>
+ <RT·title
+ title="Computational Naturalism"
+ author="Thomas Long"
+ date="2026-06-01 08:28:00Z"
+ copyright="2026 Reasoning Technology">
+ </RT·title>
+ </RT·page>
<RT·TOC level="1-2"></RT·TOC>
+ <RT·Counter·make counter="Figure" style="CountingNumber" mode="scoped"></RT·Counter·make>
+ <RT·Counter·make counter="Table" style="CountingNumber" mode="scoped"></RT·Counter·make>
+ <RT·Counter·make counter="List" style="CountingNumber" mode="scoped"></RT·Counter·make>
+ <RT·Counter·make counter="Equation" style="CountingNumber" mode="scoped"></RT·Counter·make>
+ <RT·Counter·make counter="Code" style="CountingNumber" mode="scoped"></RT·Counter·make>
+
<!--------------------------------------------------------------------------------->
- <RT·section id="Section·Exordium">
+ <RT·section counter="Front Matter,Front Matter Section" id="Section·Exordium">
<RT·name>Exordium</RT·name>
<p>My well funded colleagues have been working tirelessly to confirm Schopenhauer’s thesis, which they were in an excellent position to do, leaving me with a fulfilling career making people happy by cleaning fish and stocking shelves. Still I have managed to do some writing.</p>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section id="Section·Preface">
+ <RT·section counter="Front Matter,Front Matter Section" id="Section·Preface">
<RT·name>Preface</RT·name>
<p>The IEEE Std 754 floating-point standard equips the numerical analyst with the tools to design platform independent algorithms with predictable numerical behavior. Though the principal founder of the standard did commit one sin. He allowed for the expanded precision of the intermediate calculations on the Intel 8087 as a matter of backwards compatibility. He apparently succumbed to that final temptation because he had been part of that project. Consequently, the standard does not provide universal platform independence.</p>
</RT·section>
<!--------------------------------------------------------------------------------->
- <RT·section id="Section·Conventio">
+ <RT·section counter="Front Matter,Front Matter Section" id="Section·Conventio">
<RT·name>Conventio</RT·name>
<p>All communication starts from the knowledge held in common between the author and reader. This chapter is a first meeting and a search for that commonality.</p>
<p>Code blocks and spans follow the RT code format conventions, which resemble the math conventions above but are not identical to them.<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, unlike for math scopes, comma-separated lists apply a space before the comma and bind the punctuation directly to the item being appended to the list:</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·Counter·step counter="Code" id="Code·comma-list_example">
+ <RT·name>A horizontal comma-separated list</RT·name>
+ <RT·Counter·snapshot counter="Code" 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·read snapshot="Code·comma-list_example" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Multi-level enclosures receive a single space of padding only on the outermost boundary:</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·Counter·step counter="Code" id="Code·enclosure-padding_example">
+ <RT·name>Padding applied to the outermost enclosure only</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·enclosure-padding_example"></RT·Counter·snapshot>
<RT·code>
if( f(g(x)) ){
do_something();
}
</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·read snapshot="Code·enclosure-padding_example" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Code identifiers follow a parallel convention, though what counts as a container differs from the mathematical case. In code, a container is a namespace, a module, or a type, i.e. something that holds definitions, and these are written in PascalCase. Every other identifier is snake-kebab_case, and that includes the data structures that hold elements rather than definitions, so a list or a dictionary carries a lower case name. Both separators are in use so that a hyphen binds tighter than an underscore, which establishes semantic precedence. An example of this is:</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·Counter·step counter="Code" id="Code·identifier-separator_example">
+ <RT·name>A hyphen binding tighter than an underscore within an identifier</RT·name>
+ <RT·Counter·snapshot counter="Code" 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·read snapshot="Code·identifier-separator_example" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Throughout, this text uses native Unicode characters rather than escape sequences. Where a mathematical or Greek symbol is wanted, the character itself appears, so the text carries ‘δ’ rather than <RT·code>\delta</RT·code>. This might lead to some small typesetting variations compared to what MathJax might otherwise have output.</p>
<RT·section id="Section·Conventio·Number_types">
<RT·name>Number types</RT·name>
- <p>Several words in this book carry a formal definition that displaces their ordinary English sense, and those are capitalized: <RT·neologism>Peano Number</RT·neologism>, <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 terms for mathematical number types are capitalized, e.g.s <RT·term>Counting 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>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 it is derived through observing a machine.</p>
+
+ <p>Herein the natural numbers are called <RT·term>Counting Number</RT·term>s. A Counting Number is what a Counting Machine outputs, and it begins at one. 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.
+ <RT·endnote>Peano’s original axioms began with one, and modern presentations of Peano arithmetic commonly begin with zero. The difference is a choice about where to start a recursion rather than a discovery about number, which is part of why this book does not take a recursion as the starting point. The historical formulation is shared between Richard Dedekind and Giuseppe Peano: Dedekind described a “simply infinite system” in <em>Was sind und was sollen die Zahlen?</em> (Braunschweig: Vieweg, 1888), while Peano published a corresponding axiomatization in <em>Arithmetices principia, nova methodo exposita</em> (Turin: Bocca, 1889). The axioms are therefore also called the <em>Dedekind−Peano axioms</em>. “Dedekind number” is already the name of a different mathematical sequence, so it is not an alternative name for the objects defined here. Peano did not create arithmetic itself, but his axiomatic presentation and notation gave successor-based arithmetic its familiar formal identity. This book does not adopt the name. The objects defined here are derived from a machine that counts rather than from an axiom set, and the start at one is a fact about that machine rather than a convention adopted for it.</RT·endnote>
+ </p>
+
+ <p>Zero is not reached by counting. Rather it serves as a case for doing nothing. It is the additive identity, so adding it is not necessary. It is the distance from a thing to itself, and thus the departure was never required in the first place. It is the flag that says a container holds nothing, and thus no container is needed. There are philosophical and mathematical implications that must be discussed, and we will discuss them, see emptiness in
+ <RT·Counter·read snapshot="Section·Conventional_Turing_Machine·Memory_of_emptiness" key="counter count"></RT·Counter·read>, the construction of numbers in <RT·Counter·read snapshot="Section·Number·Construction" key="counter count"></RT·Counter·read>, and of course zero in <RT·Counter·read snapshot="Section·Number·Zero" key="counter count"></RT·Counter·read>.</p>
- <p>What mathematics calls the natural numbers are called <RT·neologism>Peano Number</RT·neologism>s in this book. A <RT·neologism>Peano Number</RT·neologism> 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 <RT·neologism>Peano Number</RT·neologism>s 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 original axioms began with the number one. Modern presentations of Peano arithmetic commonly begin with zero, and that is the convention followed here. The historical formulation is shared between Richard Dedekind and Giuseppe Peano: Dedekind described a “simply infinite system” in <em>Was sind und was sollen die Zahlen?</em> (Braunschweig: Vieweg, 1888), while Peano published a corresponding axiomatization in <em>Arithmetices principia, nova methodo exposita</em> (Turin: Bocca, 1889). The axioms are therefore also called the <em>Dedekind−Peano axioms</em>. “Dedekind number” is already the name of a different mathematical sequence, so it is not an alternative name for the objects defined here. Peano did not create arithmetic itself, but his axiomatic presentation and notation gave the successor-based arithmetic its familiar formal identity. This book therefore calls the machine’s outputs <RT·neologism>Peano Number</RT·neologism>s: the Peano Machine is named for the Peano Numbers it produces.</RT·endnote>
- An <RT·term>Integer</RT·term>, a <RT·term>Rational</RT·term>, and a <RT·term>Real</RT·term> are likewise the outputs of machines, each constructed in its turn.</p>
</RT·section>
+
+
<RT·section id="Section·Conventio·Fields_of_study">
<RT·name>Fields of study</RT·name>
- <p>Number Theory consists of the analysis of <RT·neologism>Peano Number</RT·neologism> related structures. It gives properties to these structures, e.g. the familiar ‘odd’ and ‘even’. It gives properties to the relationship between numbers and operations on those numbers, e.g. proving that an odd number squared is odd. It deals with the solution of mixed integer equations, and systems of such equations, and sets the rules for modulus arithmetic. For example, encryption algorithms belong to Number Theory.</p>
+ <p>Number Theory consists of the analysis of structures built from <RT·term>Counting Number</RT·term>s, admitting zero where a structure requires it, as modular arithmetic does for its residues. It gives properties to these structures, e.g. the familiar ‘odd’ and ‘even’. It gives properties to the relationship between numbers and operations on those numbers, e.g. proving that an odd number squared is odd. It deals with the solution of mixed integer equations, and systems of such equations, and sets the rules for modulus arithmetic. Groups, rings, and fields belong to it, and so does the whole of algebraic structure. For example, encryption algorithms belong to Number Theory.</p>
+
+ <p>Number Theory is a proto-Computation Theory. It has always dealt in procedures and in what can be decided about them: Euclid gave an algorithm for the greatest common divisor around 300 BC and argued that it terminates, and questions of primality and divisibility are decision problems in everything but name. The relation is not merely ancestral. Gödel encoded formal systems as numbers and conducted his metamathematics on their factorizations, so Number Theory supplied the medium in which the first such proofs were carried out, and Hilbert asked in 1900 for a procedure deciding Diophantine equations, a question answered seventy years later by showing that no such procedure exists. Church, Turing, and their contemporaries did not open a new subject so much as give a name to what part of an old one had been doing all along.
+ <RT·endnote>Euclid, <em>Elements</em> VII.1−2. 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. Hilbert’s tenth problem was settled by Yuri Matiyasevich in 1970, completing work of Martin Davis, Hilary Putnam, and Julia Robinson.</RT·endnote>
+ </p>
+
+ <p>The boundary between Number Theory and continuous mathematics is not a boundary between subjects. It is a single step, and the step is the limit: the supposition that a series completes at infinity. Everything short of that step remains discrete, however sophisticated. The fundamental theorem of arithmetic factors any Counting Number into primes and takes no limit. The residue number system represents a number by its remainders against a set of coprime moduli and takes no limit. A finite field is finite. What analysis contributes, and the only thing it contributes, is completion at infinity, and a result reached that way has crossed over regardless of what its subject matter was. This book does not take the step, and <RT·Counter·read snapshot="Section·Computational_Analysis" key="counter count"></RT·Counter·read> gives the reason: what is called a continuous function is, on any machine that evaluates it, a finite string of discrete symbols. Those who wish to build the continuum on top of Number Theory are free to do so, exactly as those who run a computer algebra system are free to build on Computation Theory, and neither undertaking changes what it was built on.</p>
+
+ <p>Numerical Analysis is built on two axioms. The first axiom limits computing to vectors of <RT·term>Counting Number</RT·term>s, together with whatever flags the representation needs, zero among them. A vector represents a number; a common representation is a number pair, where one number of the pair scales the other, thus making it possible to represent fractional values. The second axiom states the actual intention of the programmer is to perform computation over a Real field. As Real Numbers fall on a continuum, it follows that some Real Numbers cannot be represented with a vector of <RT·term>Counting Number</RT·term>s. The objective of Numerical Analysis is then to establish the relationship between <RT·term>Counting Number</RT·term> results and the corresponding exact Real Number results. The difference between the two is called <RT·term>error</RT·term>. People who work in numerical algorithm design often spend a great deal of time trying to keep some metric of error low over a given domain.</p>
+
+ <p>Computation Theory consists of proofs over what can, and cannot be computed, the time and space complexity of algorithms, and the fundamental structure of computation.</p>
+
+ <p>Metamathematics takes mathematics itself as the object of study rather than as the instrument. Its subject matter is formal systems, proofs, and derivations, treated as things to be reasoned about, and its questions are what a given system can prove, what it cannot, and what it can prove about itself. The distinction matters here because this book studies a machine and then finds that the language for recording those observations has itself become an object of study. That second study is a metamathematics, and it arrives out of the apparatus rather than being imposed upon it.</p>
- <p>Numerical Analysis is built on two axioms. The first axiom limits computing to vectors of <RT·neologism>Peano Number</RT·neologism>s, where a vector represents a number. A common representation is a number pair, where one number of the pair scales the other number, thus making it possible to represent fractional values. The second axiom states the actual intention of the programmer is to perform computation over a Real field. As Real Numbers fall on a continuum, it follows that some Real Numbers can not be represented with a vector of <RT·neologism>Peano Number</RT·neologism>s. The objective of Numerical Analysis is then to establish the relationship between <RT·neologism>Peano Number</RT·neologism> results with the corresponding exact Real Number results. The difference between the two is called <RT·term>error</RT·term>. People who work in numerical algorithm design often spend a great deal of time trying to keep some metric of error low over a given domain.</p>
+ <p>Computer Architecture is the design discipline concerned with the structure of a machine: what its parts are, what each is responsible for, and how the boundaries between them are drawn. It is distinct from the engineering of any particular part, and its characteristic question is where a boundary should fall rather than how a component should be built. The levels treated in <RT·Counter·read snapshot="Section·Design_stack" key="counter count"></RT·Counter·read> are its subject matter.</p>
+
+ <p>Communication Theory studies the conveyance of a message from a sender to a receiver over a channel, and in particular what must be agreed in advance for the message to be recoverable at the far end. This book borrows from it because a tape written by one machine and read by another is a channel, and the questions that arise there — how the receiver is to know where the message ends, and how control is to be told apart from data — are ones communication engineers have already had to answer.</p>
- <p>Computation Theory consists of proofs over what can, and cannot be computed, the time and space complexity of algorithms, and the fundamental structure of computation. Number Theory is a kind of Computation Theory applied to Peano Structures before Church, Turing, and their contemporaries gave computation theory its name.</p>
</RT·section>
<RT·section id="Section·Conventio·Symbol">
<p>Because a function annotates what goes in and out of an inner scope, any evaluation context, or set of evaluation contexts, can be interpreted as being a function.</p>
- <p>The term <RT·term>constant</RT·term> is a property ascribed to an object when a primary aspect of that object under discussion does not change across evaluation contexts. Different primary aspects are conventionally considered. Of a fixed symbol, the aspect is its binding as an object. Of a function, it is the return value, which for a constant function is the same for every evaluation. Of a primitive math object such as an individual <RT·neologism>Peano Number</RT·neologism>, it is the object itself. This latter usage would mean that the term <em>constant</em> is the same as a <em>math object</em>, and thus the same as <em>value</em>.</p>
+ <p>The term <RT·term>constant</RT·term> is a property ascribed to an object when a primary aspect of that object under discussion does not change across evaluation contexts. Different primary aspects are conventionally considered. Of a fixed symbol, the aspect is its binding as an object. Of a function, it is the return value, which for a constant function is the same for every evaluation. Of a primitive math object such as an individual <RT·neologism>Counting Number</RT·neologism>, it is the object itself. This latter usage would mean that the term <em>constant</em> is the same as a <em>math object</em>, and thus the same as <em>value</em>.</p>
</RT·section>
<p>The <RT·term>connective</RT·term>s are symbols, and instances of their representations are these: <RT·math>∧</RT·math> (and), <RT·math>∨</RT·math> (or), <RT·math>¬</RT·math> (not), <RT·math>→</RT·math> (implies), and <RT·math>↔</RT·math> (if and only if). Alongside them stand the parentheses, <RT·math>(</RT·math> and <RT·math>)</RT·math>, which group. Each connective is fixed, in that what it does is settled once for the whole calculus and nothing later on is at liberty to change it. What each one does is combine truth values to give a truth value, so <RT·math>∧</RT·math> gives true exactly when both of the truth values given to it are true, <RT·math>¬</RT·math> gives the truth value it was not given, and so on for the rest.</p>
- <p>Beside the connectives stand the <RT·term>proposition symbol</RT·term>s, whose representations are commonly <RT·math>p</RT·math>, <RT·math>q</RT·math>, and <RT·math>r</RT·math>. These are variables. A proposition symbol has no meaning of its own, and marks a place where a proposition is later bound to it. It is the only kind of symbol in this calculus that is not fixed.<RT·endnote>The letters follow the notation convention of section <RT·Counter·read snapshot="Section·Conventio·Notation"></RT·Counter·read>, applied to whatever the symbol marks a place for. A proposition is not a container, so the letter is lower case. A formula is a string and therefore a container, so the letters standing for formulas below are capitals.</RT·endnote></p>
+ <p>Beside the connectives stand the <RT·term>proposition symbol</RT·term>s, whose representations are commonly <RT·math>p</RT·math>, <RT·math>q</RT·math>, and <RT·math>r</RT·math>. These are variables. A proposition symbol has no meaning of its own, and marks a place where a proposition is later bound to it. It is the only kind of symbol in this calculus that is not fixed.<RT·endnote>The letters follow the notation convention of <RT·Counter·read snapshot="Section·Conventio·Notation" key="counter count"></RT·Counter·read>, applied to whatever the symbol marks a place for. A proposition is not a container, so the letter is lower case. A formula is a string and therefore a container, so the letters standing for formulas below are capitals.</RT·endnote></p>
<p>Symbol instances are strung together according to the <RT·term>formation rules</RT·term>, and what the rules build is called a <RT·term>formula</RT·term>. The rules are three, and the third is what closes the definition. The Greek letters <RT·math>Φ</RT·math> and <RT·math>Ψ</RT·math> stand for whole formulas below, and <RT·math>∘</RT·math> stands for any one of the binary connectives. All three belong to this discussion rather than to the calculus being discussed.</p>
- <RT·Counter·step counter="RT·List·counter" id="List·propositional_formation-rules">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·propositional_formation-rules"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·propositional_formation-rules">
+ <RT·name>Formation rules of the propositional calculus</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·propositional_formation-rules"></RT·Counter·snapshot>
<ol>
<li>A proposition symbol standing alone is a formula. Such a formula is called <RT·term>atomic</RT·term>, meaning no formation rule builds it out of smaller formulas.</li>
<li>If <RT·math>Φ</RT·math> and <RT·math>Ψ</RT·math> are formulas, then <RT·math>¬Φ</RT·math> is a formula, and so is <RT·math>(Φ ∘ Ψ)</RT·math> for each binary connective <RT·math>∘</RT·math>.</li>
<li>Nothing is a formula except by finitely many applications of rules 1 and 2.</li>
</ol>
- List <RT·Counter·read snapshot="List·propositional_formation-rules"></RT·Counter·read>. <RT·name>Formation rules of the propositional calculus</RT·name>
+ <RT·Counter·read snapshot="List·propositional_formation-rules" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>For example, <RT·math>(p ∧ ¬q)</RT·math> is a formula. Rule 1 supplies <RT·math>p</RT·math>, and supplies <RT·math>q</RT·math>. Rule 2 applied to <RT·math>q</RT·math> supplies the negation, <RT·math>¬q</RT·math>. Rule 2 applied again, this time to the pair, supplies <RT·math>(p ∧ ¬q)</RT·math>, and the parentheses arrive with that application rather than by any step of their own, because the rule writes them. Rule 3 then terminates the process by saying nothing more can be added. Every formula arrives through this same method.</p>
<p>A <RT·term>propositional calculus</RT·term> therefore consists of math objects that occur on an abstraction stack, which collects what has been said so far.</p>
- <RT·Counter·step counter="RT·List·counter" id="List·propositional_stack">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·propositional_stack"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·propositional_stack">
+ <RT·name>The propositional logic abstraction stack</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·propositional_stack"></RT·Counter·snapshot>
<ol reversed start="2">
<li>interpretation
<ul>
</ul>
</li>
</ol>
- List <RT·Counter·read snapshot="List·propositional_stack"></RT·Counter·read>. <RT·name>The propositional logic abstraction stack</RT·name>
+ <RT·Counter·read snapshot="List·propositional_stack" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Each level is settled without reference to the one above it. The symbols at level 0 are settled before any formula is written, the formula at level 1 is an arrangement of them and is settled before any interpretation is considered, and the interpretation at level 2 binds values to the variables among them. This is why the same formula serves under every interpretation and the same symbols serve in every formula. A hardware designer would recognize the level 1 formula as a gate network drawn before any signal has been applied to it.</p>
<RT·section id="Section·Conventio·Logic·First-order_predicate_calculus">
<RT·name>First-order predicate calculus</RT·name>
- <p>Now suppose that a proposition could be predicated on something else. A <RT·term>predicate</RT·term> is a logic function. It is given values for its arguments, and it then evaluates to true or to false. Give a predicate its arguments and what results is a proposition, so the predicate is the general case and the proposition is the settled one. <RT·math>\text{prime}(x)</RT·math> is a predicate of one argument, and <RT·math>\text{prime}(7)</RT·math> is true while <RT·math>\text{prime}(8)</RT·math> is false. <RT·math><(x, y)</RT·math> is a predicate of two arguments, which is how a relation is written. Thus <RT·math><(3, 5)</RT·math> is true, while <RT·math><(5, 3)</RT·math> is false. Predicate arguments are drawn from a <RT·term>domain</RT·term>, a set holding at least one member, and that set is whatever mathematics cares to name: the <RT·neologism>Peano Number</RT·neologism>s, the points of a plane, the strings over an alphabet. Nothing requires the arguments to be truth values, and nothing forbids it. What is required is that the result be a truth value.</p>
+ <p>Now suppose that a proposition could be predicated on something else. A <RT·term>predicate</RT·term> is a logic function. It is given values for its arguments, and it then evaluates to true or to false. Give a predicate its arguments and what results is a proposition, so the predicate is the general case and the proposition is the settled one. <RT·math>\text{prime}(x)</RT·math> is a predicate of one argument, and <RT·math>\text{prime}(7)</RT·math> is true while <RT·math>\text{prime}(8)</RT·math> is false. <RT·math><(x, y)</RT·math> is a predicate of two arguments, which is how a relation is written. Thus <RT·math><(3, 5)</RT·math> is true, while <RT·math><(5, 3)</RT·math> is false. Predicate arguments are drawn from a <RT·term>domain</RT·term>, a set holding at least one member, and that set is whatever mathematics cares to name: the <RT·neologism>Counting Number</RT·neologism>s, the points of a plane, the strings over an alphabet. Nothing requires the arguments to be truth values, and nothing forbids it. What is required is that the result be a truth value.</p>
- <p>A <RT·term>property</RT·term> is a predicate of one argument. It is not a new kind of object; it is the one-argument case of the predicate already defined. <RT·math>\text{even}</RT·math> is a property of the <RT·neologism>Peano Number</RT·neologism>s, holding of 4 and failing of 5, and <RT·math>\text{prime}</RT·math> is another. To give a property over a domain is to mark off which members of that domain it holds of, so the properties of a domain stand in exact correspondence with the sub-collections of it, and a domain of <RT·math>n</RT·math> members carries <RT·math>2^n</RT·math> properties.<RT·endnote>This correspondence counts two predicates holding of the same members as the same property, a convention called <em>extensionality</em>. It sets aside the sense in which ‘is an equilateral triangle’ and ‘is an equiangular triangle’ are different properties that happen to hold of the same figures.</RT·endnote> The properties of a domain form a collection of their own, distinct from the domain, so a quantifier ranging over the one is not ranging over the other.</p>
+ <p>A <RT·term>property</RT·term> is a predicate of one argument. It is not a new kind of object; it is the one-argument case of the predicate already defined. <RT·math>\text{even}</RT·math> is a property of the <RT·neologism>Counting Number</RT·neologism>s, holding of 4 and failing of 5, and <RT·math>\text{prime}</RT·math> is another. To give a property over a domain is to mark off which members of that domain it holds of, so the properties of a domain stand in exact correspondence with the sub-collections of it, and a domain of <RT·math>n</RT·math> members carries <RT·math>2^n</RT·math> properties.<RT·endnote>This correspondence counts two predicates holding of the same members as the same property, a convention called <em>extensionality</em>. It sets aside the sense in which ‘is an equilateral triangle’ and ‘is an equiangular triangle’ are different properties that happen to hold of the same figures.</RT·endnote> The properties of a domain form a collection of their own, distinct from the domain, so a quantifier ranging over the one is not ranging over the other.</p>
<p>The <RT·term>first-order predicate calculus</RT·term> also begins with symbols, and its base level holds three groups rather than two. The fixed group gains the <RT·term>quantifier</RT·term>s, <RT·math>∀</RT·math> (for all) and <RT·math>∃</RT·math> (there exists), alongside the connectives and parentheses already in it. The second group holds the variables an interpretation binds, and there are three kinds of them. A <RT·term>predicate symbol</RT·term> is a variable to be bound to a predicate, and it carries a fixed number of argument places, so that the predicate bound to it is one of that many arguments; its representations are commonly <RT·math>F</RT·math>, <RT·math>G</RT·math>, and <RT·math>R</RT·math>. A <RT·term>name</RT·term> is a variable to be bound to one member of the domain; its representations are commonly <RT·math>a</RT·math>, <RT·math>b</RT·math>, and <RT·math>c</RT·math>. A <RT·term>function symbol</RT·term> is a variable to be bound to a function carrying some fixed number of domain members to one domain member, and it carries that many argument places; its representations are commonly <RT·math>f</RT·math>, <RT·math>g</RT·math>, and <RT·math>s</RT·math>.<RT·endnote>The capitals are the traditional letters for predicate symbols, and are kept so that a reader can find the literature.</RT·endnote> The third group is new, and holds the variables a quantifier is able to claim. This calculus has one kind, the <RT·term>domain variable</RT·term>, whose representations are commonly <RT·math>x</RT·math>, <RT·math>y</RT·math>, and <RT·math>z</RT·math>. The proposition symbol is gone, having no work left to do: a predicate symbol given its arguments occupies the place where a proposition once stood.</p>
- <p>A function applied to domain members yields another domain member, so the expressions that mark out a member of the domain have to be settled before the formulas can be. A <RT·term>term</RT·term> is a domain variable, or a name, or a function symbol of <RT·math>n</RT·math> places applied to <RT·math>n</RT·math> terms, and nothing else is a term. A term marks out a member of the domain and carries no truth value of its own. So <RT·math>x</RT·math>, <RT·math>a</RT·math>, and <RT·math>f(s(a), x)</RT·math> are terms.<RT·endnote>The word is used elsewhere in this book in its ordinary sense, for one of the parts of a compound expression, as when the two conjuncts of a set-defining condition are called its terms in chapter <RT·Counter·read snapshot="Section·Search_for_Turing_Machine"></RT·Counter·read>. Where the calculus is under discussion, the definition given here is the one intended.</RT·endnote></p>
+ <p>A function applied to domain members yields another domain member, so the expressions that mark out a member of the domain have to be settled before the formulas can be. A <RT·term>term</RT·term> is a domain variable, or a name, or a function symbol of <RT·math>n</RT·math> places applied to <RT·math>n</RT·math> terms, and nothing else is a term. A term marks out a member of the domain and carries no truth value of its own. So <RT·math>x</RT·math>, <RT·math>a</RT·math>, and <RT·math>f(s(a), x)</RT·math> are terms.<RT·endnote>The word is used elsewhere in this book in its ordinary sense, for one of the parts of a compound expression, as when the two conjuncts of a set-defining condition are called its terms in <RT·Counter·read snapshot="Section·Search_for_Turing_Machine" key="counter count"></RT·Counter·read>. Where the calculus is under discussion, the definition given here is the one intended.</RT·endnote></p>
- <RT·Counter·step counter="RT·List·counter" id="List·first-order_formation-rules">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·first-order_formation-rules"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·first-order_formation-rules">
+ <RT·name>Formation rules of the first-order predicate calculus</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·first-order_formation-rules"></RT·Counter·snapshot>
<ol>
<li>A predicate symbol of <RT·math>n</RT·math> places applied to <RT·math>n</RT·math> terms is a formula, and it is atomic.</li>
<li>If <RT·math>Φ</RT·math> and <RT·math>Ψ</RT·math> are formulas, then <RT·math>¬Φ</RT·math> is a formula, and so is <RT·math>(Φ ∘ Ψ)</RT·math> for each binary connective <RT·math>∘</RT·math>.</li>
<li>If <RT·math>Φ</RT·math> is a formula and <RT·math>x</RT·math> is a domain variable, then <RT·math>∀x \, Φ</RT·math> and <RT·math>∃x \, Φ</RT·math> are formulas.</li>
<li>No expression is a formula except by finitely many applications of rules 1 through 3.</li>
</ol>
- List <RT·Counter·read snapshot="List·first-order_formation-rules"></RT·Counter·read>. <RT·name>Formation rules of the first-order predicate calculus</RT·name>
+ <RT·Counter·read snapshot="List·first-order_formation-rules" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>So <RT·math>∀x \, F(x)</RT·math> and <RT·math>∀x ∃y \, R(x, y)</RT·math> are formulas of the calculus.</p>
<p>A formula in which no variable appears free, also called a <RT·term-em>sentence</RT·term-em>, makes an outright claim once its predicate symbols, names, and function symbols are bound. A formula with a free appearance holds or fails according to what is bound to that appearance, so its truth value varies where the other’s does not. So <RT·math>∀x ∃y \, R(x, y)</RT·math> is one and <RT·math>∃y \, R(x, y)</RT·math> is not. The distinction has no work to do in the propositional calculus, which holds no quantifier and so no free appearances.</p>
- <p>An interpretation of a first-order formula supplies a domain, which holds at least one member.<RT·endnote>Standard first-order logic does not admit the empty domain, and the reason is visible in the formulas. Over an empty domain <RT·math>∀x \, F(x)</RT·math> would hold and <RT·math>∃x \, F(x)</RT·math> would fail, so <RT·math>(∀x \, F(x) → ∃x \, F(x))</RT·math> would not be valid; it is counted a validity of this calculus, and admitting the empty domain would cost that.</RT·endnote> It then binds, to each variable of the formula, a value of the kind that variable marks a place for: a predicate over the domain to each predicate symbol, of the matching number of arguments; a member of the domain to each name; a function over the domain to each function symbol; and a member of the domain to each free appearance of a domain variable, passing over the bound appearances, which the quantifier has already claimed.<RT·endnote>The notation is not settled across the sources surveyed in this book. Hilbert and Ackermann write <RT·math>(x)</RT·math> for the universal quantifier and <RT·math>(Ex)</RT·math> for the existential, and they mark negation with an overbar rather than with <RT·math>¬</RT·math>. A reader going to their book should be prepared for this.</RT·endnote> Take the <RT·neologism>Peano Number</RT·neologism>s as the domain and bind <RT·math><</RT·math> to <RT·math>R</RT·math>: the formula <RT·math>∀x ∃y \, R(x, y)</RT·math> then states that every <RT·neologism>Peano Number</RT·neologism> has a larger one, and under that interpretation it holds. Every appearance in it is claimed by a quantifier, so the only things the interpretation had to give were the domain and the predicate.</p>
+ <p>An interpretation of a first-order formula supplies a domain, which holds at least one member.<RT·endnote>Standard first-order logic does not admit the empty domain, and the reason is visible in the formulas. Over an empty domain <RT·math>∀x \, F(x)</RT·math> would hold and <RT·math>∃x \, F(x)</RT·math> would fail, so <RT·math>(∀x \, F(x) → ∃x \, F(x))</RT·math> would not be valid; it is counted a validity of this calculus, and admitting the empty domain would cost that.</RT·endnote> It then binds, to each variable of the formula, a value of the kind that variable marks a place for: a predicate over the domain to each predicate symbol, of the matching number of arguments; a member of the domain to each name; a function over the domain to each function symbol; and a member of the domain to each free appearance of a domain variable, passing over the bound appearances, which the quantifier has already claimed.<RT·endnote>The notation is not settled across the sources surveyed in this book. Hilbert and Ackermann write <RT·math>(x)</RT·math> for the universal quantifier and <RT·math>(Ex)</RT·math> for the existential, and they mark negation with an overbar rather than with <RT·math>¬</RT·math>. A reader going to their book should be prepared for this.</RT·endnote> Take the <RT·neologism>Counting Number</RT·neologism>s as the domain and bind <RT·math><</RT·math> to <RT·math>R</RT·math>: the formula <RT·math>∀x ∃y \, R(x, y)</RT·math> then states that every <RT·neologism>Counting Number</RT·neologism> has a larger one, and under that interpretation it holds. Every appearance in it is claimed by a quantifier, so the only things the interpretation had to give were the domain and the predicate.</p>
<p>The same three levels carry the first-order calculus. What a quantifier claims is a fact about the formula, so it is stated at level 1.</p>
- <RT·Counter·step counter="RT·List·counter" id="List·first-order-predicate-logic_stack">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·first-order-predicate-logic_stack"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·first-order-predicate-logic_stack">
+ <RT·name>The first order predicate logic stack</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·first-order-predicate-logic_stack"></RT·Counter·snapshot>
<ol reversed start="2">
<li>interpretation
<ul>
</ul>
</li>
</ol>
- List <RT·Counter·read snapshot="List·first-order-predicate-logic_stack"></RT·Counter·read>. <RT·name>The first order predicate logic stack</RT·name>
+ <RT·Counter·read snapshot="List·first-order-predicate-logic_stack" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<RT·section id="Section·Conventio·Logic·Second-order_predicate_calculus">
<p><RT·math>∀F \, \big( (F(0) ∧ ∀x \, (F(x) → F(s(x)))) → ∀x \, F(x) \big)</RT·math></p>
- <p>where <RT·math>0</RT·math> is a name marking the place of zero and <RT·math>s</RT·math> is a function symbol of one place marking the place of the successor function, both of which the formation rules admit within terms. The outermost quantifier has claimed the predicate variable, so the axiom states that any property holding of zero and carried from each <RT·neologism>Peano Number</RT·neologism> to its successor holds of every <RT·neologism>Peano Number</RT·neologism>.</p>
+ <p>where <RT·math>0</RT·math> is a name marking the place of zero and <RT·math>s</RT·math> is a function symbol of one place marking the place of the successor function, both of which the formation rules admit within terms. The outermost quantifier has claimed the predicate variable, so the axiom states that any property holding of zero and carried from each <RT·neologism>Counting Number</RT·neologism> to its successor holds of every <RT·neologism>Counting Number</RT·neologism>.</p>
<p>One cell of the abstraction stack changes, and it is the cell at level 0.</p>
- <RT·Counter·step counter="RT·List·counter" id="List·second-order-predicate-logic_stack">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·second-order-predicate-logic_stack"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·second-order-predicate-logic_stack">
+ <RT·name>The second order predicate logic stack</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·second-order-predicate-logic_stack"></RT·Counter·snapshot>
<ol reversed start="2">
<li>interpretation
<ul>
</ul>
</li>
</ol>
- List <RT·Counter·read snapshot="List·second-order-predicate-logic_stack"></RT·Counter·read>. <RT·name>The second order predicate logic stack</RT·name>
+ <RT·Counter·read snapshot="List·second-order-predicate-logic_stack" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Reading <RT·math>∀F</RT·math> as running over every property of the domain is the reading intended above, and it is called the <RT·term>standard semantics</RT·term>.<RT·endnote>The alternative is to let an interpretation nominate a smaller collection of properties for the quantifier to run over, which is the <em>Henkin semantics</em>. Leon Henkin, "Completeness in the Theory of Types", <em>Journal of Symbolic Logic</em> 15, no. 2 (1950): 81−91.</RT·endnote></p>
<p>Say a formula of the propositional calculus holds <RT·math>n</RT·math> distinct proposition symbols. An interpretation binds a proposition to each of them, and there is no counting the propositions, but the calculus reads nothing from a proposition except its truth value. What the formula answers to is therefore the induced binding of a truth value to each proposition symbol, and of those there are exactly <RT·math>2^n</RT·math>. A <RT·term>truth table</RT·term> is an enumeration of them, one per row.</p>
- <p>The <RT·term>Entscheidungsproblem</RT·term> asks for a mechanical procedure that decides, in finitely many steps, whether a given formula is valid. Enumerating the <RT·math>2^n</RT·math> rows of a truth table is such a procedure for the propositional calculus. For the first-order calculus an interpretation selects a domain of any size whatever, so there is no finite set of rows to enumerate. Chapter <RT·Counter·read snapshot="Section·Search_for_Turing_Machine"></RT·Counter·read> gives the history of the problem and where the search for a solution in the first order predicate calculus lead.<RT·endnote>Hilbert and Ackermann review the tabulation procedure for the propositional calculus in the first chapter of the 1928 book, before raising the same question for the first-order calculus. Their two formulations of the problem are distinguished by domains: the first asks for which domains of individuals a given expression is valid, and the second asks only whether it is valid for all of them.</RT·endnote></p>
+ <p>The <RT·term>Entscheidungsproblem</RT·term> asks for a mechanical procedure that decides, in finitely many steps, whether a given formula is valid. Enumerating the <RT·math>2^n</RT·math> rows of a truth table is such a procedure for the propositional calculus. For the first-order calculus an interpretation selects a domain of any size whatever, so there is no finite set of rows to enumerate. <RT·Counter·read snapshot="Section·Search_for_Turing_Machine" key="counter count"></RT·Counter·read> gives the history of the problem and where the search for a solution in the first order predicate calculus lead.<RT·endnote>Hilbert and Ackermann review the tabulation procedure for the propositional calculus in the first chapter of the 1928 book, before raising the same question for the first-order calculus. Their two formulations of the problem are distinguished by domains: the first asks for which domains of individuals a given expression is valid, and the second asks only whether it is valid for all of them.</RT·endnote></p>
<p>A <RT·term>derivation</RT·term> is a finite arrangement of formulas built from a stated collection of axioms by stated rules, ending at the formula being derived. Where validity asks what holds under every interpretation, derivation asks what can be reached by rearranging marks, and it consults no interpretation at all. Each is written with a symbol of its own, the <RT·term>double turnstile</RT·term> and the <RT·term>turnstile</RT·term>.</p>
- <RT·Counter·step counter="RT·List·counter" id="List·logic_turnstile">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·logic_turnstile"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·logic_turnstile">
+ <RT·name>The two assessments of a formula</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·logic_turnstile"></RT·Counter·snapshot>
<RT·dictionary key="notation" definition="reading">
<RT·entry key="⊨ Φ">Double turnstile. <RT·math>Φ</RT·math> holds under every interpretation.</RT·entry>
<RT·entry key="⊢ Φ">Turnstile. A derivation of <RT·math>Φ</RT·math> exists from the stated axioms and rules.</RT·entry>
</RT·dictionary>
- List <RT·Counter·read snapshot="List·logic_turnstile"></RT·Counter·read>. <RT·name>The two assessments of a formula</RT·name>
+ <RT·Counter·read snapshot="List·logic_turnstile" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>A collection of axioms and rules is <RT·term>sound</RT·term> when everything it derives is valid, so <RT·math>⊢</RT·math> never outruns <RT·math>⊨</RT·math>, and <RT·term>complete</RT·term> when everything valid is derivable, so <RT·math>⊨</RT·math> never outruns <RT·math>⊢</RT·math>.<RT·endnote>The turnstile is reused later in this book, subscripted with a machine, for the relation between one instantaneous description of a Turing Machine and the next. The subscript keeps the two apart on the page.</RT·endnote> A calculus together with a collection of axioms is a <RT·term>theory</RT·term>. Completeness is a property of the axioms and rules relative to the validities of a calculus, and is not the same question as whether a theory settles every statement it can express.</p>
- <p>Finally, the word <em>order</em> counts something different in each of the two places this book uses it, and the two scales are independent of each other. In the predicate calculus, the order counts what a quantifier runs over: a domain member at the first order, and a property of domain members at the second. In the <RT·term>orders of analysis</RT·term> set out in section <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis"></RT·Counter·read>, the order counts the depth of machines examining machines: running a machine is the first order, examining a machine’s definition is the second, and examining an examiner is the third. A second-order analysis of a machine that computes over the first-order predicate calculus is an ordinary thing, and nothing about it is second-order logic. Where a later chapter of this book speaks of second-order arithmetic, it is the orders of analysis that are meant. The same warning applies to metamathematics: a statement about a first-order system is made in the metalanguage, and that alone does not make it a second-order statement.</p>
+ <p>Finally, the word <em>order</em> counts something different in each of the two places this book uses it, and the two scales are independent of each other. In the predicate calculus, the order counts what a quantifier runs over: a domain member at the first order, and a property of domain members at the second. In the <RT·term>orders of analysis</RT·term> set out in <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis" key="counter count"></RT·Counter·read>, the order counts the depth of machines examining machines: running a machine is the first order, examining a machine’s definition is the second, and examining an examiner is the third. A second-order analysis of a machine that computes over the first-order predicate calculus is an ordinary thing, and nothing about it is second-order logic. Where a later chapter of this book speaks of second-order arithmetic, it is the orders of analysis that are meant. The same warning applies to metamathematics: a statement about a first-order system is made in the metalanguage, and that alone does not make it a second-order statement.</p>
</RT·section>
</RT·section>
<p>When a geometer erases his drawing the theorem is untouched. He draws it again badly and the theorem is untouched. Every square that has ever been drawn could be wiped away and the theorem would still hold, and it held before any of them were drawn. Such is the non-temporal nature of Forms.</p>
<p>
- The definition of a symbol given in section <RT·Counter·read snapshot="Section·Conventio·Symbol"></RT·Counter·read> is Platonic in its structure. It begins with an unnamed math object that has required properties. The definition then states that we do not write the symbol directly, as it remains abstract. A representation convention is chosen for example, a Greek letter say, and what appears on a page is an instance of that representation. Hence the Form is the symbol, the shape of the shadow is the representation, and the shadow itself is an instance.
+ The definition of a symbol given in <RT·Counter·read snapshot="Section·Conventio·Symbol" key="counter count"></RT·Counter·read> is Platonic in its structure. It begins with an unnamed math object that has required properties. The definition then states that we do not write the symbol directly, as it remains abstract. A representation convention is chosen for example, a Greek letter say, and what appears on a page is an instance of that representation. Hence the Form is the symbol, the shape of the shadow is the representation, and the shadow itself is an instance.
</p>
<p>
</p>
<p>
- A subtle difference remains between the Symbol as a Form and the symbol of section <RT·Counter·read snapshot="Section·Conventio·Symbol"></RT·Counter·read>. The structure is the same in both: an unwritten thing above, a representation, and many instances below. What differs is where the thing above is found. A Form is found in the Realm of Forms. The symbol of section <RT·Counter·read snapshot="Section·Conventio·Symbol"></RT·Counter·read> is found among math objects. A math object, being anything a mathematician cares to name, includes representations and instances, the only requirements are that the symbols be distinct and can be represented.
+ A subtle difference remains between the Symbol as a Form and the symbol of <RT·Counter·read snapshot="Section·Conventio·Symbol" key="counter count"></RT·Counter·read>. The structure is the same in both: an unwritten thing above, a representation, and many instances below. What differs is where the thing above is found. A Form is found in the Realm of Forms. The symbol of <RT·Counter·read snapshot="Section·Conventio·Symbol" key="counter count"></RT·Counter·read> is found among math objects. A math object, being anything a mathematician cares to name, includes representations and instances, the only requirements are that the symbols be distinct and can be represented.
</p>
</RT·section>
<RT·endnote>Aristotle, <em>Posterior Analytics</em> II.19, for knowledge beginning in perception and rising by induction to the principles. The Greek term for the operation is <em>epagōgē</em>, rendered as <RT·term>induction</RT·term>.</RT·endnote>
</p>
- <p>After years of challenging Plato over the Realm of Forms, the debate ended when Plato passed away. Aristotle was not chosen to take his place to head the Academy. The chair went to Plato’s nephew Speusippus, a name few people are familiar with today, and the estate to family.
+ <p>Aristotle’s direct challenges to Plato over his concept of the Realm of Forms came to an end when Plato passed away. Aristotle was not chosen to take his place to head the Academy. The estate went to Plato’s family, and the chair of the school went to Plato’s nephew Speusippus, a name few people recognize today.
<RT·endnote>Speusippus, son of Plato’s sister Potone, headed the school for eight years; Diogenes Laertius, <em>Lives</em> IV.1. The will leaves the estate at Iphistiadae to a boy named Adeimantus, taken to be a young kinsman since Plato had a brother of that name, and lists a second estate at Eiresidae; <em>Lives</em> III.41−42. Headship of the school and title to the land were separate things, and neither came to Aristotle. The Academy grove itself was a public gymnasium, not Plato’s to bequeath, and Aristotle, a Stagirite and therefore a metic at Athens, could not have held Attic land in any case.</RT·endnote>
- Upon leaving Aristotle dedicated his time to studying the natural world. He dissected, he collected, and he questioned fishermen and beekeepers about what they had seen; his account of the developing chick came from opening eggs on successive days.
+ Upon leaving, Aristotle dedicated his time to studying the natural world. He dissected, he collected, and he questioned fishermen and beekeepers about what they had seen; his account of the developing chick came from opening eggs on successive days.
<RT·endnote>Aristotle, <em>Historia Animalium</em> VI.3 561a for the chick; V.12 541b for the modified arm of the male octopus, which was thought a fable until confirmed in 1857. He was wrong about a great deal, holding the heart to be the seat of thought and the brain an organ for cooling the blood. Darwin, thanking William Ogle in 1882 for a translation of the <em>Parts of Animals</em>, wrote that Linnaeus and Cuvier had been his two gods, but that they were mere schoolboys compared to old Aristotle. Charles Darwin to William Ogle, 22 February 1882, in Francis Darwin, ed., <em>The Life and Letters of Charles Darwin</em> (London: John Murray, 1887), vol. 3, 252.</RT·endnote>
- What he produced from it was a <RT·term>taxonomy</RT·term>: animals sorted by the features they share, the sorting answerable to the specimens and revised whenever a specimen refused its category.</p>
+ What he produced from it was a <RT·term>taxonomy</RT·term>: animals sorted by the features they share, the sorting answerable to the specimens and revised whenever a specimen refused its category.
+ </p>
<p>This perspective, that knowledge comes from the categorization of observations of nature rather than, as Plato taught, from the conceptualization of Forms, is the essence of <RT·term>Naturalism</RT·term>. There are two modern definitions for Naturalism. One definition is that of a philosophy that nothing exists outside of nature. This philosophy is generally taken to deny the existence of any abstraction standing apart from what could be observed, including that of the Realm of Forms. The other definition is that of a study of nature, that of a wildlife biologist.</p>
<RT·section id="Section·Naturalism·The_argument_since">
<RT·name>Metamorphosis of the dielectic</RT·name>
- <p>Debate over the dialectic continued for two millennia between the decline of the Athenian Academy and the 19th century. There is a brief review of this interim period in the appendix of chapter <RT·Counter·read snapshot="Section·Appendix_dialectic_to_Kant"></RT·Counter·read>. In the 19th century there were two revolutionary developments that changed the form of the dialectic. The symbolic logic foundation of mathematics, and the advent of thinking machines.</p>
+ <p>Debate over the dialectic continued for two millennia between the decline of the Athenian Academy and the 19th century. There is a brief review of this interim period in the appendix of <RT·Counter·read snapshot="Section·Appendix_dialectic_to_Kant" key="counter count"></RT·Counter·read>. In the 19th century there were two revolutionary developments that changed the form of the dialectic. The symbolic logic foundation of mathematics, and the advent of thinking machines.</p>
<p>A person might say that Plato had won over the mathematicians. The Forms were no longer discussed as a separate realm; they had been recast as symbols, relations, and rules that could be manipulated within a formal system. George Boole put logical operations into an algebra. Georg Cantor made infinite collections a subject of mathematical investigation. Richard Dedekind sought to characterize the natural numbers through objects, systems, and mappings, and in <em>Was sind und was sollen die Zahlen?</em> (1888) described what he called a <em>simply infinite system</em>. Giuseppe Peano published a closely corresponding axiomatization in <em>Arithmetices principia, nova methodo exposita</em> (1889), acknowledging Dedekind’s earlier work.
<RT·endnote>George Boole, <em>The Mathematical Analysis of Logic</em> (Cambridge: Macmillan, Barclay & Macmillan, 1847), and <em>An Investigation of the Laws of Thought</em> (London: Walton and Maberly, 1854). Georg Cantor’s work on set theory and transfinite numbers expanded the mathematical study of infinity. Richard Dedekind, <em>Was sind und was sollen die Zahlen?</em> (Braunschweig: Vieweg, 1888); Giuseppe Peano, <em>Arithmetices principia, nova methodo exposita</em> (Turin: Fratres Bocca, 1889). Dedekind’s simply infinite system and Peano’s axiomatization are historically distinct formulations of the natural-number structure. Peano’s presentation is closely related to Dedekind’s earlier formulation, and modern historical accounts therefore often refer to the shared lineage as the <em>Dedekind−Peano axioms</em>. “Dedekind number” is already used for a different mathematical sequence, so it is not adopted here as an alternative name.</RT·endnote>
<p>Yet Kleene is not the counterexample he first appears to be. His 1952 <em>Introduction to Metamathematics</em> returns to the natural setting at each of the three places where the formalism has to be tied to something outside itself:</p>
- <RT·Counter·step counter="RT·List·counter" id="List·Kleene_natural-settings">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·Kleene_natural-settings"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·Kleene_natural-settings">
+ <RT·name>Where Kleene reaches for a natural setting</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·Kleene_natural-settings"></RT·Counter·snapshot>
<ol>
<li>At the opening of the book, to ground one-to-one correspondence before cardinality is defined. Kleene writes, "A flock of four sheep and a grove of four trees are related to each other in a way in which neither is related to a pile of three stones or a grove of seven trees. ... Without counting the sheep or the trees, one can pair them with each other, for example by tethering the sheep to the trees, so that each sheep and each tree belongs to exactly one of the pairs."<RT·endnote>Stephen Cole Kleene, <em>Introduction to Metamathematics</em> (Amsterdam: North-Holland, 1952), 3.</RT·endnote></li>
<li>At the introduction of the formal system, to say what a symbol is. Kleene proposes that the symbols be thought of concretely as marks on paper, or more precisely as abstracted from our experience with marks on paper, and then observes in a parenthesis that proof theory has to remain abstract to some degree because it supposes arbitrarily long symbol sequences to be constructible, while the paper and ink in the world are finite.<RT·endnote>Kleene 1952, 62. The parenthesis is the concession this book is built on: the idealization is named as an idealization, and the reason given for it is a physical bound.</RT·endnote></li>
<li>At the definition of the machine, and again in its defense. Kleene does not open the chapter on computable functions with a formalism. He opens with a person computing a function by following pre-assigned instructions, using finitely many tokens, able to observe only finitely many at once and to remember only finitely many more, and derives the atomic acts of the machine from what that person can do. The subsequent defense of Turing’s thesis is conducted entirely over such a person, who ticks figures off in pencil to avoid counting them twice, and who may read a symbol on paper by eye, another in braille by hand, and take a signal by ear.<RT·endnote>Kleene 1952, 356 for the derivation, 377−381 for the defense.</RT·endnote></li>
</ol>
- List <RT·Counter·read snapshot="List·Kleene_natural-settings"></RT·Counter·read>. <RT·name>Where Kleene reaches for a natural setting</RT·name>
+ <RT·Counter·read snapshot="List·Kleene_natural-settings" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>At the same time that the dialectic appeared to have been resolved in favor of the abstract, it reappeared incarnate. The resolution had been to say that mathematics is the manipulation of symbols under rules within a formal system. But the manipulation of symbols under rules is something a device can be built to do. In declaring itself formal, mathematics had declared itself mechanizable, and a mechanism is an object with a mass and a temperature that a person can put on a bench and turn a crank on. The Forms had been driven out of the heavens and into the notation, and the notation could be cut into brass. Whatever else that is, it is a natural object, and it can be observed.</p>
<p>Such objects were not new. The Antikythera mechanism carries a model of the heavens in bronze gearing, and it predates the argument it settles by two thousand years.
<RT·endnote>The shipwreck is dated to about 60 BC, which fixes the latest possible construction. Estimates of construction itself range from about 205 BC, taken from the epoch of the eclipse dials, to Derek de Solla Price’s earlier figure of about 87 BC, with the inscriptions favouring roughly 150 to 100 BC. No consensus exists on whether the device was built shortly before the wreck or well before it. The field remains active: a 2024 re-analysis of the calendar ring hole positions put the count near 354 or 355, which argues for a lunar rather than a solar ring.</RT·endnote>
- In 1642 Blaise Pascal built a machine that added, and in doing so discovered that a carry is not free. His sautoir lifted a weight and dropped it into the next wheel, and the number of wheels a single carry could propagate through was a matter of how much force the mechanism could raise. Leibniz took up the problem thirty years later with a stepped drum that multiplied, and his carriage never worked reliably across the full width of the register. He wanted more than arithmetic from it. He wanted a <em>calculus ratiocinator</em>, a reckoning that would settle disputes by computation, which is Hobbes’s claim that reasoning is a kind of reckoning taken seriously enough to be machined. Charles Babbage then built a machine that evaluated polynomials by the method of forward differences, the same construction taken up in section <RT·Counter·read snapshot="Section·Computational_Analysis"></RT·Counter·read>, and went on to design the Analytical Engine, treated in section <RT·Counter·read snapshot="Section·Prescience_and_credit"></RT·Counter·read>.
+ In 1642 Blaise Pascal built a machine that added, and in doing so discovered that a carry is not free. His sautoir lifted a weight and dropped it into the next wheel, and the number of wheels a single carry could propagate through was a matter of how much force the mechanism could raise. Leibniz took up the problem thirty years later with a stepped drum that multiplied, and his carriage never worked reliably across the full width of the register. He wanted more than arithmetic from it. He wanted a <em>calculus ratiocinator</em>, a reckoning that would settle disputes by computation, which is Hobbes’s claim that reasoning is a kind of reckoning taken seriously enough to be machined. Charles Babbage then built a machine that evaluated polynomials by the method of forward differences, the same construction taken up in <RT·Counter·read snapshot="Section·Computational_Analysis" key="counter count"></RT·Counter·read>, and went on to design the Analytical Engine, treated in <RT·Counter·read snapshot="Section·Prescience_and_credit" key="counter count"></RT·Counter·read>.
<RT·endnote>Blaise Pascal began the machine in 1642 and some fifty were made. Gottfried Wilhelm Leibniz demonstrated a stepped reckoner to the Royal Society in 1673 and had a working instrument by 1694; the carry across the full register was never dependable. On the <em>calculus ratiocinator</em>, see the 1666 <em>Dissertatio de arte combinatoria</em> and the later sketches for a universal characteristic.</RT·endnote>
</p>
<RT·endnote>Richard Owen, <em>Lectures on the Comparative Anatomy and Physiology of the Invertebrate Animals</em> (London: Longman, Brown, Green & Longmans, 1843), 374 and 379 for the two definitions. Owen distinguished special homology, holding between species, from serial homology, holding between the repeated parts of one organism, and from general homology, relating a part to the archetype. His criteria for deciding a homology were position, development, and composition. The account is pre-evolutionary: the archetype is a plan, not an ancestor. Darwin supplied the ancestor in 1859 and the vocabulary survived the substitution intact, which is the point being borrowed here.</RT·endnote>
</p>
- <p>Notice that Owen’s distinction is doing work in this book already, under other names. Two architectures that compute the same class of functions are analogues: same function, different parts. That is what <RT·term>Turing Complete</RT·term> asserts, and it asserts nothing about how either machine is built. A transform that carries one machine to another while leaving every computation theoretic question with the same answer is asserting a homology: the same organ, under a variety of form. Section <RT·Counter·read snapshot="Section·Three_conditions"></RT·Counter·read> observes that the second requirement is the stronger of the two, and Owen would have said the same of his pair. The wing of a bat and the wing of a bee are analogues and tell you nothing about each other’s construction. The wing of a bat and the arm of a man are homologues, and either one can be read off the other bone by bone.</p>
+ <p>Notice that Owen’s distinction is doing work in this book already, under other names. Two architectures that compute the same class of functions are analogues: same function, different parts. That is what <RT·term>Turing Complete</RT·term> asserts, and it asserts nothing about how either machine is built. A transform that carries one machine to another while leaving every computation theoretic question with the same answer is asserting a homology: the same organ, under a variety of form. <RT·Counter·read snapshot="Section·Three_conditions" key="counter count"></RT·Counter·read> observes that the second requirement is the stronger of the two, and Owen would have said the same of his pair. The wing of a bat and the wing of a bee are analogues and tell you nothing about each other’s construction. The wing of a bat and the arm of a man are homologues, and either one can be read off the other bone by bone.</p>
<p>That is why the comparison is worth making rather than merely amusing. A naturalist who has only analogy has a list of things that do the same job. A naturalist who has homology has a method: he can carry a finding from one specimen to another and know what he is entitled to carry. The transforms in the chapters that follow are homologies, and the argument that they are inconsequential is the argument that the carrying is legitimate.</p>
</p>
<p>
- The authority to remove Russell’s Paradox set formulation comes from the set <RT·math>S</RT·math>. It is not that undefined sets are disallowed, as <RT·math>\dot{R}</RT·math> is perfectly well defined, the Axiom of Separation having defined it. It is that membership in <RT·math>S</RT·math> is granted by prior construction and never by satisfying a condition. A condition can only partition what <RT·math>S</RT·math> already holds, so it has no power to admit. This is why the very condition that is fatal under unrestricted comprehension is harmless under separation: in the first it was doing the admitting, and in the second it is not. Though this invites an objection. If <RT·math>S</RT·math> is stocked in advance, and a condition can only sort what is already inside, then have we not merely arranged for <RT·math>\dot{R}</RT·math> to be absent and called the arrangement a repair? I sometimes wonder how mathematics might have evolved had Frege simply taken that approach and declared such formulations dismissed. It is not the same thing, and showing why requires machinery we do not have yet. We take the question up again in section <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis"></RT·Counter·read>.
+ The authority to remove Russell’s Paradox set formulation comes from the set <RT·math>S</RT·math>. It is not that undefined sets are disallowed, as <RT·math>\dot{R}</RT·math> is perfectly well defined, the Axiom of Separation having defined it. It is that membership in <RT·math>S</RT·math> is granted by prior construction and never by satisfying a condition. A condition can only partition what <RT·math>S</RT·math> already holds, so it has no power to admit. This is why the very condition that is fatal under unrestricted comprehension is harmless under separation: in the first it was doing the admitting, and in the second it is not. Though this invites an objection. If <RT·math>S</RT·math> is stocked in advance, and a condition can only sort what is already inside, then have we not merely arranged for <RT·math>\dot{R}</RT·math> to be absent and called the arrangement a repair? I sometimes wonder how mathematics might have evolved had Frege simply taken that approach and declared such formulations dismissed. It is not the same thing, and showing why requires machinery we do not have yet. We take the question up again in <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis" key="counter count"></RT·Counter·read>.
</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>
- <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·Counter·step counter="Code" id="Code·halting_diagonal-machine">
+ <RT·name>The diagonal machine that defeats a supposed halting decider</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·halting_diagonal-machine"></RT·Counter·snapshot>
<RT·code>
M(x){
if( H(x ,x) == 'Y' ) while(true);
else 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·read snapshot="Code·halting_diagonal-machine" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
<RT·name>The conditions on a Natural machine</RT·name>
<p>
- The Computational Naturalism thesis holds that mathematics is a taxonomy of machine observations. This sets some conditions. For a machine to be observed, it must be possible to realize it. For observations of the machine to be relevant, its program must be able to encompass any statement in mathematics, being a second condition, and execution must be faithful to the program, being a third condition. The third condition will be met if said observable machine is a <RT·neologism-em>computation theoretic inconsequential</RT·neologism-em> variation of the Turing Machine. This property is formally defined in chapter <RT·Counter·read snapshot="Section·Consequentiality"></RT·Counter·read>; informally it means that the observed machine gives the same computation theoretic results as a Turing Machine. This argument builds on the work already done with Turing Machines, and it establishes that said programs are executed faithfully to their meaning.
+ The Computational Naturalism thesis holds that mathematics is a taxonomy of machine observations. This sets some conditions. For a machine to be observed, it must be possible to realize it. For observations of the machine to be relevant, its program must be able to encompass any statement in mathematics, being a second condition, and execution must be faithful to the program, being a third condition. The third condition will be met if said observable machine is a <RT·neologism-em>computation theoretic inconsequential</RT·neologism-em> variation of the Turing Machine. This property is formally defined in <RT·Counter·read snapshot="Section·Consequentiality" key="counter count"></RT·Counter·read>; informally it means that the observed machine gives the same computation theoretic results as a Turing Machine. This argument builds on the work already done with Turing Machines, and it establishes that said programs are executed faithfully to their meaning.
</p>
<p>
- The Turing Machine itself fails the first condition. It cannot be built, so the machine that started the Naturalism thesis cannot carry the thesis. Some other machine has to, and satisfying the third condition is what makes the substitution of the new machine valid. A realizable machine that is not a computation theoretic inconsequential variation of the Turing Machine is merely some other machine, and a catalog of observations of it is a catalog of nothing in particular. The obvious candidate is the computer already sitting on the desk, which descends from the concrete machine Babbage drew rather than from the paper one Turing described. It is realizable by construction, it is the machine people actually own and run, and were it to satisfy the third condition the thesis would be finished here, with no proposal to make and no book to write. It does not satisfy it. Establishing that, and locating precisely where it fails, is in part the business of this book. A machine that does satisfy all three conditions is the <RT·neologism>Realizable Machine</RT·neologism> of chapter <RT·Counter·read snapshot="Section·Realizable_computation_theoretic"></RT·Counter·read>. The capitals mark a term carrying a formal definition that displaces its ordinary English sense, as they do for Real. A Realizable Machine is not merely a machine that happens to be realizable, which the computer on the desk also is; it is a machine meeting all three of the conditions set out above.
+ The Turing Machine itself fails the first condition. It cannot be built, so the machine that started the Naturalism thesis cannot carry the thesis. Some other machine has to, and satisfying the third condition is what makes the substitution of the new machine valid. A realizable machine that is not a computation theoretic inconsequential variation of the Turing Machine is merely some other machine, and a catalog of observations of it is a catalog of nothing in particular. The obvious candidate is the computer already sitting on the desk, which descends from the concrete machine Babbage drew rather than from the paper one Turing described. It is realizable by construction, it is the machine people actually own and run, and were it to satisfy the third condition the thesis would be finished here, with no proposal to make and no book to write. It does not satisfy it. Establishing that, and locating precisely where it fails, is in part the business of this book. A machine that does satisfy all three conditions is the <RT·neologism>Realizable Machine</RT·neologism> of <RT·Counter·read snapshot="Section·Realizable_computation_theoretic" key="counter count"></RT·Counter·read>. The capitals mark a term carrying a formal definition that displaces its ordinary English sense, as they do for Real. A Realizable Machine is not merely a machine that happens to be realizable, which the computer on the desk also is; it is a machine meeting all three of the conditions set out above.
</p>
<p>
</p>
<p>
- The problem with the controller is more nuanced. The head of a Turing Machine 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. This is treated in detail in section <RT·Counter·read snapshot="Section·Conventional_Turing_Machine·Analysis_of_the_reverse_machine"></RT·Counter·read>, where a machine that reverses a string is analyzed and the consequence is proven: the number of states and arcs required grows exponentially with 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 fixed at the start. The tape’s limit can be handed outside the machine and dealt with there, as we have just seen. The controller’s limit is sealed inside the model, where nothing can reach it.
+ The problem with the controller is more nuanced. The head of a Turing Machine 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. This is treated in detail in <RT·Counter·read snapshot="Section·Conventional_Turing_Machine·Analysis_of_the_reverse_machine" key="counter count"></RT·Counter·read>, where a machine that reverses a string is analyzed and the consequence is proven: the number of states and arcs required grows exponentially with 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 fixed at the start. The tape’s limit can be handed outside the machine and dealt with there, as we have just seen. The controller’s limit is sealed inside the model, where nothing can reach it.
</p>
<p>
</p>
<p>
- The remainder is delivered by construction rather than by thesis, and it occupies much of this book. A tape cell is defined as a location in physical memory in section <RT·Counter·read snapshot="Section·Binding·Turing_Machine_tape_cell"></RT·Counter·read>, and a symbol in computational terms in section <RT·Counter·read snapshot="Section·Symbol·In_computing"></RT·Counter·read>. Logic follows from relay switch logic, as Shannon and others have already established. On top of logic sits the Peano Machine, a counter, which then serves as the definition of <RT·neologism>Peano Number</RT·neologism>s. Where Gödel reduced logic to <RT·neologism>Peano Number</RT·neologism>s, we run the other way and expand logic out of them. An axiomatic proof becomes a decider assembled from subroutine calls to the axioms. Frege’s set theory becomes the analysis of a logic program against an enumeration of inputs. Russell’s paradox becomes a machine that can be analyzed in the second order though it will never halt in the first, which requires the orders of analysis set out in section <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis"></RT·Counter·read>. The whole is drawn together in chapter <RT·Counter·read snapshot="Section·Computational_Naturalism"></RT·Counter·read>, where the claim is that every statement a mathematician has ever made can be restated in this language.
+ The remainder is delivered by construction rather than by thesis, and it occupies much of this book. A tape cell is defined as a location in physical memory in <RT·Counter·read snapshot="Section·Binding·Turing_Machine_tape_cell" key="counter count"></RT·Counter·read>, and a symbol in computational terms in <RT·Counter·read snapshot="Section·Symbol·In_computing" key="counter count"></RT·Counter·read>. Logic follows from relay switch logic, as Shannon and others have already established. On top of logic sits the Counting Machine, a counter, which then serves as the definition of <RT·neologism>Counting Number</RT·neologism>s. Where Gödel reduced logic to <RT·neologism>Counting Number</RT·neologism>s, we run the other way and expand logic out of them. An axiomatic proof becomes a decider assembled from subroutine calls to the axioms. Frege’s set theory becomes the analysis of a logic program against an enumeration of inputs. Russell’s paradox becomes a machine that can be analyzed in the second order though it will never halt in the first, which requires the orders of analysis set out in <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis" key="counter count"></RT·Counter·read>. The whole is drawn together in <RT·Counter·read snapshot="Section·Stored_program" key="counter count"></RT·Counter·read>, where the claim is that every statement a mathematician has ever made can be restated in this language.
</p>
<p>
</p>
<p>
- There is a remedy, and it occupies the chapters that follow. 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, those 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. That machine, the Realizable Machine of chapter <RT·Counter·read snapshot="Section·Realizable_computation_theoretic"></RT·Counter·read>, satisfies the first condition by being buildable and the third by the manner of its construction, and it inherits the second from the Turing Machine it was transformed out of. Neither the Turing Machine nor the computer on the desk is a Natural manifestation of mathematics. The Realizable Machine, standing between them, is.
+ There is a remedy, and it occupies the chapters that follow. 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, those 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. That machine, the Realizable Machine of <RT·Counter·read snapshot="Section·Realizable_computation_theoretic" key="counter count"></RT·Counter·read>, satisfies the first condition by being buildable and the third by the manner of its construction, and it inherits the second from the Turing Machine it was transformed out of. Neither the Turing Machine nor the computer on the desk is a Natural manifestation of mathematics. The Realizable Machine, standing between them, is.
</p>
</RT·section>
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>
+ <RT·Counter·step counter="List" id="List·abstraction-stack_levels">
+ <RT·name>The six levels of the computer design abstraction stack</RT·name>
+ <RT·Counter·snapshot counter="List" 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>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·read snapshot="List·abstraction-stack_levels" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
</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·Realizable_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.
+ 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 <RT·Counter·read snapshot="Section·Realizable_machine_design" key="counter count"></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 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>
+ <RT·Counter·step counter="List" id="List·Turing-Machine_missing-components">
+ <RT·name>What the Turing Machine leaves out of its architecture</RT·name>
+ <RT·Counter·snapshot counter="List" 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 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·read snapshot="List·Turing-Machine_missing-components" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
</p>
<p>
- Russell’s set formulation of section <RT·Counter·read snapshot="Section·Search_for_Turing_Machine"></RT·Counter·read> is worth taking up here. It is perfectly legal to write a Turing Machine that accepts or rejects a proposed element by evaluating a logical predicate on it, and <RT·math>R = \{x \mid x ∉ x\}</RT·math> is such a machine. Asked whether <RT·math>R</RT·math> is a member of <RT·math>R</RT·math>, it will not halt. First-order analysis therefore returns nothing about it at all, which is the condition described above under which the only remaining option is a higher-order analysis. So the machine, its input, and the whole system around it are written to a tape and reasoned about instead, which is what was done in that section and what we are doing here. <RT·math>R</RT·math> is not dismissed. It is promoted.
+ Russell’s set formulation of <RT·Counter·read snapshot="Section·Search_for_Turing_Machine" key="counter count"></RT·Counter·read> is worth taking up here. It is perfectly legal to write a Turing Machine that accepts or rejects a proposed element by evaluating a logical predicate on it, and <RT·math>R = \{x \mid x ∉ x\}</RT·math> is such a machine. Asked whether <RT·math>R</RT·math> is a member of <RT·math>R</RT·math>, it will not halt. First-order analysis therefore returns nothing about it at all, which is the condition described above under which the only remaining option is a higher-order analysis. So the machine, its input, and the whole system around it are written to a tape and reasoned about instead, which is what was done in that section and what we are doing here. <RT·math>R</RT·math> is not dismissed. It is promoted.
</p>
<p>
Suppose we are given a Turing Machine <RT·math>m_i</RT·math>, which will potentially be run after being given any one of a number of input tapes <RT·math>x_{i,j}</RT·math>. For each of those inputs, the same tape with the results written upon it will be <RT·math>r_{i,j}</RT·math>. We notate this as:
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·machine_result_notation">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·machine_result_notation"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·machine_result_notation">
+ <RT·name>Machine m_i given input tape x_{i,j} writes result tape r_{i,j}</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·machine_result_notation"></RT·Counter·snapshot>
<RT·math>
m_i(x_{i,j}) = r_{i,j}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·machine_result_notation"></RT·Counter·read> <RT·name>Machine m_i given input tape x_{i,j} writes result tape r_{i,j}</RT·name>
+ <RT·Counter·read snapshot="Equation·machine_result_notation" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
Here the subscripts of the same name set up a correspondence. <RT·math>x_{i,j}</RT·math> is the <RT·math>j</RT·math>th input to the machine <RT·math>m_i</RT·math>, etc. The free variable <RT·math>j</RT·math> runs over all the interesting distinct input tapes to be given to machine <RT·math>m_i</RT·math>. So for example, if we had a machine, say <RT·math>m_8</RT·math>, and we had a set of three inputs to be given to <RT·math>m_8</RT·math>, then:
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·machine_result_example">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·machine_result_example"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·machine_result_example">
+ <RT·name>Machine m_8 over a set of three input tapes</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·machine_result_example"></RT·Counter·snapshot>
<RT·math>
\begin{aligned}
m_8(x_{8,0}) &= r_{8,0} \\
m_8(x_{8,2}) &= r_{8,2}
\end{aligned}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·machine_result_example"></RT·Counter·read> <RT·name>Machine m_8 over a set of three input tapes</RT·name>
+ <RT·Counter·read snapshot="Equation·machine_result_example" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
Now suppose that a machine <RT·math>m_{i.1}</RT·math> is the result of a transformation, <RT·math>T</RT·math>, applied to machine <RT·math>m_i</RT·math>.
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·transform_notation">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·transform_notation"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·transform_notation">
+ <RT·name>Transform T carries machine m_i to machine m_{i.1}</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·transform_notation"></RT·Counter·snapshot>
<RT·math>
m_i \xrightarrow{T} m_{i.1}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·transform_notation"></RT·Counter·read> <RT·name>Transform T carries machine m_i to machine m_{i.1}</RT·name>
+ <RT·Counter·read snapshot="Equation·transform_notation" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
We can then assign a property to transform <RT·math>T</RT·math> called its <RT·neologism>doesn’t change results</RT·neologism> property, as follows. If and only if:
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·same-results_single-machine">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·same-results_single-machine"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·same-results_single-machine">
+ <RT·name>The doesn’t change results condition for one machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·same-results_single-machine"></RT·Counter·snapshot>
<RT·math>
\forall j \colon r_{i,j} = r_{i.1,j}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·same-results_single-machine"></RT·Counter·read> <RT·name>The doesn’t change results condition for one machine</RT·name>
+ <RT·Counter·read snapshot="Equation·same-results_single-machine" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
If, and only if, it is the case that
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·same-results_all-machines">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·same-results_all-machines"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·same-results_all-machines">
+ <RT·name>The same results transform property, over all machines</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·same-results_all-machines"></RT·Counter·snapshot>
<RT·math>
\forall i, \forall j \colon r_{i,j} = r_{i.1,j}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·same-results_all-machines"></RT·Counter·read> <RT·name>The same results transform property, over all machines</RT·name>
+ <RT·Counter·read snapshot="Equation·same-results_all-machines" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
Suppose we also have a computation theory <RT·math>C</RT·math> that allows us to analyze some machines so as to answer some questions we find interesting. Suppose furthermore that among these questions are questions of time and space complexity, along with zero or more questions about decidability. Furthermore, we are given a machine, say <RT·math>m_i</RT·math>, for which these questions have answers. We represent this as:
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·question_answer_notation">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·question_answer_notation"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·question_answer_notation">
+ <RT·name>A computation theoretic question and the answer it has for a machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·question_answer_notation"></RT·Counter·snapshot>
<RT·math>
a_{i,k} = q_{i,k}(m_i, \{x_{i,j}\})
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·question_answer_notation"></RT·Counter·read> <RT·name>A computation theoretic question and the answer it has for a machine</RT·name>
+ <RT·Counter·read snapshot="Equation·question_answer_notation" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
As we had already discovered when determining that <RT·math>T</RT·math> is a same results transform, <RT·math>T</RT·math> transforms machine <RT·math>m_i</RT·math> into machine <RT·math>m_{i.1}</RT·math>.
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·transform_restated">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·transform_restated"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·transform_restated">
+ <RT·name>Transform T carries machine m_i to machine m_{i.1}, restated</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·transform_restated"></RT·Counter·snapshot>
<RT·math>
m_i \xrightarrow{T} m_{i.1}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·transform_restated"></RT·Counter·read> <RT·name>Transform T carries machine m_i to machine m_{i.1}, restated</RT·name>
+ <RT·Counter·read snapshot="Equation·transform_restated" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
For our specific machine <RT·math>m_i</RT·math>, if and only if:
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·inconsequential_single-machine">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·inconsequential_single-machine"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·inconsequential_single-machine">
+ <RT·name>The inconsequential condition for one machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·inconsequential_single-machine"></RT·Counter·snapshot>
<RT·math>
\forall k \colon a_{i,k} = a_{i.1,k}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·inconsequential_single-machine"></RT·Counter·read> <RT·name>The inconsequential condition for one machine</RT·name>
+ <RT·Counter·read snapshot="Equation·inconsequential_single-machine" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
If, and only if, it is the case that:
</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·inconsequential_all-machines">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·inconsequential_all-machines"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·inconsequential_all-machines">
+ <RT·name>The computation theoretic inconsequential transform property</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·inconsequential_all-machines"></RT·Counter·snapshot>
<RT·math>
\forall i, \forall k \colon a_{i,k} = a_{i.1,k}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·inconsequential_all-machines"></RT·Counter·read> <RT·name>The computation theoretic inconsequential transform property</RT·name>
+ <RT·Counter·read snapshot="Equation·inconsequential_all-machines" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
<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·Counter·step counter="Equation" id="Equation·conventional-machine_definition">
+ <RT·name>The conventional Turing Machine as a seven tuple</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·conventional-machine_definition" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="List" id="List·conventional-machine_components">
+ <RT·name>The components of the conventional Turing Machine M</RT·name>
+ <RT·Counter·snapshot counter="List" 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>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·read snapshot="List·conventional-machine_components" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>I introduced the qualifier <em>programmed</em> in front of the <em>finite state machine controller</em> because each Turing Machine that accomplishes a different task has a different finite state machine controller. A <RT·term-em>program</RT·term-em> is then a set of assignments to the variable parts of the Turing Machine definition. Notice that additional variables are needed by the Turing Machine executor beyond those that appear in the definition, such as the current state variable. In alternative terminology, the definition above defines a Turing Machine <RT·term-em>type</RT·term-em>, and a set of assignments to the variable parts of the definition constitutes an <RT·term-em>instance</RT·term-em>. Accordingly, then, when a computer arithmetician says he has two Turing Machine<em>s</em>, he is saying that he has two distinct sets of Turing Machine variable assignments, and as these sets are distinct, each can be manipulated independently.</p>
<p>Hopcroft and Ullman explain a step of the machine by showing a representation of the tape with the state variable melded in to the left of the currently scanned symbol. Suppose <RT·math>δ(q, X_i) = (p, Y, L)</RT·math>; i.e., the next move is leftward. Then,
</p>
- <RT·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·Counter·step counter="Equation" id="Equation·instantaneous-description_left-move">
+ <RT·name>An instantaneous description rewritten by a leftward move</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·instantaneous-description_left-move" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>So first the tape is <RT·math>X_1 X_2 ⋯ X_{i-1} X_i X_{i+1} ⋯ X_n</RT·math>, with the head over <RT·math>X_i</RT·math>, and in state <RT·math>q</RT·math>. Then after a step of the machine, the tape is <RT·math>X_1 X_2 ⋯ X_{i-1} Y X_{i+1} ⋯ X_n</RT·math>, with the head over <RT·math>X_{i-1}</RT·math>, and in state <RT·math>p</RT·math>. Thus <RT·math>X_i</RT·math> was overwritten with <RT·math>Y</RT·math>, and the head stepped left.
<p>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>
+ <RT·Counter·step counter="Figure" id="Figure·conventional_reverse-machine">
+ <RT·name>A conventional Turing Machine that reverses a binary string</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·conventional_reverse-machine" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·conventional-reverse_YAML">
+ <RT·name>The conventional reverse machine, as TuringMachine.io YAML</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·conventional-reverse_YAML"></RT·Counter·snapshot>
<RT·code>
# YAML
# Reverses a binary string using a single marker and an EOM terminator.
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·read snapshot="Code·conventional-reverse_YAML" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·conventional-reverse_trace">
+ <RT·name>A step-by-step trace of the conventional reverse machine</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·conventional-reverse_trace"></RT·Counter·snapshot>
<RT·code>
q_init • 1 1 0
q1 •1 1 0
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·read snapshot="Code·conventional-reverse_trace" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<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·Counter·step counter="Equation" id="Equation·conventional-reverse_step-count">
+ <RT·name>Steps taken by the conventional reverse machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·conventional-reverse_step-count"></RT·Counter·snapshot>
<RT·math>
\text{steps} =
\begin{cases}
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·read snapshot="Equation·conventional-reverse_step-count" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>This shows string reversal to be an <RT·math>O(n^2)</RT·math> complexity problem, which might appear to some programmers as a peculiar result, as the same problem can be solved in <RT·math>O(n)</RT·math> time with a C program. This justifies further analysis.</p>
<p>For a 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·Counter·step counter="Equation" id="Equation·conventional-reverse_state-count">
+ <RT·name>States required by the conventional reverse machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·conventional-reverse_state-count" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Equation" id="Equation·conventional-reverse_arc-count">
+ <RT·name>Arcs required by the conventional reverse machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·conventional-reverse_arc-count" key="counter count step"></RT·Counter·read>
</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>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>
+ <RT·Counter·step counter="Table" id="Table·Hennessy-Patterson_chapters">
+ <RT·name>The chapter list of Hennessy and Patterson, Computer Architecture: A Quantitative Approach</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·Hennessy-Patterson_chapters"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<tbody>
</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·read snapshot="Table·Hennessy-Patterson_chapters" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Equation" id="Equation·empty-tape_as_empty-sets">
+ <RT·name>An empty tape written as a sequence of empty sets</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·empty-tape_as_empty-sets" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Here, each tape member set is called a <RT·term>cell</RT·term>. This definition for an empty tape is specific to Turing Machines, as in mathematics an empty sequence has zero length. An empty tape is not an empty sequence, rather it is an infinite sequence where every member is an empty set. In one sense this is a little peculiar that something said to be empty is infinite, in another sense it is consistent for the model that an empty Turing Machine tape keeps its defining characteristics. That is, it remains a single-ended Turing Machine tape, where any cell of the tape could be written with a symbol value, while the basic form of the tape will not change.</p>
<p>So we might imagine a tape machine, say called machine A, where, upon attempting to read an empty cell, the machine head instead returns a control symbol representing that the cell was empty. To accomplish this, the head would have to do some work; it would have to be able to detect emptiness, and then choose to return the empty symbol instead of a read value. This feature would fix the problem of not having any defined next-state behavior for an empty cell. Furthermore, suppose the inverse process is also special in that upon attempting to write the empty symbol, the machine takes action, emptying the cell out. This would facilitate an erase operation.</p>
- <RT·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·Counter·step counter="Code" id="Code·empty-cell_read">
+ <RT·name>Reading a cell that can be empty</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·empty-cell_read"></RT·Counter·snapshot>
<RT·code>
def read(c):
if is_empty(c):
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·read snapshot="Code·empty-cell_read" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·empty-cell_write">
+ <RT·name>Writing a cell, where writing the empty symbol erases it</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·empty-cell_write"></RT·Counter·snapshot>
<RT·code>
def write(c ,x):
if not is_empty(c):
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·read snapshot="Code·empty-cell_write" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Now imagine machine B, where the concept of an empty cell is jettisoned, and what remains is the mere memory of emptiness, a symbol called <RT·code>empty</RT·code>. Then using the language of mathematics, the mathematician defines an initial empty tape as:</p>
- <RT·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·Counter·step counter="Equation" id="Equation·empty-tape_with_empty-symbol">
+ <RT·name>An empty tape written with the empty symbol</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·empty-tape_with_empty-symbol" key="counter count step"></RT·Counter·read>
</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>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>
+ <RT·Counter·step counter="List" id="List·unspecified_causes">
+ <RT·name>Reasons a memory location can hold an unspecified value</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·unspecified_causes" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>An example of effectively unspecified data would be a program that reverses a string without looking at the values being reversed. A string reverse function need not inspect the value of the string; it only needs to recognize the structural boundaries established by the writing protocol. Yet the conventional Turing Machine is incapable of doing this, and worse, as we saw, there is an explosion in the number of states for the reverse string controller against word length.</p>
<RT·name>The modifications</RT·name>
<p>The specific architectural modifications are as follows:</p>
- <RT·Counter·step counter="RT·List·counter" id="List·Realizable_modifications">
- <RT·Counter·snapshot counter="RT·List·counter" snapshot="List·Realizable_modifications"></RT·Counter·snapshot>
+ <RT·Counter·step counter="List" id="List·Realizable_modifications">
+ <RT·name>The architectural modifications that distinguish the Realizable Machine</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·Realizable_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>
</ol>
</li>
</ol>
- List <RT·Counter·read snapshot="List·Realizable_modifications"></RT·Counter·read>. <RT·name>The architectural modifications that distinguish the Realizable Machine</RT·name>
+ <RT·Counter·read snapshot="List·Realizable_modifications" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Here the subscript <RT·math>i</RT·math> is a device used to emphasize that <RT·math>q_i</RT·math> and <RT·math>q_{i+1}</RT·math> can be any members of the total set of states, <RT·math>Q</RT·math>. State <RT·math>q_0</RT·math> refers specifically to the initial state. Also note, later the spartan <RT·math>q</RT·math> will be used to denote the contents of the <RT·code>q register</RT·code>, the current state register.</p>
<p>The Hopcroft and Ullman machine definition specified a next-state function, <RT·math>δ</RT·math>. Here we instead use next-state tables that cascade, and as tables are containers, we denote these using a capital letter as <RT·math>Δ_0</RT·math>, <RT·math>Δ_1</RT·math>, <RT·math>Δ_2</RT·math>, and <RT·math>Δ_3</RT·math>.</p>
<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>
+ <RT·Counter·step counter="List" id="List·transition_layers">
+ <RT·name>The four next-state transition layers, in evaluation order</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·transition_layers" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Programmers will typically use the Global Default arc, <RT·math>Δ_3</RT·math>, to take the machine to an error state when they have mistakenly left the next-state transition undefined. However, it is conceivable for some machines that if no other next-state is defined, there is a single logical state that should be visited, and this condition is not an error. If no Global Default arc is specified, and no next-state is found, the machine hangs.</p>
<RT·section id="Section·Realizable_computation_theoretic·Realizable_Machine_fixed_part">
<RT·name>The Realizable Machine fixed part</RT·name>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_fixed-part">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_fixed-part"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_fixed-part">
+ <RT·name>MF, the fixed part of the Realizable Machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_fixed-part"></RT·Counter·snapshot>
<RT·math>
\mathit{MF} = (\mathit{QF}, \mathit{ΣF}, \mathit{AF})
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_fixed-part"></RT·Counter·read> <RT·name>MF, the fixed part of the Realizable Machine</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_fixed-part" key="counter count step"></RT·Counter·read>
</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·Realizable_fixed-states">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_fixed-states"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_fixed-states">
+ <RT·name>QF, the set of predefined states</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_fixed-states"></RT·Counter·snapshot>
<RT·math>
\mathit{QF} = \{\mathit{QF}{·}\mathtt{initial}\}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_fixed-states"></RT·Counter·read> <RT·name>QF, the set of predefined states</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_fixed-states" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Realizable_fixed-instructions">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_fixed-instructions"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_fixed-instructions">
+ <RT·name>AF, the set of predefined instructions</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_fixed-instructions"></RT·Counter·snapshot>
<RT·math>
\begin{aligned}
\mathit{AF} = \{& \\
\}
\end{aligned}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_fixed-instructions"></RT·Counter·read> <RT·name>AF, the set of predefined instructions</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_fixed-instructions" key="counter count step"></RT·Counter·read>
</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·Realizable_fixed-symbols">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_fixed-symbols"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_fixed-symbols">
+ <RT·name>ΣF, the set of predefined symbols</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_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·Realizable_fixed-symbols"></RT·Counter·read> <RT·name>ΣF, the set of predefined symbols</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_fixed-symbols" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
<RT·section id="Section·Realizable_computation_theoretic·Machine_variables">
<RT·name>Machine variables</RT·name>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_machine-variables">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_machine-variables"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_machine-variables">
+ <RT·name>MV, the machine variables</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_machine-variables"></RT·Counter·snapshot>
<RT·math>
\mathit{MV} = (q, s, d)
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_machine-variables"></RT·Counter·read> <RT·name>MV, the machine variables</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_machine-variables" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p><RT·code>q</RT·code>: is the current state of the machine.</p>
<RT·section id="Section·Realizable_computation_theoretic·Programmable_part">
<RT·name>Programmable part</RT·name>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_programmable-part">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_programmable-part"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_programmable-part">
+ <RT·name>MP, the programmable part of the Realizable Machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_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·Realizable_programmable-part"></RT·Counter·read> <RT·name>MP, the programmable part of the Realizable Machine</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_programmable-part" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>A set of programmed <em>state</em> symbols:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_programmed-states">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_programmed-states"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_programmed-states">
+ <RT·name>QP, the set of programmed state symbols</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_programmed-states"></RT·Counter·snapshot>
<RT·math>
\mathit{QP}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_programmed-states"></RT·Counter·read> <RT·name>QP, the set of programmed state symbols</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_programmed-states" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>A set of programmed data symbols:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_programmed-symbols">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_programmed-symbols"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_programmed-symbols">
+ <RT·name>ΣP, the set of programmed data symbols</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_programmed-symbols"></RT·Counter·snapshot>
<RT·math>
\mathit{ΣP}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_programmed-symbols"></RT·Counter·read> <RT·name>ΣP, the set of programmed data symbols</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_programmed-symbols" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>The programmed instructions. A set of pairs of the form:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_programmed-instructions">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_programmed-instructions"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_programmed-instructions">
+ <RT·name>ΛP, the programmed instructions, as state and action pairs</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_programmed-instructions"></RT·Counter·snapshot>
<RT·math>
\mathit{ΛP} = \{ \langle q_i, a \rangle, \dots \}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_programmed-instructions"></RT·Counter·read> <RT·name>ΛP, the programmed instructions, as state and action pairs</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_programmed-instructions" key="counter count step"></RT·Counter·read>
</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>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·Realizable_conditional-transitions">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_conditional-transitions"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_conditional-transitions">
+ <RT·name>Δ₀, the conditional transition table</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_conditional-transitions"></RT·Counter·snapshot>
<RT·math>
Δ_0 = \{ \langle q_i, σ, q_{i+1} \rangle, \dots \}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_conditional-transitions"></RT·Counter·read> <RT·name>Δ₀, the conditional transition table</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_conditional-transitions" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>Here <RT·math>q_i</RT·math> and <RT·math>q_{i+1}</RT·math> are two states from the total set of <RT·math>Q</RT·math>. They need not be distinct. While the machine is running, state <RT·math>q_i</RT·math> is to be matched against the contents of the <RT·code>q register</RT·code>, the current state. Symbol <RT·math>σ</RT·math> is a member of the total set <RT·math>Σ</RT·math> and is to be matched against the contents of the <RT·code>s register</RT·code>, the machine status. When <RT·math>q_i</RT·math> matches the current state and <RT·math>σ</RT·math> matches the current status, then <RT·math>q_{i+1}</RT·math> becomes the next-state.</p>
<p>The state default transition table. A set of state transition pairs; each pair is of the form:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_state-default-transitions">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_state-default-transitions"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_state-default-transitions">
+ <RT·name>Δ₁, the state default transition table</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_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·Realizable_state-default-transitions"></RT·Counter·read> <RT·name>Δ₁, the state default transition table</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_state-default-transitions" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>where <RT·math>q_i</RT·math> is matched to the current state, and upon a match <RT·math>q_{i+1}</RT·math> will be taken as the next-state.</p>
<p>The status default transition table. A set of state transition pairs; each pair is of the form:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_status-default-transitions">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_status-default-transitions"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_status-default-transitions">
+ <RT·name>Δ₂, the status default transition table</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_status-default-transitions"></RT·Counter·snapshot>
<RT·math>
Δ_2 = \{ \langle σ, q_{i+1} \rangle, \dots \}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_status-default-transitions"></RT·Counter·read> <RT·name>Δ₂, the status default transition table</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_status-default-transitions" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>where <RT·math>σ</RT·math> matches the symbol in <RT·code>s register</RT·code>, and upon a match <RT·math>q_{i+1}</RT·math> will be taken as the next-state.</p>
<p>The global default next-state:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_global-default-transition">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_global-default-transition"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_global-default-transition">
+ <RT·name>Δ₃, the global default next-state</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_global-default-transition"></RT·Counter·snapshot>
<RT·math>
Δ_3 = q_{i+1}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_global-default-transition"></RT·Counter·read> <RT·name>Δ₃, the global default next-state</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_global-default-transition" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>This is the transition of last resort. It is unconditional; the next-state becomes <RT·math>q_{i+1}</RT·math>.</p>
<p>A set of programmer-defined halting states:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_halt-states">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_halt-states"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_halt-states">
+ <RT·name>HP, the set of programmed halting states</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_halt-states"></RT·Counter·snapshot>
<RT·math>
\mathit{HP}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_halt-states"></RT·Counter·read> <RT·name>HP, the set of programmed halting states</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_halt-states" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<RT·section id="Section·Realizable_computation_theoretic·Realizable_Machine_definition_in_total">
<RT·name>The Realizable Machine definition in total</RT·name>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_machine_definition">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_machine_definition"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_machine_definition">
+ <RT·name>The Realizable Machine in total</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_machine_definition"></RT·Counter·snapshot>
<RT·math>
M = (q, s, d, Q, Σ, A, Λ, Δ, H)
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_machine_definition"></RT·Counter·read> <RT·name>The Realizable Machine in total</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_machine_definition" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Realizable_state-set">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_state-set"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_state-set">
+ <RT·name>Q, the complete state set, fixed united with programmed</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_state-set"></RT·Counter·snapshot>
<RT·math>
Q = \mathit{QF} \cup \mathit{QP}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_state-set"></RT·Counter·read> <RT·name>Q, the complete state set, fixed united with programmed</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_state-set" key="counter count step"></RT·Counter·read>
</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·Realizable_symbol-set">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_symbol-set"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_symbol-set">
+ <RT·name>Σ, the complete symbol set, fixed united with programmed</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_symbol-set"></RT·Counter·snapshot>
<RT·math>
Σ = \mathit{ΣF} \cup \mathit{ΣP}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_symbol-set"></RT·Counter·read> <RT·name>Σ, the complete symbol set, fixed united with programmed</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_symbol-set" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>All members of the set of available instructions are fixed:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_instruction-set">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_instruction-set"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_instruction-set">
+ <RT·name>A, the instruction set, entirely fixed</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_instruction-set"></RT·Counter·snapshot>
<RT·math>
A = \mathit{AF}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_instruction-set"></RT·Counter·read> <RT·name>A, the instruction set, entirely fixed</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_instruction-set" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>The table of state-instruction pairs is strictly programmed.</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_instruction-table">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_instruction-table"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_instruction-table">
+ <RT·name>Λ, the instruction table, entirely programmed</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_instruction-table"></RT·Counter·snapshot>
<RT·math>
Λ = \mathit{ΛP}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_instruction-table"></RT·Counter·read> <RT·name>Λ, the instruction table, entirely programmed</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_instruction-table" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>The ordered sequence of next-state transition rules:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable_transition-sequence">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_transition-sequence"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_transition-sequence">
+ <RT·name>Δ, the transition rules as an ordered sequence</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_transition-sequence"></RT·Counter·snapshot>
<RT·math>
Δ = [Δ_0 \mid Δ_1 \mid Δ_2 \mid Δ_3]
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_transition-sequence"></RT·Counter·read> <RT·name>Δ, the transition rules as an ordered sequence</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_transition-sequence" key="counter count step"></RT·Counter·read>
</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·Realizable_halt-set">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable_halt-set"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable_halt-set">
+ <RT·name>H, the halt state set, entirely programmed</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable_halt-set"></RT·Counter·snapshot>
<RT·math>
H = \mathit{HP}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable_halt-set"></RT·Counter·read> <RT·name>H, the halt state set, entirely programmed</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable_halt-set" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<RT·section id="Section·Realizable_computation_theoretic·Computation_theoretic_Realizable_Machine_executor·Initialization_stage">
<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>
+ <RT·Counter·step counter="List" id="List·initialization_values">
+ <RT·name>The initial values given to the machine variables</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·initialization_values" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<RT·section id="Section·Realizable_computation_theoretic·Computation_theoretic_Realizable_Machine_executor·Programmed_control_stage·Phase_1">
<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>
+ <RT·Counter·step counter="List" id="List·phase-1_steps">
+ <RT·name>The two steps of instruction issue and execution</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·phase-1_steps" key="counter count step"></RT·Counter·read>
</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>Because the Realizable 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·Realizable-reverse_controller">
- <RT·Counter·snapshot counter="RT·Code·counter" snapshot="Code·Realizable-reverse_controller"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Code" id="Code·Realizable-reverse_controller">
+ <RT·name>The Realizable Machine string reverse controller</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·Realizable-reverse_controller"></RT·Counter·snapshot>
<RT·code>
# Realizable Machine String Reverse
# Domains:
δ:
Q·Done
</RT·code>
- Code <RT·Counter·read snapshot="Code·Realizable-reverse_controller"></RT·Counter·read>. <RT·name>The Realizable Machine string reverse controller</RT·name>
+ <RT·Counter·read snapshot="Code·Realizable-reverse_controller" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
- <RT·Counter·step counter="RT·Figure·counter" id="Figure·Realizable_reverse-machine">
- <RT·Counter·snapshot counter="RT·Figure·counter" snapshot="Figure·Realizable_reverse-machine"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Figure" id="Figure·Realizable_reverse-machine">
+ <RT·name>The Realizable Machine that reverses a binary string</RT·name>
+ <RT·Counter·snapshot counter="Figure" snapshot="Figure·Realizable_reverse-machine"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<figure>
<img src="realizable_reverse.png" class="RT·diagram" alt="RTM reverse machine">
</figure>
- Figure <RT·Counter·read snapshot="Figure·Realizable_reverse-machine"></RT·Counter·read>. <RT·name>The Realizable Machine that reverses a binary string</RT·name>
+ <RT·Counter·read snapshot="Figure·Realizable_reverse-machine" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<p>The form of this diagram shows a lead-in, a long loop, and a tail leading to done. This is suggestive of code followed by a while loop that breaks out, with further code completing the program.</p>
- <RT·Counter·step counter="RT·Code·counter" id="Code·Realizable-reverse_in_C">
- <RT·Counter·snapshot counter="RT·Code·counter" snapshot="Code·Realizable-reverse_in_C"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Code" id="Code·Realizable-reverse_in_C">
+ <RT·name>The RT reverse controller written as C</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·Realizable-reverse_in_C"></RT·Counter·snapshot>
<RT·code>
void Realizable·reverse_string() {
// Initialization: Scan to EOM and setup the EOR boundary
return;
}
</RT·code>
- Code <RT·Counter·read snapshot="Code·Realizable-reverse_in_C"></RT·Counter·read>. <RT·name>The RT reverse controller written as C</RT·name>
+ <RT·Counter·read snapshot="Code·Realizable-reverse_in_C" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>The total number of steps for reversing an <RT·math>n</RT·math> symbol string using the Realizable Machine:</p>
- <RT·Counter·step counter="RT·Equation·counter" id="Equation·Realizable-reverse_step-count">
- <RT·Counter·snapshot counter="RT·Equation·counter" snapshot="Equation·Realizable-reverse_step-count"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Equation" id="Equation·Realizable-reverse_step-count">
+ <RT·name>Steps taken by the Realizable reverse machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·Realizable-reverse_step-count"></RT·Counter·snapshot>
<RT·math>
\text{steps} =
\begin{cases}
4.5n^2 + 11.5n + 5 & \text{if } n \ge 1
\end{cases}
</RT·math>
- eq: <RT·Counter·read snapshot="Equation·Realizable-reverse_step-count"></RT·Counter·read> <RT·name>Steps taken by the Realizable reverse machine</RT·name>
+ <RT·Counter·read snapshot="Equation·Realizable-reverse_step-count" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Code" id="Code·two-headed-reverse_controller">
+ <RT·name>The two-headed string reverse controller</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·two-headed-reverse_controller"></RT·Counter·snapshot>
<RT·code>
# Realizable Two-Head String Reverse
# input: (σ ∈ Σ)* EOM (starting on the leftmost cell)
δ:
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·read snapshot="Code·two-headed-reverse_controller" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
- <RT·Counter·step counter="RT·Figure·counter" id="Figure·Realizable_two-headed_reverse-machine">
- <RT·Counter·snapshot counter="RT·Figure·counter" snapshot="Figure·Realizable_two-headed_reverse-machine"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Figure" id="Figure·Realizable_two-headed_reverse-machine">
+ <RT·name>A two-headed Realizable Machine that reverses a binary string</RT·name>
+ <RT·Counter·snapshot counter="Figure" snapshot="Figure·Realizable_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·Realizable_two-headed_reverse-machine"></RT·Counter·read>. <RT·name>A two-headed Realizable Machine that reverses a binary string</RT·name>
+ <RT·Counter·read snapshot="Figure·Realizable_two-headed_reverse-machine" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<p>The number of states has dropped from 24 to 18, while the speed increase is dramatic, with the former quadratic performance becoming linear performance. The total number of steps for reversing an <RT·math>n</RT·math> symbol string using a two-head 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·Counter·step counter="Equation" id="Equation·two-headed-reverse_step-count">
+ <RT·name>Steps taken by the two-headed Realizable reverse machine</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·two-headed-reverse_step-count"></RT·Counter·snapshot>
<RT·math>
\text{steps} =
\begin{cases}
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 Realizable reverse machine</RT·name>
+ <RT·Counter·read snapshot="Equation·two-headed-reverse_step-count" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·two-headed-reverse_in_C">
+ <RT·name>The two-headed reverse controller written as C</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·two-headed-reverse_in_C"></RT·Counter·snapshot>
<RT·code>
void Realizable·reverse_string_2_head() {
// Phase 1: Both heads scan right to the EOM pivot
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·read snapshot="Code·two-headed-reverse_in_C" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>This machine has a single tape with two heads marking two separate context areas. Because the areas do not overlap, this situation is indistinguishable from the case of the machine having two separate tapes, each with its own head. Hartmanis and Stearns established the original proof that simulating a Turing Machine with multiple tapes, each with its own head, on a single-tape, single-head machine incurs a quadratic time penalty <RT·endnote>J. Hartmanis and R. E. Stearns, "On the computational complexity of algorithms," <em>Transactions of the American Mathematical Society</em> 117 (1965): 285-306.</RT·endnote>. Hopcroft and Ullman formalize this relationship in their text <RT·endnote>John E. Hopcroft and Jeffrey D. Ullman, <em>Introduction to Automata Theory, Languages, and Computation</em> (Reading: Addison-Wesley, 1979), 292.</RT·endnote>. This explains why in this example of a string reverse machine, when the second head was added to eliminate the head shuttling, the quadratic term disappeared. Not all quadratic terms in step-count formulas are due to shuttling, but this one happens to be such a case.</p>
<RT·section id="Section·Realizable_machine_design">
<RT·name>The Realizable 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>
+ <RT·Counter·step counter="Figure" id="Figure·Turing-Machine">
+ <RT·name>A Turing Machine</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·Turing-Machine" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
- <p>The prior chapter on the computation theoretic Realizable Machine, chapter <RT·Counter·read snapshot="Section·Realizable_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 Realizable Machine, <RT·Counter·read snapshot="Section·Realizable_computation_theoretic" key="counter count"></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·Peano_Number·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 <RT·Counter·read snapshot="Section·Number·Hindu-Arabic_representation" key="counter count"></RT·Counter·read>, which analyses the increment operation. Its working footprint, however, will be logarithmic in space complexity, because that is how fast an Hindu-Arabic representation grows with a count.</p>
<p>If a program executed at the speed of a human operator, the operator would likely abandon the process before it finished. This highlights a necessary attribute of good software: <RT·term>utility</RT·term>. It also exposes a limitation of pure computation theory, which abstracts away physical time. Nevertheless, formal analysis remains a necessity. Consider an exponential-time program processing worst-case operands: its execution time explodes relative to input length, rapidly exceeding the age of the universe. In such extremes, empirical wall-clock measurement becomes superfluous. Computation theory classifies a program’s behavior, which establishes structural implications for wall-clock time, rather than calculating absolute durations.</p>
<p>An <RT·code>HU</RT·code> contains a head and a local controller. The local controller supports these instructions:</p>
- <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>
+ <RT·Counter·step counter="List" id="List·HU_instructions">
+ <RT·name>The instructions supported by the head unit controller</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·HU_instructions" key="counter count step"></RT·Counter·read>
</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·Realizable_machine_design·Tape_transport_unit"></RT·Counter·read>.) As established in section <RT·Counter·read snapshot="Section·Binding·Turing_Machine_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, <RT·Counter·read snapshot="Section·Realizable_machine_design·Tape_transport_unit" key="counter count"></RT·Counter·read>.) As established in <RT·Counter·read snapshot="Section·Binding·Turing_Machine_tape_cell" key="counter count"></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>
+ <RT·Counter·step counter="List" id="List·cell_types">
+ <RT·name>The cell types a head unit can report</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·cell_types" key="counter count step"></RT·Counter·read>
</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>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>
+ <RT·Counter·step counter="List" id="List·TTU_components">
+ <RT·name>The components of the tape transport unit controller</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·TTU_components" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="List" id="List·TTU_instructions">
+ <RT·name>The instructions issued to a selected tape transport unit</RT·name>
+ <RT·Counter·snapshot counter="List" 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>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·read snapshot="List·TTU_instructions" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>The <em>head</em> argument multiplexes the instruction to the specified head. If the <RT·code>TTU</RT·code> has one head, the head argument is optional. The last two instructions cause the tape to be moved such that, relatively, the selected head moves left or right by one cell.</p>
<p>The controller is programmed via patch panels. The panels would look something like what is shown in the following ASCII art blocks. Note that <RT·code>●</RT·code> indicates an illuminated indicator light, whereas <RT·code>○</RT·code> is not illuminated. <RT·code>[/]</RT·code> represents an open toggle switch, while <RT·code>[—]</RT·code> is a closed one. <RT·code>{*}</RT·code> is a pushed button, while <RT·code>{ }</RT·code> is a button that is not pushed. <RT·code>( )</RT·code> represents a hole for a banana plug. Each patch cord has a banana plug on each end. Plugging a patch cord between separate panels will void the warranty ;-).</p>
- <RT·Counter·step counter="RT·Figure·counter" id="Figure·control-panel">
- <RT·Counter·snapshot counter="RT·Figure·counter" snapshot="Figure·control-panel"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Figure" id="Figure·control-panel">
+ <RT·name>The control panel, carrying power, error, reset and single-step</RT·name>
+ <RT·Counter·snapshot counter="Figure" snapshot="Figure·control-panel"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<pre>
[ CONTROL PANEL ]
| 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·read snapshot="Figure·control-panel" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="Figure" id="Figure·state-transition-table_panel">
+ <RT·name>The state transition panel, with state indicators and halt switches</RT·name>
+ <RT·Counter·snapshot counter="Figure" snapshot="Figure·state-transition-table_panel"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<pre>
[ State Transition Table ]
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·read snapshot="Figure·state-transition-table_panel" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="Figure" id="Figure·instruction_panel">
+ <RT·name>The instruction panel, one patch row per instruction and one column per state</RT·name>
+ <RT·Counter·snapshot counter="Figure" snapshot="Figure·instruction_panel"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<pre>
[ Instruction ]
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·read snapshot="Figure·instruction_panel" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="Figure" id="Figure·sigma-select_panel">
+ <RT·name>The sigma select panel, choosing the symbol written by write(σ)</RT·name>
+ <RT·Counter·snapshot counter="Figure" snapshot="Figure·sigma-select_panel"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<pre>
[ Sigma Select for write('σ') ]
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·read snapshot="Figure·sigma-select_panel" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>The top panel has two toggle switches. One turns the machine on, and the other selects run or single-step mode. Immediately to the right of the two toggles are indicator lights. To the right of the indicator lights are two push buttons. One is for reset, which sends the machine back to state <RT·math>q_0</RT·math>, and the other is for stepping the machine when it is in single-step mode. This panel also has an error indicator light which will illuminate if no next-state is specified for a state transition, and thus the machine is hung, or if a head walks off the end of a tape.</p>
<RT·section id="Section·Realizable_machine_design·Machine_block_diagram">
<RT·name>The machine block diagram</RT·name>
- <RT·Counter·step counter="RT·Figure·counter" id="Figure·Realizable_block-diagram">
- <RT·Counter·snapshot counter="RT·Figure·counter" snapshot="Figure·Realizable_block-diagram"></RT·Counter·snapshot>
+ <RT·Counter·step counter="Figure" id="Figure·Realizable_block-diagram">
+ <RT·name>The Realizable Machine block diagram</RT·name>
+ <RT·Counter·snapshot counter="Figure" snapshot="Figure·Realizable_block-diagram"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<figure>
<img src="Realizable_Machine.svg" class="RT·diagram" alt="Figure: RT block diagram">
</figure>
- Figure <RT·Counter·read snapshot="Figure·Realizable_block-diagram"></RT·Counter·read>. <RT·name>The Realizable Machine block diagram</RT·name>
+ <RT·Counter·read snapshot="Figure·Realizable_block-diagram" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
- <p>This section describes the Realizable Machine organization. Figure <RT·Counter·read snapshot="Figure·Realizable_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>This section describes the Realizable Machine organization. <RT·Counter·read snapshot="Figure·Realizable_block-diagram" key="counter count"></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>
+ <RT·Counter·step counter="List" id="List·block-diagram_components">
+ <RT·name>The units and panels the machine is assembled from</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·block-diagram_components"></RT·Counter·snapshot>
<ol>
<li>Control Panel
<ol>
<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·read snapshot="List·block-diagram_components" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
- <p>As described in chapter <RT·Counter·read snapshot="Section·Realizable_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 <RT·Counter·read snapshot="Section·Realizable_computation_theoretic" key="counter count"></RT·Counter·read>, which is being used as the architectural template, the executor guides the machine through the initialization, programmed control, and halting stages of execution. The Executor contains the power, reset, and clock logic. It has two modes of execution: the run mode in which the clock runs free, and the single-step mode, in which clock pulses are sent with the push of a button. It also holds the halt state switch bank, and is ready to stop the clock when a halt state is reached. When in the programmed control stage, most of the active control comes from the <RT·code>CPCU</RT·code>.</p>
<p>The <RT·code>CPCU</RT·code> contains the current state register <RT·code>q</RT·code>, the <RT·code>Next-State Table</RT·code>, and the <RT·code>Instruction Table</RT·code>.</p>
</RT·section>
</RT·section>
-
- <!--------------------------------------------------------------------------------->
- <RT·section id="Section·The_reversal">
- <RT·name>The reversal</RT·name>
- <!--
- The bridge. The descent is finished: dialectic, machine, design.
- From here the book ascends, and the route up is not the route down,
- because the descent followed history and the ascent follows
- construction.
-
- Owes the reader:
- - a statement that the transforms run in both directions
- - the ladder named rung by rung: symbol, relation, cell, tape,
- universality, area, number, address, metric, analysis
- - the reason the ascent cannot retrace the descent
- - one sentence on what would count as failure
- -->
- </RT·section>
-
- <!--------------------------------------------------------------------------------->
+<!--------------------------------------------------------------------------------->
<RT·section id="Section·Symbol">
<RT·name>Symbol</RT·name>
- <RT·section id="Section·Symbol·Natural_Symbol">
- <RT·name>Natural Symbol</RT·name>
-
- <p>The design for the Realizable Machine was given in chapter <RT·Counter·read snapshot="Section·Realizable_machine_design"></RT·Counter·read>. On that machine there was a column of patch panel holes said to be symbols for gating next state transitions. The presence of a symbol could be ascertained by its effect on the machine by observing the indicator lights, or more directly if the observer is allowed and facilitated to probe the machine with a voltage meter. Alternatively, the symbols could be enumerated in the abstract, as the maker of the control panel did, when he wrote symbol names next to each of the symbol holes. These are all natural actions. When there are merely two such symbols the machine is said to be a "binary" machine.
- </p>
- </RT·section>
-
<RT·section id="Section·Symbol·Conventionally_defined_symbol">
<RT·name>Conventionally defined symbol</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. (Here we speak at the metamathematical level, where the objects being compared are the symbol instances themselves, rather than anything that might be <RT·term>bound</RT·term> to the symbol. <RT·term>binding</RT·term> is discussed in section <RT·Counter·read snapshot="Section·Binding"></RT·Counter·read>.)
+ 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. (Here we speak at the metamathematical level, where the objects being compared are the symbol instances themselves, rather than anything that might be <RT·term>bound</RT·term> to the symbol. <RT·term>binding</RT·term> is discussed in <RT·Counter·read snapshot="Section·Binding" key="counter count"></RT·Counter·read>.)
</p>
<p>
</p>
</RT·section>
+ <RT·section id="Section·Symbol·Natural_Symbol">
+ <RT·name>Natural Symbol</RT·name>
+
+ <p>The design for the Realizable Machine was given in <RT·Counter·read snapshot="Section·Realizable_machine_design" key="counter count"></RT·Counter·read>. On that machine there was a column of patch panel holes said to be symbols for gating next state transitions. The presence of a symbol could be ascertained by its effect on the machine by observing the indicator lights, or more directly if the observer is allowed and facilitated to probe the machine with a voltage meter. Alternatively, the symbols could be enumerated in the abstract, as the maker of the control panel did, when he wrote symbol names next to each of the symbol holes. These are all natural actions. When there are merely two such symbols the machine is said to be a "binary" machine.
+ </p>
+ </RT·section>
+
<RT·section id="Section·Symbol·In_computing">
<RT·name>Naturally derived Math Symbol</RT·name>
<p>
- Because the Realizable Machine runs programs, it is possible to extend the notion of the Natural Symbol to that of the symbol of mathematics. Accordingly, the symbol of mathematics is defined as a program that produces symbol instances. A new symbol instance of the given symbol is then made, say, by calling a symbol factory’s <RT·code>make</RT·code> function. All of the symbol instances made by the factory constitute the members of corresponding ‘made by’ equivalence class.
+ Because a program held on a tape can be called upon while the machine runs, it is possible to extend the notion of the Natural Symbol to that of the symbol of mathematics. A patched machine will not serve here: each factory would need its own patching, and re-patching is not something that happens while the machine is running, whereas mathematics asks for new symbol types on demand. Accordingly, the symbol of mathematics is defined as a program that produces symbol instances. A new symbol instance of the given symbol is then made, say, by calling a symbol factory’s <RT·code>make</RT·code> function. All of the symbol instances made by the factory constitute the members of corresponding ‘made by’ equivalence class.
</p>
<p>
</p>
<p>
- At the time of this writing many machines use 64 bit words. This is equivalent to 8 ASCII characters, while the average size of an identifier is about 5 characters. Hence the approach of using a string as a symbol might not be as inefficient as it seems to be at first. Using strings has advantages. Symbol instances can carry semantic clues for the programmer. There is no hazard of conflating the string instance with the name, as they are the same. Also, a string instance will have integrity across contexts, such as between invocations or when passed between processes (note section <RT·Counter·read snapshot="Section·Symbol·In_computing·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.
+ 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 <RT·Counter·read snapshot="Section·Symbol·In_computing·Distinctness_across_contexts" key="counter count"></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>
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·Counter·step counter="Code" id="Code·symbol-factory_enum">
+ <RT·name>A static symbol factory made with a C enum</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·symbol-factory_enum"></RT·Counter·snapshot>
<RT·code>
/* The enum definition acts as the factory. */
typedef enum {
/* 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·read snapshot="Code·symbol-factory_enum" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·symbol-factory_dynamic">
+ <RT·name>A dynamic symbol factory whose instances are string pointers</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·symbol-factory_dynamic"></RT·Counter·snapshot>
<RT·code>
#include <string.h>
#include <stdlib.h>
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·read snapshot="Code·symbol-factory_dynamic" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
</RT·section>
+ <!--------------------------------------------------------------------------------->
+ <RT·section id="Section·Stored_program">
+ <RT·name>The stored program</RT·name>
+
+ <p>It is not a different machine. The fixed part is the fixed part of <RT·Counter·read snapshot="Section·Realizable_machine_design" key="counter count"></RT·Counter·read>, the tape transport unit is the same unit, and the panel is the same panel. What differs is which chords are in it. Patch the panel to reverse a string and the machine reverses strings. Patch it with an interpreter and the machine runs whatever program is handed to it on a tape. No component is added and none is removed.</p>
+
+ <p>This deserves emphasis, because the word <RT·term>universal</RT·term> attaches to a machine by long habit and belongs to a program. A Realizable Machine is not universal or non-universal. A patch program is one or the other, and the machine is whatever its panel currently says it is.</p>
+
+ <RT·section id="Section·Stored_program·What_changed">
+ <RT·name>What actually changed</RT·name>
+
+ <p>Placing chords on a panel has always been called programming the machine, and a program was the list saying where the chords go. There is nothing loose in that usage. An operator was handed a program and a panel, and he wired what he was told to wire.</p>
+
+ <p>So the innovation was never the program. It was the <RT·term>stored program</RT·term>. The list stopped being a little book handed to a person and became symbols written on a tape handed to a machine. Everything that follows in this chapter is a consequence of moving that list from paper into the machine’s own medium.</p>
+
+ <p>The arrangement did not vanish when patch panels did. Machines with writable control stores hold their microcode in memory, and the technician who loads it is placing the chords. The boundary between the fixed part and the patched part is itself movable, and where a given manufacturer draws it is a commercial decision rather than a mathematical one.</p>
+
+ <p>One consequence is worth stating before the constructions begin. There is not one interpreter but a family of them, any of which can be patched into the same panel, and all of which run the same programs to the same results. They are not therefore the same. They differ in what interpretation costs in steps and in tape, and the transform criteria of <RT·Counter·read snapshot="Section·Consequentiality·Consequential_transform" key="counter count"></RT·Counter·read> are the instrument for telling them apart. A treatment that identifies them because they compute the same functions has discarded the entire content of the comparison.</p>
+
+ </RT·section>
+
+ <RT·section id="Section·Stored_program·Kinds_of_control">
+ <RT·name>Where the control lives</RT·name>
+
+ <p>Three arrangements, and the reader has met two of them.</p>
+
+ <RT·Counter·step counter="List" id="List·control_locations">
+ <RT·name>Where the control lives</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·control_locations"></RT·Counter·snapshot>
+ <ol>
+ <li><strong>Built in.</strong> The control is part of the fixed part. It cannot be altered without altering the machine, and it is the same for every customer.</li>
+ <li><strong>Patched.</strong> The control is on the panel, set by the customer. Altering it means stopping the machine and moving chords. This is the machine of <RT·Counter·read snapshot="Section·Realizable_machine_design·Control_unit" key="counter count"></RT·Counter·read>.</li>
+ <li><strong>Interpreted.</strong> The panel holds an interpreter and the control being carried out is on a tape. Altering it means writing a tape, which the machine can do while running.</li>
+ </ol>
+ <RT·Counter·read snapshot="List·control_locations" key="counter count step"></RT·Counter·read>
+ </RT·Counter·step>
+
+ <p>Notice that the third is not a third place for control to sit in the machine. The tape holds marks. Whether those marks are a program is settled by the chords on the panel and by nothing on the tape itself. The same tape under a different interpreter is a different program, or is not a program at all. What a symbol is, and what a program is, are conferred in the same way and for the same reason.</p>
+
+ </RT·section>
+
+ <RT·section id="Section·Universal_Turing_Machine">
+ <RT·name>The Universal Turing Machine</RT·name>
+
+ <p>The Computer Theoretic model chapter provided symbolic definitions for the Turing Machine and the Realizable 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>
+
+ </RT·section>
+
+ <RT·section id="Section·Stored_program·Machine_interpretation">
+ <RT·name>Interpreting a machine</RT·name>
+
+ <p>The interpreter needs two tapes, and <RT·Counter·read snapshot="Section·Realizable_machine_design·Tape_transport_unit" key="counter count"></RT·Counter·read> already supplies more than one tape transport unit. One holds <RT·math>\mathit{MP}</RT·math>. The other is the tape the interpreted machine is working on, and it is a real tape under a real head, not a representation of one. Nothing has to be virtualized.</p>
+
+ <p>The interpreter’s own state is small and fixed: it holds the current state symbol of the interpreted machine, and nothing else that grows. It reads the symbol under the working head, searches the definition tape for the arc matching the pair of that symbol and the current state, issues the instruction that arc names to the working tape transport unit, writes the next state symbol into its own holding place, and repeats. When it reaches an arc naming a halt state, it halts.</p>
+
+ <p>This is a virtualization, and the machine being virtualized is virtualized entire, tape and all. It is the more primitive of the two forms treated in this chapter, in that the thing on the tape is the same kind of object as the thing doing the interpreting.</p>
+
+ </RT·section>
+
+ <RT·section id="Section·Stored_program·Virtualization_for_analysis">
+ <RT·name>Virtualization as the instrument of analysis</RT·name>
+
+ <p>The reason to build this is not that it computes anything a patched machine could not. It is that a virtualized machine can be watched.</p>
+
+ <p>A hardwired machine can be run, and running it is first-order analysis in the sense of <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis" key="counter count"></RT·Counter·read>. It answers what the machine did on this input. It does not answer whether the machine ever revisits a cell, how many steps it took, whether it halts, or what it would do on an input never supplied. To ask those, the machine must be held as an object and examined, and that is what putting <RT·math>\mathit{MP}</RT·math> on a tape achieves.</p>
+
+ <p>So the procedure is this. Take the machine to be studied. Write its programmable part on a tape. Patch the interpreter into the panel, and instrument the interpreter, not the machine under study. Count the steps by incrementing a counter in the interpreter’s loop. Detect a cell revisited by having the interpreter note the cells it visits. Test a property over a domain of inputs by having the interpreter run the machine once per input.</p>
+
+ <p>The machine under study is untouched throughout, which is the whole point. An analysis that requires modifying the subject is an analysis of a different subject. Here the subject is data and the instrumentation is in the observer, which is the arrangement a naturalist wants and rarely gets.</p>
+
+ <p>The orders of analysis then become a count of how many interpreters are stacked. An interpreter running a machine is the second order. An interpreter running an interpreter running a machine is the third, and the halting argument lives there.</p>
+
+ </RT·section>
+
+ <RT·section id="Section·Stored_program·From_states_to_instructions">
+ <RT·name>From a state controller to an instruction sequence</RT·name>
+
+ <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 two-headed Realizable reverse string example controller results in:</p>
+
+ <RT·Counter·step counter="Code" id="Code·two-headed-reverse_linearized">
+ <RT·name>The two-headed reverse controller as linear code with jumps</RT·name>
+ <RT·Counter·snapshot counter="Code" 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>
+ <RT·Counter·read snapshot="Code·two-headed-reverse_linearized" key="counter count step"></RT·Counter·read>
+ </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. <RT·Counter·read snapshot="Code·two-headed-reverse_linearized" key="counter count"></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="Code" id="Code·two-headed-reverse_with_branches">
+ <RT·name>The same controller using test, branch and jump instructions</RT·name>
+ <RT·Counter·snapshot counter="Code" 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>
+ <RT·Counter·read snapshot="Code·two-headed-reverse_with_branches" key="counter count step"></RT·Counter·read>
+ </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 Realizable Machine program invocation.</p>
+
+ </RT·section>
+
+ <RT·section id="Section·Stored_program·Comparison">
+ <RT·name>Which form, and why both</RT·name>
+
+ <p>The two forms are not rivals and neither subsumes the other, though either can host the other.</p>
+
+ <p>Machine interpretation is faithful. What is on the tape is a machine of the same kind as the one interpreting it, so a property proved of the representation is a property of the machine. This is what analysis requires, and it is why the more primitive form is the one the preceding sections needed.</p>
+
+ <p>Instruction interpretation is compact and fast. A sequence of instructions says in one cell what a transition table says in a row, and control that would have to be encoded as a state can be written as a branch. The price is that the object on the tape is no longer the same kind of thing as the machine, so a property of the program is not immediately a property of a machine, and getting from one to the other takes an argument.</p>
+
+ <p>An instruction-interpreting machine can run a machine interpreter, and a machine interpreter can interpret a machine whose panel holds an instruction interpreter. The stacking is unrestricted, and each layer costs what it costs.</p>
+
+ </RT·section>
+
+ <RT·section id="Section·Stored_program·Universality_discharged">
+ <RT·name>Universality by construction</RT·name>
+
+ <p><RT·Counter·read snapshot="Section·Three_conditions" key="counter count"></RT·Counter·read> set out that the Turing Machine fails the first condition, being unrealizable, and that some other machine must carry the thesis. The universality of the Turing Machine cannot therefore be borrowed, and a citation to the Church-Turing thesis will not serve, since that thesis speaks of what functions are computable and not of what can be built.</p>
+
+ <p>What has been exhibited here is a machine that can be built, holding a program that can be written, which runs any machine whose programmable part fits on its definition tape. The claim is discharged by construction. What remains is the cost of the construction, and cost is the subject the conventional treatment sets aside.</p>
+
+ </RT·section>
+
+ </RT·section>
+
+
+ <!--------------------------------------------------------------------------------->
+ <RT·section id="Section·The_reversal">
+ <RT·name>The reversal</RT·name>
+ <!--
+ The bridge. The descent is finished: dialectic, machine, design.
+ From here the book ascends, and the route up is not the route down,
+ because the descent followed history and the ascent follows
+ construction.
+
+ Owes the reader:
+ - a statement that the transforms run in both directions
+ - the ladder named rung by rung: symbol, relation, cell, tape,
+ universality, area, number, address, metric, analysis
+ - the reason the ascent cannot retrace the descent
+ - one sentence on what would count as failure
+ -->
+ </RT·section>
+
+
<!--------------------------------------------------------------------------------->
<RT·section id="Section·Binding">
<RT·name>Binding</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>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 <RT·neologism>Peano Number</RT·neologism>s, 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 <RT·neologism>Counting Number</RT·neologism>s, 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>
</RT·section>
- <!--------------------------------------------------------------------------------->
- <RT·section id="Section·Mathematical_Tape">
- <RT·name>Mathematical Tape</RT·name>
-
- <p>The Realizable Machine is a natural object. We observe its mechanisms, name its parts, and then find symbol representation for them so as to facilitate introspection. In short, we build a model.</p>
-
- <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>
-
- <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>
-
- <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>
-
- <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 id="Section·Universal_Turing_Machine">
- <RT·name>The Universal Turing Machine</RT·name>
-
- <p>The Computer Theoretic model chapter provided symbolic definitions for the Turing Machine and the Realizable 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 two-headed Realizable 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 Realizable Machine program invocation.</p>
-
- </RT·section>
-
-
- <!--------------------------------------------------------------------------------->
- <RT·section id="Section·Universal_Realizable_Machine">
- <RT·name>The Universal Realizable Machine</RT·name>
- <!--
- The largest hole in the current draft. Chapter 7 disqualifies the
- Turing Machine as unrealizable, and chapter 16 then rests the
- universality claim on it. The counterpart is missing.
-
- Owes the reader:
- - the encoding: a Realizable Machine held as symbols on a tape, which
- is the debt the symbolic tape and cell of chapters 14 and 15 were
- incurred to pay, and this section is where the reader learns why
- those definitions were built
- - the evaluator, exhibited rather than asserted
- - the stack, and where it lives
- - the cost of interpretation against the cost of direct execution
- - an explicit statement that "universal" is discharged by
- construction here and not by appeal to the Church-Turing thesis
- -->
- </RT·section>
<!--------------------------------------------------------------------------------->
<RT·section id="Section·Area_and_partitioning">
<RT·section id="Section·Area_and_partitioning·Head_partition">
<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>
+ <RT·Counter·step counter="List" id="List·head_partition">
+ <RT·name>The three areas of the head partition</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·head_partition" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>If the head is on the leftmost cell, there is no left side area.</p>
<RT·section id="Section·Area_and_partitioning·Leftmost_remaining_partition">
<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>
+ <RT·Counter·step counter="List" id="List·leftmost-remaining_partition">
+ <RT·name>The two areas of the leftmost and remaining partition</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·leftmost-remaining_partition" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
A nonempty tape, one with at least one cell holding an alphabet symbol, can be partitioned into the following areas:
</p>
- <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>
+ <RT·Counter·step counter="List" id="List·active-area_partition">
+ <RT·name>The three areas of the active area partition</RT·name>
+ <RT·Counter·snapshot counter="List" snapshot="List·active-area_partition"></RT·Counter·snapshot>
<ol>
<li>The left empty tail: if the leftmost cell of the tape is an alphabet cell, there is no left empty tail. Otherwise, it consists of the leftmost cell and the empty cells, if any, to the right of the leftmost cell, up to, but not including, the first alphabet cell.</li>
<li>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·read snapshot="List·active-area_partition" key="counter count step"></RT·Counter·read>
</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 <RT·neologism>Peano Number</RT·neologism>s 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.
+ 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 <RT·neologism>Counting Number</RT·neologism>s 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·name>The impossibility of recognizing an empty tape</RT·name>
<p>
+ <!-- REVISIT:zero The impossibility results in this section are the
+ machine-level evidence that emptiness is a status and not a value: a
+ machine cannot read emptiness off the tape, it can only be told. That
+ argument is wanted in the number chapter and is currently made only
+ here. Cross-reference once the derivation is written. -->
<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>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-of-rightmost</RT·code> symbol. Such a machine defines a virtual tape over an area.
+ </p>
+
+ </RT·section>
+
+
+ <!-- Formerly a top level chapter. An abstract tape is a tape realized in
+ mathematics rather than in metal, and therefore a third kind of virtual
+ tape, alongside the virtual cell and the virtual tape over an area.
+ Id retained so that any future reference resolves. -->
+ <RT·section id="Section·Mathematical_Tape">
+ <RT·name>Abstract tape</RT·name>
+
+ <p>The Realizable Machine is a natural object. We observe its mechanisms, name its parts, and then find symbol representation for them so as to facilitate introspection. In short, we build a model.</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.
+ 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>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>
+ 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>
- </RT·section>
+ <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>
+
+ <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>
+
+ <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 id="Section·Area_and_partitioning·Partitions_on_a_finite_virtual_tape">
<RT·name>Partitions on a finite virtual tape</RT·name>
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>
+ <RT·Counter·step counter="List" id="List·finite-virtual-tape_partitions">
+ <RT·name>The partitions of a finite virtual tape</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·finite-virtual-tape_partitions" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<RT·name>Iteration</RT·name>
<!--
The formally grounded iterator library promised in the Preface as
- this book's practical contribution. It should be named as such here.
+ this book’s practical contribution. It should be named as such here.
First edition: Stepping through the cells of a tape, TTCA 87.
-->
</RT·section>
<!-- First edition: Generators, TTCA 105; Recursive, TTCA 106. -->
</RT·section>
+ <RT·section id="Section·TTU_API·First_rest">
+ <RT·name>Initialization and the first-rest pattern</RT·name>
+ <!-- To be pulled from the first edition: Initialization and the first-rest
+ pattern, TTCA 118.
+
+ The pattern: a tape machine can only be created after there is a first item
+ to place in it, so code producing data for a tape has a separate first case
+ and recursive case. get-first creates the machine and hands it on;
+ get-rest extends it and creates nothing. In loop terms this is priming,
+ where the work before the loop is a variant of the work inside it.
+
+ Also from TTCA 119, and worth keeping, is the argument against hiding the
+ pattern behind a single get routine taking an empty machine flag. It cannot
+ create the caller’s machine, since the local is not the caller’s reference,
+ so it must return the machine and the caller must reassign on every call.
+ The flag encapsulates the pattern rather than removing it, and pays a
+ redundant test, a redundant return, and a redundant assignment for the
+ privilege.
+
+ Prerequisites, so the section can be read where it sits:
+ - the primitive interface, so that create and append are distinguishable
+ - a way to speak of a machine that does not yet exist, which is the
+ empty machine reference of the Emptiness section following
+ - continuations or an equivalent, since the first edition writes the
+ pattern with them
+
+ REVISIT:zero This section carries the machine-level argument for the zero
+ question. Creating a leftmost cell and appending to a leftmost cell are
+ different operations, distinguished by whether the active area has length
+ zero, and a length of zero is available only from a higher order analysis.
+ That is the derivation wanted in What a number is: the machine begins at
+ one, and zero is what analysis says about a machine that is not there yet.
+ -->
+ </RT·section>
+
<RT·section id="Section·TTU_API·Emptiness">
<RT·name>Signaling emptiness</RT·name>
<!--
First edition: Emptiness, TTCA 120, including the empty tape slot,
the empty machine reference, the padding cell, and the second order
machine.
+
+ REVISIT:zero The first edition already reaches the conclusion this book
+ now wants. Length of an area is one greater than the difference between the
+ least and greatest address, so a single cell has length one. Zero length is
+ then derived by analysis, as a higher order construct, and a zero length
+ area still has a location, serving as a locator for future growth or a
+ marker where the area used to be. And since no machine can decide whether a
+ tape is empty, emptiness has to be kept as an attribute at a higher order.
+ That is the status flag argument, made from the machine. Bring it across.
-->
</RT·section>
<RT·section id="Section·TTU_API·Lengthening_the_tape">
<RT·name>Lengthening the tape, and what it costs</RT·name>
<!--
- New material, not in the first edition. Minsky's "attach another
+ New material, not in the first edition. Minsky’s "attach another
unit of tape" is quoted in chapter 7 and left uncosted. Here it
acquires a price and an API call.
- which quantifications the machine settles and which it merely
verifies, stated in terms of what the apparatus does rather than by
naming a class of functions
- - Russell's R and the dotted R from section 9.1, revisited now that
+ - Russell’s R and the dotted R from section 9.1, revisited now that
the machinery is built
- an explicit statement that the scaffolding of chapter 3 is now
standing on its own
</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:
+ 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. <RT·Counter·read snapshot="Table·memory-tier_scaled-latency" key="counter count"></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>
+ <RT·Counter·step counter="Table" id="Table·memory-tier_scaled-latency">
+ <RT·name>Memory tier latency, scaled so that one clock tick lasts one day</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·memory-tier_scaled-latency"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<thead>
</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·read snapshot="Table·memory-tier_scaled-latency" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
</p>
<p>
- When discussing symbols we noted they could be <RT·neologism>Peano Number</RT·neologism>s, 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.
+ When discussing symbols we noted they could be <RT·neologism>Counting Number</RT·neologism>s, 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>
- <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>As we noted in <RT·Counter·read snapshot="Section·Area_and_partitioning" key="counter count"></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 <RT·neologism>Peano Number</RT·neologism>s, the address of the leftmost cell, and that of the rightmost cell. All <RT·neologism>Peano Number</RT·neologism>s 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><!-- REVISIT:zero TYPE COLLISION. This sentence calls an address a Counting
+ Number. Section Address assigns address zero to the leftmost cell, and a
+ Counting Number now begins at one, so an address is not a Counting Number
+ and the two are different kinds of quantity: a count and a position. That
+ distinction may be worth keeping rather than repairing, since a count of
+ one cell is 1 while the position of the first cell is 0, and conflating
+ them is the usual source of off-by-one error. Whatever is decided here
+ governs the lemma chain below. -->
+ With addresses we can now define an area with two addresses, two <RT·neologism>Counting Number</RT·neologism>s, the address of the leftmost cell, and that of the rightmost cell. All <RT·neologism>Counting Number</RT·neologism>s 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·section id="Section·Metrics·Cardinality_question">
- <RT·name>Is the cardinality of an open on the right area a <RT·neologism>Peano Number</RT·neologism>?</RT·name>
+ <RT·name>Is the cardinality of an open on the right area a <RT·neologism>Counting Number</RT·neologism>?</RT·name>
+ <!-- REVISIT:zero THE LEMMA CHAIN IS THE DANGER ZONE. Under the replacement
+ of Peano Number by Counting Number, this argument does not survive
+ unexamined:
+
+ Lemma 4 states that the address space of an open on the right area is
+ identical to the Counting Numbers. Addresses begin at zero and Counting
+ Numbers begin at one, so as written the lemma is false.
+
+ Lemma 2 states that cardinality is a Counting Number. This now holds
+ more naturally than before, since the cardinality of a one cell area is
+ one, and a count has no zero case at the first order.
+
+ Lemma 3 states that cardinality is not in the address space. If a count
+ and a position are different kinds of quantity, this may become true by
+ type rather than by the counting argument, which would either strengthen
+ the conclusion or trivialize it. Decide which.
+
+ The apparent contradiction and its resolution both hang on these, so work
+ the chain through before anything else in this chapter. -->
<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 id="Section·Metrics·Cardinality_question·How_cardinality_is_computed">
<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>
+ <RT·Counter·step counter="List" id="List·cardinality_procedure">
+ <RT·name>The three steps for computing the cardinality of an address space</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·cardinality_procedure" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<RT·section id="Section·Metrics·Cardinality_question·Lemma_1">
- <RT·name>Lemma 1, the A machine produces <RT·neologism>Peano Number</RT·neologism>s</RT·name>
+ <RT·name>Lemma 1, the A machine produces <RT·neologism>Counting Number</RT·neologism>s</RT·name>
- <p>This follows from its definition; it is literally the increment from the <RT·neologism>Peano Number</RT·neologism>s Machine.</p>
+ <p>This follows from its definition; it is literally the increment from the <RT·neologism>Counting Number</RT·neologism>s Machine.</p>
</RT·section>
<RT·section id="Section·Metrics·Cardinality_question·Lemma_2">
- <RT·name>Lemma 2, cardinality is a <RT·neologism>Peano Number</RT·neologism></RT·name>
+ <RT·name>Lemma 2, cardinality is a <RT·neologism>Counting Number</RT·neologism></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 <RT·neologism>Peano Number</RT·neologism>s.</p>
+ <p>Cardinality is produced by repeatedly calling the <RT·math>A</RT·math> machine, and the <RT·math>A</RT·math> machine produces <RT·neologism>Counting Number</RT·neologism>s.</p>
</RT·section>
</RT·section>
<RT·section id="Section·Metrics·Cardinality_question·Lemma_4">
- <RT·name>Lemma 4, the address space of an open on the right area is identical to the <RT·neologism>Peano Number</RT·neologism>s.</RT·name>
+ <RT·name>Lemma 4, the address space of an open on the right area is identical to the <RT·neologism>Counting Number</RT·neologism>s.</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 <RT·neologism>Peano Number</RT·neologism>s 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 <RT·neologism>Counting Number</RT·neologism>s Machine.</p>
</RT·section>
<RT·section id="Section·Metrics·Cardinality_question·Apparent_contradiction">
<RT·name>The apparent contradiction.</RT·name>
- <p>By Lemma 2, cardinality is a <RT·neologism>Peano Number</RT·neologism>. By Lemma 3 cardinality is not in the address space. By Lemma 4 the address space is identical to the <RT·neologism>Peano Number</RT·neologism>s.</p>
+ <p>By Lemma 2, cardinality is a <RT·neologism>Counting Number</RT·neologism>. By Lemma 3 cardinality is not in the address space. By Lemma 4 the address space is identical to the <RT·neologism>Counting Number</RT·neologism>s.</p>
</RT·section>
<RT·section id="Section·Metrics·Cardinality_question·Resolution">
<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 <RT·neologism>Peano Number</RT·neologism> because a <RT·neologism>Peano Number</RT·neologism> 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 <RT·neologism>Counting Number</RT·neologism> because a <RT·neologism>Counting Number</RT·neologism> 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>Such a value would be a new Turing Machine, one that composes a call to the never halting <RT·neologism>Peano Number</RT·neologism> 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>Such a value would be a new Turing Machine, one that composes a call to the never halting <RT·neologism>Counting Number</RT·neologism> 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·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 <RT·neologism>Peano Number</RT·neologism>s. We can call this machine <RT·math>\aleph_{-1}</RT·math>.
+ 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 <RT·neologism>Counting Number</RT·neologism>s. We can call this machine <RT·math>\aleph_{-1}</RT·math>.
</p>
<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·Counter·step counter="Equation" id="Equation·aleph_difference">
+ <RT·name>The difference of two transfinite cardinals is one</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·aleph_difference" key="counter count step"></RT·Counter·read>
</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 <RT·neologism>Peano Number</RT·neologism> machines annihilate each other, and the increment machine remains. The increment machine can be run, so we end up with an output value.
+ Neither machine can be run. However we can compose the two machines, then simplify the composition. When we do so, the ever larger <RT·neologism>Counting Number</RT·neologism> 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·section id="Section·Peano_Number">
- <RT·name><RT·neologism>Peano Number</RT·neologism></RT·name>
+ <!-- REVISIT:zero CHAPTER-LEVEL. The term was Peano Number and is now
+ Counting Number, because these objects are what a machine that counts
+ produces, not what an axiom set stipulates. Two consequences are not yet
+ worked through:
+
+ 1. Where the sequence starts. The convention note in chapter 3 asserted
+ zero, following modern presentations of Peano arithmetic. If a
+ Counting Number is what the Counting Machine outputs, the start is a
+ fact about the machine and not a convention, and it has to be derived
+ here rather than announced there.
+
+ 2. Whether zero is a number at all. The position to be argued is that an
+ empty sequence of successors, or an empty set, is a status flag rather
+ than an entity. See the markers in Representation of zero, in
+ Numeric value, and in the emptiness discussion in Area and
+ partitioning, which are the three places the current text leans on a
+ zero that is doing two jobs at once.
+
+ A new section giving the machine-based definition of number belongs at the
+ head of this chapter, before Unary representation. -->
+
+ <RT·section id="Section·Number">
+ <RT·name>Number</RT·name>
+
+
+ <RT·section id="Section·Number·Construction">
+ <RT·name>What a number is</RT·name>
+ <!-- TO BE WRITTEN. The construction, replacing both the cardinal account and
+ the successor account as a starting point.
+
+ The primitives are distinct items and groups. A number follows from having
+ things that can be told apart and things that can be collected. Neither
+ distinctness nor collection needs a set theory to state, and both are
+ available from the machine: distinctness is what the Natural Symbol already
+ is, and a group is an area.
+
+ Against the successor account of Dedekind and Peano: it characterizes a
+ structure already possessed rather than saying where the structure came
+ from. It is a description of the thing, offered as its origin.
+
+ For the cardinal account, with a reservation: pairing without counting is
+ the right primitive, and Kleene reaches for sheep and trees to say so. But
+ the set concept carries baggage the machine does not need, and an area does
+ the work without it.
+
+ The Counting Machine, and the sense in which its output is the definition
+ rather than an illustration of one. It begins at one, because a machine
+ cannot be created before there is a first item to place in it. See the
+ first-rest pattern in section (TTU API, Initialization and the first-rest
+ pattern), which is the same fact stated as a programming pattern.
+ -->
+ </RT·section>
+ <RT·section id="Section·Number·Zero">
+ <RT·name>Where zero comes from</RT·name>
+ <!-- TO BE WRITTEN. The argument, in order:
+
+ Zero is not reached by counting. It arrives with a relation, as the distance
+ between an object and itself. That is a degenerate case of a two place
+ relation, and it is the same shape as an empty container: in both, the thing
+ measured or held is absent while the apparatus for measuring or holding
+ remains.
+
+ Consequence for addressing. An address is a distance from the leftmost cell
+ of an area. But the locator already locates the area, so a distance of zero
+ from it is a quantity that does no work. If what is wanted is the leftmost
+ cell, it is already had, and no measurement was needed to get it. Address
+ zero is therefore redundant with the thing it is measured from. Whether that
+ is a defect in the convention or a licence to keep it as a special case is
+ the question this section settles, and the lemma chain in Metrics depends on
+ the answer.
+
+ Consequence for counting. A count has no zero at the first order. What is
+ called a count of zero is the absence of the container, and absence cannot
+ be read off the tape. Section (Area and partitioning, The impossibility of
+ recognizing an empty tape) is the proof: a machine can only be told that a
+ tape is empty, never find it out. So zero is carried as an attribute at a
+ higher order, which is to say a flag.
+
+ Cross-reference the three places the book already says this without saying
+ it: the impossibility results, the zero length area that still has a
+ location, and the empty machine reference in the TTU API.
+ -->
+ </RT·section>
- <RT·section id="Section·Peano_Number·Unary_representation">
+ <RT·section id="Section·Number·Unary_representation">
+ <!-- REVISIT:zero In unary there is no way around the flag. The
+ representation is the container, so an unacknowledged container leaves
+ nothing to look at, and zero cannot be written as a mark. This is the
+ cleanest case in the chapter and should be stated as such: the flag is
+ not a workaround here, it is what zero is. -->
<RT·name>Unary representation</RT·name>
<p>
- A person can define a Turing Machine that is identical to the recursive definition of <RT·neologism>Peano Number</RT·neologism>s 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 <RT·neologism>Peano Number</RT·neologism> Machine and observe as it writes to the tape, that person would watch as the <RT·neologism>Peano Number</RT·neologism>s are printed one after another: ‘·s·ss·sss·ssss· ...’. Here ‘·’ represents zero, and ‘s·’ represents one, etc. Because the <RT·neologism>Peano Number</RT·neologism> 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.
+ A person can define a Turing Machine that is identical to the recursive definition of <RT·neologism>Counting Number</RT·neologism>s 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 <RT·neologism>Counting Number</RT·neologism> Machine and observe as it writes to the tape, that person would watch as the <RT·neologism>Counting Number</RT·neologism>s are printed one after another: ‘·s·ss·sss·ssss· ...’. Here ‘·’ represents zero, and ‘s·’ represents one, etc. Because the <RT·neologism>Counting Number</RT·neologism> 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 <RT·neologism>Peano Number</RT·neologism> 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 <RT·neologism>Peano Number</RT·neologism>, as per the sequence that the <RT·neologism>Peano Number</RT·neologism> 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 <RT·neologism>Peano Number</RT·neologism> 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.
+ In contrast, a function extension version of the <RT·neologism>Counting Number</RT·neologism> 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 <RT·neologism>Counting Number</RT·neologism>, as per the sequence that the <RT·neologism>Counting Number</RT·neologism> 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 <RT·neologism>Counting Number</RT·neologism> 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 <RT·neologism><RT·neologism>Peano Number</RT·neologism></RT·neologism> A is smaller than <RT·neologism>Peano Number</RT·neologism> B is to say that A would occur on the <RT·neologism>Peano Number</RT·neologism> 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.
+ To say that <RT·neologism><RT·neologism>Counting Number</RT·neologism></RT·neologism> A is smaller than <RT·neologism>Counting Number</RT·neologism> B is to say that A would occur on the <RT·neologism>Counting Number</RT·neologism> 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 <RT·neologism>Peano Number</RT·neologism> 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.
+ As such, a person can assign a <RT·neologism>Counting Number</RT·neologism> 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 <RT·neologism>Peano Number</RT·neologism> 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.
+ The <RT·neologism>Counting Number</RT·neologism> 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>
+ <!-- REVISIT:zero Addresses begin at zero here while a Counting Number now
+ begins at one. State explicitly whether an address is a Counting Number,
+ an offset, or a third kind of quantity. The lemma chain in Metrics
+ depends on the answer. -->
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·Peano_Number·Hindu-Arabic_representation">
+ <RT·section id="Section·Number·Hindu-Arabic_representation">
+ <!-- REVISIT:zero Arabic representation has the same trouble in a subtler
+ form. A plain 0 is one digit, so the digit length function returns one
+ while the value is zero. Length and value disagree at exactly one point,
+ and it is this point. Note that this is a defect of the representation
+ rather than of the number, and that the growing representation and the
+ fixed width representation fail differently: see the fixed width
+ section. -->
<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>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 <RT·neologism>Peano Number</RT·neologism> 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 <RT·neologism>Counting Number</RT·neologism> and a sequence of symbols in Arabic Representation.</p>
<p>
For <RT·code>Hindu-Arabic_increment</RT·code>, the machine reads the cell under the head; upon finding a 0 or the terminator, it writes a 1 and halts. Upon finding a 1, it writes a 0, steps right, and repeats the procedure.
</p>
- <RT·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·Counter·step counter="Code" id="Code·increment_controller">
+ <RT·name>A controller that increments a binary counter</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·increment_controller"></RT·Counter·snapshot>
<RT·code>
increment:
a = TTU.read()
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·read snapshot="Code·increment_controller" key="counter count step"></RT·Counter·read>
</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 <RT·neologism>Peano Number</RT·neologism> 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>Here <RT·code>TTU</RT·code> is the tape transport unit. <!-- REVISIT:zero "either zero, which would mean the leftmost cell is empty"
+ treats zero and emptiness as the same case. The first edition argued the
+ opposite: emptiness is an attribute carried at a higher order, not a value
+ on the tape. Reconcile. -->
+ 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 <RT·neologism>Counting Number</RT·neologism> 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.
+ 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. <RT·Counter·read snapshot="Table·increment_cost" key="counter count"></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>
+ <RT·Counter·step counter="Table" id="Table·increment_cost">
+ <RT·name>The cost in steps of each increment, through the range of a three bit counter</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·increment_cost"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<tr>
<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·read snapshot="Table·increment_cost" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
</RT·section>
- <RT·section id="Section·Peano_Number·Computability_of_length">
+ <RT·section id="Section·Number·Computability_of_length">
<RT·name>The Computability of Length and Unbounded Zeros</RT·name>
- <p>Consider the proposition of representing <RT·neologism>Peano Number</RT·neologism>s 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 <RT·neologism>Counting Number</RT·neologism>s 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>
</RT·section>
- <RT·section id="Section·Peano_Number·Representation_of_zero">
+ <RT·section id="Section·Number·Representation_of_zero">
<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><!-- REVISIT:zero This section already treats zero as the state before the
+ first carry-in, which is close to calling it a status rather than an
+ entity, but it then goes on to offer two representations for zero as
+ though it were a value needing one. Reconcile. -->
+ 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 <RT·neologism>Peano Number</RT·neologism>) 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>This reveals a fundamental property of Arabic Representation: it encodes both the sequence of digit symbols (which map to a <RT·neologism>Counting Number</RT·neologism>) 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>
+ <RT·Counter·step counter="List" id="List·zero_representation_options">
+ <RT·name>The two options for representing zero</RT·name>
+ <RT·Counter·snapshot counter="List" 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·read snapshot="List·zero_representation_options" key="counter count step"></RT·Counter·read>
</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>
</RT·section>
- <RT·section id="Section·Peano_Number·Numeric_value">
+ <RT·section id="Section·Number·Numeric_value">
<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>
</RT·section>
- <RT·section id="Section·Peano_Number·Meaning_of_the_word_digital">
+ <RT·section id="Section·Number·Meaning_of_the_word_digital">
<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>
</RT·section>
- <RT·section id="Section·Peano_Number·Scanning-Order_and_Digit-Order">
+ <RT·section id="Section·Number·Scanning-Order_and_Digit-Order">
<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>
</RT·section>
- <RT·section id="Section·Peano_Number·Binary_octal_hex_BCD">
+ <RT·section id="Section·Number·Fixed_width">
+ <RT·name>Fixed width representation</RT·name>
+ <!-- TO BE WRITTEN, and it is a distinct representation rather than a variant
+ of the preceding one.
+
+ A growing Arabic number is a sequence whose length is whatever has been
+ written. A fixed array of bits is a different object: the container is
+ allocated first and the digits are placed into it, so length is a property
+ of the container and not of the number. Every consequence in this section
+ follows from that inversion.
+
+ Zero is where the difference shows. In the growing representation, zero is
+ the sequence not yet begun. In a fixed array, every cell holds something,
+ so zero has to be encoded as a value among values, and the representation
+ has no way to say that the container is empty rather than holding zero.
+
+ The empirical confirmation is IEEE 754, which is the most carefully
+ engineered number representation in use. It does not treat zero as an
+ ordinary value. Zero is a reserved encoding, signalled by a zero exponent
+ field together with a zero significand, and there are two of them, positive
+ and negative, distinguished by the sign bit. The most demanding practical
+ number system available flags zero, and flags it twice. That is the
+ argument of the Zero section arriving from industry rather than from
+ philosophy, and it should be reported as such.
+
+ The subsections that follow, on radix, allocation, and ordering, all belong
+ to the fixed width case and should be read under it.
+ -->
+ </RT·section>
+
+ <RT·section id="Section·Number·Binary_octal_hex_BCD">
<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>
</RT·section>
- <RT·section id="Section·Peano_Number·Allocation">
+<!-- ===================================================================== -->
+<!-- TWO INSERTS. -->
+<!-- -->
+<!-- 1. Section·Number·Fractions, placed inside the Number chapter, -->
+<!-- immediately before Section·Number·Realizable_number_system. It is -->
+<!-- the last representation topic before the book’s own system, and it -->
+<!-- needs both the growing and the fixed width representations, so it -->
+<!-- cannot sit earlier than either. -->
+<!-- -->
+<!-- 2. Section·Limits, a new chapter placed between Number and -->
+<!-- Computational Analysis. It is needed to finish the fractions -->
+<!-- section above it, and it supplies the limit analyzer that -->
+<!-- Computational Analysis already uses at present without having -->
+<!-- defined it. The paragraph now in Computational Analysis beginning -->
+<!-- "As an analyzer does not run the machine being analyzed" should -->
+<!-- either move here or become a back reference. -->
+<!-- ===================================================================== -->
+
+ <RT·section id="Section·Number·Fractions">
+ <RT·name>Fractions</RT·name>
+ <!-- TO BE WRITTEN. This is where a limit first becomes unavoidable, and the
+ section should reach that point and then hand off rather than resolve it.
+
+ Owes the reader:
+
+ - the radix point, in both the growing and the fixed width representation
+ - the division machine asked for one third in base ten, which does not
+ halt, so that 0.333... is not a number written down but the name of a
+ machine that runs forever, with the ellipsis standing in for a citation
+ to the machine
+ - the terminating condition: a fraction a/b terminates in base r exactly
+ when every prime factor of b divides r, which is why base ten terminates
+ only for denominators built from twos and fives. This is Number Theory
+ and takes no limit to state or to prove
+ - therefore: non-termination is a property of the radix and not of the
+ number, and the limit is being called upon to repair a choice of
+ representation
+ - the pair observation, which on inspection is a triple. Two Counting
+ Numbers, 3 and 0.1, represent one third exactly when a machine reads the
+ first as a radix and the second as digits against it. The same two marks,
+ 1 and 3, represent one third exactly when a machine divides the first by
+ the second. Hand either pair to the wrong machine and a different number
+ comes out, or none. So the object is not a pair but a triple, and the
+ third component is the machine.
+
+ This is the argument of the stored program chapter arriving one level
+ down. A tape holds marks, and what those marks are is settled by what
+ reads them, not by anything in the marks. A number pair is a pair of
+ marks. A number is a pair together with its reader.
+
+ Which sharpens the claim this section is making. It is not that one third
+ has several representations. It is that one third is exactly representable
+ by several machines, and the non-terminating expansion is what the base
+ ten machine does with it. That is a defect in the reader that was chosen,
+ not in the number.
+
+ Note the same structure in the Numerical Analysis paragraph of Conventio,
+ where one number of the pair scales the other; the machine that performs
+ the scaling is the unnamed third component there as well.
+
+ TERMINOLOGY, unsettled: whether to call the third component the machine,
+ the reader, or the interpreter. The stored program chapter uses
+ interpreter for a program that gives meaning to marks on a tape, which
+ argues for that word, but interpreter is already carrying a specific load
+ there and may not stretch.
+ - hand off to the Limits chapter, without taking the step here. The
+ handoff is direct: that chapter opens by saying a limit cannot be given a
+ point, only a function, and the reason has just been established here.
+ A point was never a number. A digit string is inert. What a limit
+ analyzer needs is what a digit string always needed, which is the machine
+ that makes it mean something.
+ -->
+ </RT·section>
+
+ <!-->
+ <RT·section id="Section·Limits">
+ <RT·name>Limits</RT·name>
+ <!-- TO BE WRITTEN. Rough draft of the argument follows, in order. The prose
+ below is a sketch to work from, not finished text.
+
+ 1. What the analyzer is given
+
+ A limit cannot be handed a point. Asked what 0.999... equals, there is
+ nothing to examine: the string is the shadow of a machine and the digits
+ alone do not say which machine cast it. What a limit analyzer must be given
+ is the function, the generator, the machine itself. Only then is there
+ something to inspect.
+
+ The fractions section has already established why, so this needs asserting
+ rather than arguing. A number is not a pair of marks but a pair together with
+ the machine that reads them. A point, handed over on its own, is the pair with
+ the machine stripped off. There was never anything there for an analyzer to
+ work on.
+
+ This is why the term analysis is not being borrowed here from two places at
+ once. Mathematical analysis and the analysis of section (Orders of analysis)
+ are the same activity: a machine is held as an object and examined rather
+ than run. A limit analyzer does not run the machine it studies, which is why
+ it is permitted to succeed where the machine never finishes.
+
+ 2. The equality is a decree, and the decree is about provenance
+
+ 0.999... = 1 is not a result any machine reaches. It is the definition that
+ the value of a non-halting machine shall be the limit of its partial sums.
+
+ And the definition is about history rather than about the digits. If we hold
+ the memory that this digit sequence was generated by a process equivalent to
+ one, the equivalence is true. Absent that memory there is only a string, and
+ a string with no provenance supports no such claim. So a limit is a memory
+ review function: it is handed a generator, it reconstructs the history that
+ generator produces, and it reports what that history was tending toward.
+
+ CARE: the complex number analogy belongs here but needs handling. The
+ defensible form is the rotational one, where the second component carries
+ accumulated phase and phase is a record of what has already happened, which
+ connects to the treatment of the rotational language in the anatomy chapter.
+ The unqualified claim that complex numbers are memory will draw fire from a
+ mathematician, and the phase reading will not.
+
+ 3. Where the step is actually taken
+
+ Conventio says the boundary between Number Theory and continuous mathematics
+ is a single step, the supposition that a series completes at infinity. This
+ chapter is where that step is examined rather than named.
+
+ The quantifier structure places it exactly. Given an epsilon, find an N: that
+ is a computation, finite, and a machine performs it. For every epsilon: that
+ is the unbounded quantifier. So a limit claim is semi-decidable in shape,
+ verifiable instance by instance and never settled by running. Cross-reference
+ the predicate logic chapter, where the quantifier is derived as an iteration
+ with a halting condition, and the orders of analysis.
+
+ 4. What survives
+
+ The chapter does not reject limits. It rejects the completed limit and keeps
+ the procedural one, which is a replacement rather than a subtraction and is
+ therefore much harder to argue with.
+
+ Turing’s 1936 paper is titled On Computable Numbers, and a computable real is
+ one whose digits a machine produces on demand. Boehm and Cartwright, already
+ cited in Computational Analysis, are the working implementation. A limit that
+ stays realizable is a program, and a program is exactly what a limit analyzer
+ can be given.
+
+ The counting argument is worth one line: machines are countable and the reals
+ are not, so most reals have no machine at all. What the completed limit buys
+ is precisely the objects no apparatus can produce.
+
+ 5. Forward
+
+ The Stirling appendix calls the Stirling numbers the translation layer
+ between continuous and discrete mathematics. Once this chapter exists, that
+ claim can be stated as what it is: a change of basis between two discrete
+ representations, one of which was reached by a step this book declines.
+ -->
+ </RT·section>
+
+
+ <RT·section id="Section·Number·Allocation">
<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 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><RT·Counter·read snapshot="Figure·little-endian_digit-order" key="counter count"></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>
+ <RT·Counter·step counter="Figure" id="Figure·little-endian_digit-order">
+ <RT·name>A left-justified word holding a number least-significant-digit-first</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·little-endian_digit-order" key="counter count step"></RT·Counter·read>
</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 <RT·Counter·read snapshot="Figure·big-endian_digit-order" key="counter count"></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 <RT·Counter·read snapshot="Figure·little-endian_digit-order" key="counter count"></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>
+ <RT·Counter·step counter="Figure" id="Figure·big-endian_digit-order">
+ <RT·name>The same number held in big-endian digit-order</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·big-endian_digit-order" key="counter count step"></RT·Counter·read>
</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>
</RT·section>
- <RT·section id="Section·Peano_Number·Bit_Order_Within_Bytes">
+ <RT·section id="Section·Number·Bit_Order_Within_Bytes">
<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>
</RT·section>
- <RT·section id="Section·Peano_Number·Byte_Order_Within_Words">
+ <RT·section id="Section·Number·Byte_Order_Within_Words">
<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>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><RT·Counter·read snapshot="Figure·in-address-order_byte-copy" key="counter count"></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>
+ <RT·Counter·step counter="Figure" id="Figure·in-address-order_byte-copy">
+ <RT·name>A byte-by-byte copy performed in address order</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·in-address-order_byte-copy" key="counter count step"></RT·Counter·read>
</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>
- <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>
+ <RT·Counter·step counter="Figure" id="Figure·reverse-order_byte-copy">
+ <RT·name>A reverse order byte copy performed word by word</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·reverse-order_byte-copy" key="counter count step"></RT·Counter·read>
</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>
</RT·section>
- <RT·section id="Section·Peano_Number·Realizable_number_system">
+ <RT·section id="Section·Number·Realizable_number_system">
<RT·name>The Realizable Machine number system</RT·name>
<p>The native Integer data type for the Realizable Machine 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>
<p>
- The orders of analysis were named in section
- <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis"></RT·Counter·read>. This
+ The orders of analysis were named in
+ <RT·Counter·read snapshot="Section·Consequentiality·Orders_of_analysis" key="counter count"></RT·Counter·read>. This
chapter takes the second-order as its working material.
</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·Counter·step counter="Code" id="Code·five_AST">
+ <RT·name>The abstract syntax tree for the <RT·neologism>Counting Number</RT·neologism> five</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·five_AST"></RT·Counter·snapshot>
<RT·code>
(defparameter *five-ast*
’(progn
(write s) (step)
))
</RT·code>
- Code <RT·Counter·read snapshot="Code·five_AST"></RT·Counter·read>. <RT·name>The abstract syntax tree for the <RT·neologism>Peano Number</RT·neologism> five</RT·name>
+ <RT·Counter·read snapshot="Code·five_AST" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·three_AST">
+ <RT·name>The abstract syntax tree for the <RT·neologism>Counting Number</RT·neologism> three</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·three_AST"></RT·Counter·snapshot>
<RT·code>
(defparameter *three-ast*
’(progn
(write s) (step)
))
</RT·code>
- Code <RT·Counter·read snapshot="Code·three_AST"></RT·Counter·read>. <RT·name>The abstract syntax tree for the <RT·neologism>Peano Number</RT·neologism> three</RT·name>
+ <RT·Counter·read snapshot="Code·three_AST" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Code" id="Code·subtract_composer">
+ <RT·name>A composer that subtracts by inverting the direction of one machine</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·subtract_composer"></RT·Counter·snapshot>
<RT·code>
(defun invert-direction (cmds)
(cond
,@(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·read snapshot="Code·subtract_composer" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
- <p>We pass our two <RT·neologism>Peano Number</RT·neologism> ASTs to this composer, and we get as a result a newly synthesized AST.</p>
+ <p>We pass our two <RT·neologism>Counting Number</RT·neologism> 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·Counter·step counter="Code" id="Code·five-minus-three_primitive">
+ <RT·name>The composed but unsimplified tree for five minus three</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·five-minus-three_primitive"></RT·Counter·snapshot>
<RT·code>
(defparameter
*primitive-five-minus-3-ast*
;; (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·read snapshot="Code·five-minus-three_primitive" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
</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 <RT·neologism>Peano Number</RT·neologism> 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.
+ 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 <RT·neologism>Counting Number</RT·neologism> 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·Counter·step counter="Code" id="Code·machine_simplifier">
+ <RT·name>A simplifier that removes annihilating instruction pairs</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·machine_simplifier"></RT·Counter·snapshot>
<RT·code>
(defun remove-annihilations (cmds)
(cond
)))
</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·read snapshot="Code·machine_simplifier" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·five-minus-three_simplified">
+ <RT·name>The simplified tree for five minus three</RT·name>
+ <RT·Counter·snapshot counter="Code" snapshot="Code·five-minus-three_simplified"></RT·Counter·snapshot>
<RT·code>
(defparameter
*simplified-five-minus-3-ast*
;; (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·read snapshot="Code·five-minus-three_simplified" key="counter count step"></RT·Counter·read>
</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·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 <RT·neologism>Peano Number</RT·neologism> 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.
+ 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 <RT·neologism>Counting Number</RT·neologism> 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>
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·Counter·step counter="Code" id="Code·divide-by-zero">
+ <RT·name>A division by zero, which does not reduce</RT·name>
+ <RT·Counter·snapshot counter="Code" 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·read snapshot="Code·divide-by-zero" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·divide-by-zero_composed">
+ <RT·name>A composition of two unreduced divisions</RT·name>
+ <RT·Counter·snapshot counter="Code" 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·read snapshot="Code·divide-by-zero_composed" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Code" id="Code·divide-by-zero_result">
+ <RT·name>The reduced result, still carrying a divide of zero by zero</RT·name>
+ <RT·Counter·snapshot counter="Code" 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·read snapshot="Code·divide-by-zero_result" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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>
+ <RT·Counter·step counter="Table" id="Table·difference-table_for_t-squared">
+ <RT·name>The forward difference table for f(t) = t²</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·difference-table_for_t-squared"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<thead>
</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·read snapshot="Table·difference-table_for_t-squared" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Code" id="Code·difference-engine_tape-trace">
+ <RT·name>The tape at each call while extending t²</RT·name>
+ <RT·Counter·snapshot counter="Code" 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 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·read snapshot="Code·difference-engine_tape-trace" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Equation" id="Equation·Newton_forward-difference">
+ <RT·name>Newton’s forward difference formula for the value at call ω</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·Newton_forward-difference" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Equation" id="Equation·initial-tape_from_evaluations">
+ <RT·name>The initial tape components recovered from evaluated calls</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·initial-tape_from_evaluations" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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>
+ <RT·Counter·step counter="Table" id="Table·difference_equations">
+ <RT·name>The initial differences as a system of equations in the polynomial constants</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·difference_equations"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<thead>
</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·read snapshot="Table·difference_equations" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Equation" id="Equation·Stirling-second_matrix">
+ <RT·name>Polynomial constants carried to initial differences by Stirling numbers of the second kind</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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}
\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·read snapshot="Equation·Stirling-second_matrix" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
</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>).
+ 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, <RT·Counter·read snapshot="Section·Appendix_Stirling_Numbers" key="counter count"></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·Counter·step counter="Equation" id="Equation·polynomial-constant_from_differences">
+ <RT·name>A polynomial constant recovered using signed Stirling numbers of the first kind</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·polynomial-constant_from_differences" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Equation" id="Equation·polynomial_from_initial-tape">
+ <RT·name>The polynomial built directly on a basis of binomial terms</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·polynomial_from_initial-tape" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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>
+ <RT·Counter·step counter="Table" id="Table·difference-table_for_2-to-the-t">
+ <RT·name>The forward difference table for f(t) = 2ᵗ</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·difference-table_for_2-to-the-t"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<thead>
</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·read snapshot="Table·difference-table_for_2-to-the-t" key="counter count step"></RT·Counter·read>
</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·Computational_Analysis·Evaluating_and_Extending·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.
+ 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 <RT·Counter·read snapshot="Section·Computational_Analysis·Evaluating_and_Extending·Lemma_evaluating_call" key="counter count"></RT·Counter·read>, stating that evaluating call <RT·math>\omega</RT·math> requires an initial tape populated with components 0 through <RT·math>\omega</RT·math> of row 0, exactly those components are needed for the recurrence to proceed. Furthermore, when new values are needed, they are easily computed. A programmer need not store the entire infinite first row of the difference table on a static tape.
</p>
<p>
Now suppose we want to express the quotient of these two functions.
</p>
- <RT·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·Counter·step counter="Equation" id="Equation·quotient_definition">
+ <RT·name>The quotient h(t), carrying a pole and a zero at t = 5</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·quotient_definition" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="Figure" id="Figure·singularity_plot">
+ <RT·name>The quotient h(t) plotted across the singularity at t = 5</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·singularity_plot" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
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>
+ <RT·Counter·step counter="Table" id="Table·quotient_difference-ratios">
+ <RT·name>The quotient and the ratio of first differences through the singularity</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·quotient_difference-ratios"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<thead>
</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·read snapshot="Table·quotient_difference-ratios" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<p>
</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>.
+ I included the first difference along with the evaluation results in <RT·Counter·read snapshot="Table·quotient_difference-ratios" key="counter count"></RT·Counter·read>. When building a first difference table an interesting thing happens at the singularity, the first difference and the function itself coincide, note calls 4 and 5. This makes sense because <RT·math>δ f(4) = f(5) - f(4)</RT·math>, which becomes <RT·math>δ f(4) = 0 - f(4)</RT·math>, and the same happens to <RT·code>g</RT·code> in the denominator, so the signs cancel. Note also <RT·math>δ f(5) = f(6) - f(5)</RT·math>, which becomes <RT·math>δ f(5) = f(6) - 0</RT·math>.
</p>
<p>Ostensibly it looks like we have happened upon a discrete version of L’Hôpital’s rule, that we merely use the first difference quotient instead of the function quotient at the singularity. But alas, the coincidence occurs at <RT·math>h(4)</RT·math> rather than at <RT·math>h(5)</RT·math>. For the second coincidence, we find <RT·math>h(6)</RT·math> as the 5th first finite difference. In neither case did we learn anything about the value of <RT·math>h(5)</RT·math>.
So then, perhaps we set the value at the singularity to <RT·math>x</RT·math> build out the difference table, then solve for <RT·math>x</RT·math>?
</p>
- <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>
+ <RT·Counter·step counter="Figure" id="Figure·difference-table_with_x">
+ <RT·name>The difference table with the singular value carried as the variable x</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·difference-table_with_x" key="counter count step"></RT·Counter·read>
</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·Counter·step counter="Equation" id="Equation·quotient_initial-differences">
+ <RT·name>The initial differences of the quotient, taken from the function</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·quotient_initial-differences" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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·Counter·step counter="Equation" id="Equation·transcendental_constant">
+ <RT·name>The transcendental constant the quotient requires</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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·read snapshot="Equation·transcendental_constant" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="Figure" id="Figure·D_0-vector_for-quotient">
+ <RT·name>The D₀ vector for the quotient</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·D_0-vector_for-quotient" key="counter count step"></RT·Counter·read>
</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>
+ <RT·Counter·step counter="Figure" id="Figure·difference-table_for_h">
+ <RT·name>The difference table for h(t)</RT·name>
+ <RT·Counter·snapshot counter="Figure" 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·read snapshot="Figure·difference-table_for_h" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
<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>
+ <RT·Counter·step counter="Table" id="Table·direct-evaluation_vs_extended-quotient">
+ <RT·name>Direct evaluation of f(t)/g(t) against the extended quotient vector H(t)</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·direct-evaluation_vs_extended-quotient"></RT·Counter·snapshot>
<!-- first edition: no number carried -->
<table>
<thead>
</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·read snapshot="Table·direct-evaluation_vs_extended-quotient" key="counter count step"></RT·Counter·read>
</RT·Counter·step>
</RT·section>
<p>The fundamental claim of computational analysis is that all functions can be viewed as discrete entities. Take this simple function:</p>
- <RT·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·Counter·step counter="Code" id="Code·cubic_function">
+ <RT·name>A simple cubic function</RT·name>
+ <RT·Counter·snapshot counter="Code" 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·read snapshot="Code·cubic_function" key="counter count step"></RT·Counter·read>
</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>
<!-- rest of book goes here --->
</RT·section>
- </RT·section>
-
- <!--------------------------------------------------------------------------------->
- <RT·section id="Section·Appendix_formal_methods">
- <RT·name>Appendix: The Tension Between Formal Methods and Practical Architecture</RT·name>
-
- <RT·section id="Section·Appendix_formal_methods·Does_theory_matter">
- <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>
+ <!--------------------------------------------------------------------------------->
+ <RT·section id="Section·Logic_and_neural_networks">
+ <RT·name>Neural networks</RT·name>
+ <!--
+ New material.
+
+ Owes the reader:
+ - the equivalence itself, stated as a transform and tested against
+ the consequentiality criterion of chapter 9 rather than asserted
+ - a program that emulates a network, so the claim is realizable in
+ the sense this book means
+ - what the emulation costs
+ - the phylum argument: a network running on the machine is another
+ specimen on the bench, and the anatomy chapter has already set up
+ how such a thing is to be classified
+
+ Note: the anatomy chapter compares a trilobite with a calculating
+ engine and observes that a working machine is a better subject than a
+ fossil because it still runs. That argument carries here directly.
+ -->
</RT·section>
- <RT·section id="Section·Appendix_formal_methods·Formal_methods_in_design">
- <RT·name>Do formal methods belong in computer design?</RT·name>
-
-
-
- <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>
-
- <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>
-
- <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·Logic_and_neural_networks">
- <RT·name>Logic and neural network equivalence</RT·name>
- <!--
- New material.
+ <RT·section id="Section·Appendix">
+ <RT·name>Appendix</RT·name>
- Owes the reader:
- - the equivalence itself, stated as a transform and tested against
- the consequentiality criterion of chapter 9 rather than asserted
- - a program that emulates a network, so the claim is realizable in
- the sense this book means
- - what the emulation costs
- - the phylum argument: a network running on the machine is another
- specimen on the bench, and the anatomy chapter has already set up
- how such a thing is to be classified
-
- Note: the anatomy chapter compares a trilobite with a calculating
- engine and observes that a working machine is a better subject than a
- fossil because it still runs. That argument carries here directly.
- -->
- </RT·section>
+ <RT·section counter="Appendix,Appendix Section" id="Section·Appendix·formal_methods">
+ <RT·name>The Tension Between Formal Methods and Practical Architecture</RT·name>
+ <RT·section id="Section·Appendix·formal_methods·Does_theory_matter">
+ <RT·name>Does computation theory matter to computing?</RT·name>
-<!--------------------------------------------------------------------------------->
- <RT·section id="Section·Appendix_dialectic_to_Kant">
- <RT·name>Appendix: The dialectic from the Athenian decline to Kant</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. <RT·Counter·read snapshot="Table·memory-tier_scaled-latency_appendix" key="counter count"></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>
- <p>Section <RT·Counter·read snapshot="Section·Naturalism·The_argument_since"></RT·Counter·read> gives the short account of what became of the argument between Plato and Aristotle. This appendix gives the long one. It is arranged by date, with one exception noted where it occurs. A reader who accepts the summary loses nothing by skipping it.</p>
+ <RT·Counter·step counter="Table" id="Table·memory-tier_scaled-latency_appendix">
+ <RT·name>Memory tier latency, scaled so that one clock tick lasts one day</RT·name>
+ <RT·Counter·snapshot counter="Table" snapshot="Table·memory-tier_scaled-latency_appendix"></RT·Counter·snapshot>
+ <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>
+ <RT·Counter·read snapshot="Table·memory-tier_scaled-latency_appendix" key="counter count step"></RT·Counter·read>
+ </RT·Counter·step>
- <p>As Greek learning passed among late-antique, Syriac, and Arabic-speaking communities, the transmission of Greek philosophy became dispersed rather than simply preserved in one place. Western Europe retained fragments of Aristotle’s logic, while much of the philosophical and scientific corpus was translated and developed in the Syriac Christian and Arabic scholarly worlds. The Abbasid translation movement made Aristotle, Euclid, Galen, and other Greek authors available in Arabic, but the work was not merely translational: it also involved commentary, criticism, and the construction of new philosophical syntheses.
- <RT·endnote>The Arabic translation movement flourished especially under the Abbasids. Syriac Christian scholars had already translated Greek philosophical and medical works into Syriac, and some of these scholars later participated in Arabic translations. The resulting Arabic tradition also incorporated Neoplatonic works and texts falsely attributed to Aristotle, notably the <em>Theology of Aristotle</em>, an adaptation of parts of Plotinus. See Cristina D’Ancona, “Greek Sources in Arabic and Islamic Philosophy,” <em>Stanford Encyclopedia of Philosophy</em>.</RT·endnote>
- </p>
+ </RT·section>
- <p>
- One recurring problem was how philosophical demonstration could be reconciled with Islamic theology. Al-Farabi (c. 872−950) held that truth reaches the philosopher as a proof and everyone else as an image of it, with different nations holding different images of the one truth. Avicenna (980−1037) gave Aristotelian and Neoplatonic materials a systematic philosophical form. Ibn al-Haytham (c. 965−1040) argued, with the aid of experiments, that vision depends on light entering the eye rather than on rays emitted by the eye. Al-Ghazali (1058−1111) denied that fire possesses an independent and necessary power to burn cotton, arguing that what appears as natural causation depends at every occasion on God’s act. Ibn Rushd (1126−1198) answered that a demonstrated conclusion cannot conflict with a revealed truth, and that apparent conflicts call for a revision of the textual interpretation.
- <RT·endnote>Al-Ghazali, <em>Tahāfut al-Falāsifa</em>, discussion 17. The position, termed occasionalism, denies necessary causal efficacy to created things; it need not deny the regular succession of events or the usefulness of ordinary causal descriptions. Its relationship to Hume’s later account of causation is one of resemblance and historical comparison, not simple identity.</RT·endnote>
- </p>
+ <RT·section id="Section·Appendix·formal_methods·Formal_methods_in_design">
+ <RT·name>Do formal methods belong in computer design?</RT·name>
- <p>Ibn Rushd’s commentaries, together with other Arabic philosophical works, entered Latin Europe through translators working in Toledo and elsewhere. The Arabic-Latin translation movements transformed several areas of Latin philosophy, including natural philosophy, psychology, metaphysics, logic, and ethics.
- <RT·endnote>The Arabic-Latin translation movement was not a single return of Greek philosophy through one city or one author. Important translations were made in Toledo, Sicily, southern Italy, and elsewhere. The influence of Arabic philosophy on Latin Europe was especially strong in natural philosophy, psychology, and metaphysics, but it also reached logic and ethics. See Dag Nikolaus Hasse, “Influence of Arabic and Islamic Philosophy on the Latin West,” <em>Stanford Encyclopedia of Philosophy</em>.</RT·endnote>
- </p>
+ <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>Here the arrangement by date is set aside once, to introduce the question the schoolmen were answering. The specifically medieval form of it was shaped by Porphyry’s <em>Isagoge</em>, an introduction to Aristotle’s <em>Categories</em>. Porphyry famously set aside, for a deeper investigation, the questions of whether genera and species exist in reality or only in thought, whether they are bodies or incorporeal, and whether they exist separately or in sensible things. Boethius then carried these questions into Latin philosophy through two commentaries, and medieval authors spent centuries refining the relations among things, concepts, and the universal terms by which things are named.
- <RT·endnote>Porphyry, <em>Isagoge</em>, in John Peter Anton and George L. Kustas, eds., <em>Essays in Ancient Greek Philosophy</em>, vol. 2 (Albany: State University of New York Press, 1971), 197−199. Boethius wrote two commentaries on Porphyry’s text, the first based on Marius Victorinus’s translation and the second on his own.</RT·endnote>
- </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>
- <p>William of Ockham (c. 1287−1347) gave one of the sharpest late-medieval attempts to dissolve this dialectic. He held that what the many instances of a thing have in common is neither a Form standing above them nor an essence lodged within them, but a sign that stands for all of them.
- <RT·endnote>William of Ockham, <em>Summa Logicae</em> I.14−17 (c. 1323); in English as <em>Ockham’s Theory of Terms: Part I of the Summa Logicae</em>, trans. Michael J. Loux (Notre Dame: University of Notre Dame Press, 1974). The fuller critique is in the <em>Ordinatio</em> I d.2 qq.4−8. The position is called nominalism, from <em>nomen</em>, a name. Peter Abelard (1079−1142) reached a non-realist account two centuries earlier, while Ockham gave one of the sharpest and most influential late-medieval statements. Ockham’s sign is a concept in the soul, with spoken and written words subordinated to it, so the sign he means is nearer the abstraction of section <RT·Counter·read snapshot="Section·Conventio·Symbol"></RT·Counter·read> than the representation is.</RT·endnote>
- Plato places the explanatory model in an intelligible order distinct from sensible particulars, whereas Ockham denies that there is any independently existing universal of that kind to locate. In the language of section <RT·Counter·read snapshot="Section·Conventio·Symbol"></RT·Counter·read>, Ockham keeps the representation and the instances below, and empties the layer above.
- </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>
- <p>Thomas Hobbes (1588−1679) pressed the naturalist argument into the human body. Against the separation of an immaterial mind from an extended body, he treated sensation, imagination, and reasoning as processes belonging to the natural order. Thought, on this account, was not a visitor from a higher realm but something that happened in a body.
- <RT·endnote>Thomas Hobbes, <em>Leviathan</em> (London, 1651), Introduction and chaps. 1 and 5. In the Introduction Hobbes compares the body to an artificial machine, asking why the heart should not be a spring, the nerves strings, and the joints wheels. In chap. 1 he treats sense as a motion produced in the organ by an external body; in chap. 2 he describes imagination as decaying sense; and in chap. 5 he defines reasoning as a form of reckoning or computation. See also Hobbes, <em>De Corpore</em> (London, 1655), Part I, chap. 1, and Part II on geometry and motion. Hobbes’s materialism does not anticipate a modern computational theory in every detail, but it places bodily sensation, imagination, and reasoning within a natural order rather than assigning them to an immaterial realm.</RT·endnote>
- </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>
- <p>René Descartes (1596−1650) argued that certain knowledge comes from reason reflecting on itself, rather than from the senses which can deceive. The ideas he trusted most were those he regarded as arising from the mind’s own constitution rather than being derived from sensory experience, thus giving Plato a modern form.
- <RT·endnote>René Descartes, <em>Meditationes de Prima Philosophia</em> (Paris, 1641), Meditations III and V. The position is called <RT·term>rationalism</RT·term>. Descartes held the body to be a machine and animals to be machines entire, while reserving the mind from mechanism; the line he drew there was erased a century later by Julien Offray de La Mettrie, <em>L’Homme Machine</em> (Leyden, 1747).</RT·endnote>
- John Locke (1632−1704) answered that there are no innate ideas: the mind begins without ideas, and what is in it arrives through sensation and through reflection on what sensation delivers. Yet Locke treated mathematics as demonstrative knowledge of relations among ideas rather than as a direct report of sensation.
- <RT·endnote>John Locke, <em>An Essay Concerning Human Understanding</em> (London, 1690), Book I against innate ideas, Book II on the two sources, and Book IV chap. 4 on mathematical certainty. The position is called <RT·term>empiricism</RT·term>. Locke’s denial concerns innate ideas, not the mind’s innate capacities for receiving and comparing ideas.</RT·endnote>
- </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>
- <p>George Berkeley (1685−1753) attempted to dissolve the dialectic by identifying sensible objects with ideas as perceived, rather than treating perception as a report about some further material thing standing behind them. The world as sensed is therefore a world of perceived ideas, but Berkeley does not reduce reality to a private person’s perceptions: the order of nature is secured by God’s perception and is not controlled by individual will. When asked what becomes of the furniture in a room when nobody is there, he answered that God perceives it.
- <RT·endnote>George Berkeley, <em>A Treatise Concerning the Principles of Human Knowledge</em> (Dublin, 1710), §§3 and 6 for the doctrine, §§28−33 and §146 for the argument reaching God, and §48 for the objects that persist unperceived by any man. Put again, and more accessibly, in <em>Three Dialogues between Hylas and Philonous</em> (London, 1713).</RT·endnote>
- </p>
+ </RT·section>
+ </RT·section>
- <p>David Hume (1711−1776) divided all inquiry into relations of ideas and matters of fact. Hume placed mathematical certainty among the relations of ideas while noting that mathematical certainty belongs to intuition and demonstration rather than to empirical observation.
- <RT·endnote>David Hume, <em>An Enquiry Concerning Human Understanding</em> (London, 1748), §IV part 1.</RT·endnote>
- </p>
+ <RT·section counter="Appendix,Appendix Section" id="Section·Appendix·dialectic_to_Kant">
+ <RT·name>The dialectic from the Athenian decline to Kant</RT·name>
- <p>In 1781 Immanuel Kant (1724−1804) placed mathematics within the conditions of human cognition. He argued that space and time are forms of intuition: space is the condition under which geometry is possible, and time is the condition under which arithmetic can be constructed through succession.
- <RT·endnote>Immanuel Kant, <em>Kritik der reinen Vernunft</em> (Riga: Hartknoch, 1781), Introduction B14−B17 and the Transcendental Aesthetic. Kant does not merely say that mathematics is a private invention. He argues that space and time are forms of intuition, conditions under which objects can be given to us and mathematical cognition can arise.</RT·endnote>
- </p>
+ <p><RT·Counter·read snapshot="Section·Naturalism·The_argument_since" key="counter count"></RT·Counter·read> gives the short account of what became of the argument between Plato and Aristotle. This appendix gives the long one. It is arranged by date, with one exception noted where it occurs. A reader who accepts the summary loses nothing by skipping it.</p>
- <p>Kant’s position remained influential until nineteenth-century geometries challenged the identification of Euclidean space with the necessary structure of human intuition. In the 1820s and 1830s, Nikolai Lobachevsky and János Bolyai developed geometries in which Euclid’s parallel postulate fails. In 1868 Eugenio Beltrami constructed a model of Lobachevskian geometry within Euclidean geometry, establishing a relative-consistency result: if the Euclidean background is consistent, then so is the modeled geometry.
- <RT·endnote>Nikolai Lobachevsky, “On the Principles of Geometry,” <em>Kazan Messenger</em> (1829−1830); János Bolyai, “Appendix Scientiam Spatii Absolute Veram Exhibens,” published with Farkas Bolyai’s <em>Tentamen</em> (Maros-Vásárhely, 1832); Eugenio Beltrami, “Saggio di interpretazione della geometria non-euclidea,” <em>Giornale di Matematiche</em> 6 (1868): 284−312. Gauss had reached similar results and published none of them. The historical point is not that non-Euclidean geometry simply refuted Kant, but that it forced philosophers to reconsider what Kant’s claims about mathematical intuition could mean.</RT·endnote>
- This did not by itself refute Kant’s philosophy, but it made the location of mathematical necessity in human spatial intuition much more difficult to defend.
- </p>
+ <p>As Greek learning passed among late-antique, Syriac, and Arabic-speaking communities, the transmission of Greek philosophy became dispersed rather than simply preserved in one place. Western Europe retained fragments of Aristotle’s logic, while much of the philosophical and scientific corpus was translated and developed in the Syriac Christian and Arabic scholarly worlds. The Abbasid translation movement made Aristotle, Euclid, Galen, and other Greek authors available in Arabic, but the work was not merely translational: it also involved commentary, criticism, and the construction of new philosophical syntheses.
+ <RT·endnote>The Arabic translation movement flourished especially under the Abbasids. Syriac Christian scholars had already translated Greek philosophical and medical works into Syriac, and some of these scholars later participated in Arabic translations. The resulting Arabic tradition also incorporated Neoplatonic works and texts falsely attributed to Aristotle, notably the <em>Theology of Aristotle</em>, an adaptation of parts of Plotinus. See Cristina D’Ancona, “Greek Sources in Arabic and Islamic Philosophy,” <em>Stanford Encyclopedia of Philosophy</em>.</RT·endnote>
+ </p>
- </RT·section>
+ <p>
+ One recurring problem was how philosophical demonstration could be reconciled with Islamic theology. Al-Farabi (c. 872−950) held that truth reaches the philosopher as a proof and everyone else as an image of it, with different nations holding different images of the one truth. Avicenna (980−1037) gave Aristotelian and Neoplatonic materials a systematic philosophical form. Ibn al-Haytham (c. 965−1040) argued, with the aid of experiments, that vision depends on light entering the eye rather than on rays emitted by the eye. Al-Ghazali (1058−1111) denied that fire possesses an independent and necessary power to burn cotton, arguing that what appears as natural causation depends at every occasion on God’s act. Ibn Rushd (1126−1198) answered that a demonstrated conclusion cannot conflict with a revealed truth, and that apparent conflicts call for a revision of the textual interpretation.
+ <RT·endnote>Al-Ghazali, <em>Tahāfut al-Falāsifa</em>, discussion 17. The position, termed occasionalism, denies necessary causal efficacy to created things; it need not deny the regular succession of events or the usefulness of ordinary causal descriptions. Its relationship to Hume’s later account of causation is one of resemblance and historical comparison, not simple identity.</RT·endnote>
+ </p>
- <!--------------------------------------------------------------------------------->
- <RT·section id="Section·Appendix_Stirling_Numbers">
- <RT·name>Appendix: Stirling Numbers</RT·name>
+ <p>Ibn Rushd’s commentaries, together with other Arabic philosophical works, entered Latin Europe through translators working in Toledo and elsewhere. The Arabic-Latin translation movements transformed several areas of Latin philosophy, including natural philosophy, psychology, metaphysics, logic, and ethics.
+ <RT·endnote>The Arabic-Latin translation movement was not a single return of Greek philosophy through one city or one author. Important translations were made in Toledo, Sicily, southern Italy, and elsewhere. The influence of Arabic philosophy on Latin Europe was especially strong in natural philosophy, psychology, and metaphysics, but it also reached logic and ethics. See Dag Nikolaus Hasse, “Influence of Arabic and Islamic Philosophy on the Latin West,” <em>Stanford Encyclopedia of Philosophy</em>.</RT·endnote>
+ </p>
- <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>Here the arrangement by date is set aside once, to introduce the question the schoolmen were answering. The specifically medieval form of it was shaped by Porphyry’s <em>Isagoge</em>, an introduction to Aristotle’s <em>Categories</em>. Porphyry famously set aside, for a deeper investigation, the questions of whether genera and species exist in reality or only in thought, whether they are bodies or incorporeal, and whether they exist separately or in sensible things. Boethius then carried these questions into Latin philosophy through two commentaries, and medieval authors spent centuries refining the relations among things, concepts, and the universal terms by which things are named.
+ <RT·endnote>Porphyry, <em>Isagoge</em>, in John Peter Anton and George L. Kustas, eds., <em>Essays in Ancient Greek Philosophy</em>, vol. 2 (Albany: State University of New York Press, 1971), 197−199. Boethius wrote two commentaries on Porphyry’s text, the first based on Marius Victorinus’s translation and the second on his own.</RT·endnote>
+ </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>
+ <p>William of Ockham (c. 1287−1347) gave one of the sharpest late-medieval attempts to dissolve this dialectic. He held that what the many instances of a thing have in common is neither a Form standing above them nor an essence lodged within them, but a sign that stands for all of them.
+ <RT·endnote>William of Ockham, <em>Summa Logicae</em> I.14−17 (c. 1323); in English as <em>Ockham’s Theory of Terms: Part I of the Summa Logicae</em>, trans. Michael J. Loux (Notre Dame: University of Notre Dame Press, 1974). The fuller critique is in the <em>Ordinatio</em> I d.2 qq.4−8. The position is called nominalism, from <em>nomen</em>, a name. Peter Abelard (1079−1142) reached a non-realist account two centuries earlier, while Ockham gave one of the sharpest and most influential late-medieval statements. Ockham’s sign is a concept in the soul, with spoken and written words subordinated to it, so the sign he means is nearer the abstraction of <RT·Counter·read snapshot="Section·Conventio·Symbol" key="counter count"></RT·Counter·read> than the representation is.</RT·endnote>
+ Plato places the explanatory model in an intelligible order distinct from sensible particulars, whereas Ockham denies that there is any independently existing universal of that kind to locate. In the language of <RT·Counter·read snapshot="Section·Conventio·Symbol" key="counter count"></RT·Counter·read>, Ockham keeps the representation and the instances below, and empties the layer above.
+ </p>
- <p>
- To understand their mechanical role, a person must look at the mathematical basis used in each domain.
- </p>
+ <p>Thomas Hobbes (1588−1679) pressed the naturalist argument into the human body. Against the separation of an immaterial mind from an extended body, he treated sensation, imagination, and reasoning as processes belonging to the natural order. Thought, on this account, was not a visitor from a higher realm but something that happened in a body.
+ <RT·endnote>Thomas Hobbes, <em>Leviathan</em> (London, 1651), Introduction and chaps. 1 and 5. In the Introduction Hobbes compares the body to an artificial machine, asking why the heart should not be a spring, the nerves strings, and the joints wheels. In chap. 1 he treats sense as a motion produced in the organ by an external body; in chap. 2 he describes imagination as decaying sense; and in chap. 5 he defines reasoning as a form of reckoning or computation. See also Hobbes, <em>De Corpore</em> (London, 1655), Part I, chap. 1, and Part II on geometry and motion. Hobbes’s materialism does not anticipate a modern computational theory in every detail, but it places bodily sensation, imagination, and reasoning within a natural order rather than assigning them to an immaterial realm.</RT·endnote>
+ </p>
- <RT·section id="Section·Appendix_Stirling_Numbers·Continuous_vs._Discrete_Basis">
- <RT·name>The Continuous vs. Discrete Basis</RT·name>
+ <p>René Descartes (1596−1650) argued that certain knowledge comes from reason reflecting on itself, rather than from the senses which can deceive. The ideas he trusted most were those he regarded as arising from the mind’s own constitution rather than being derived from sensory experience, thus giving Plato a modern form.
+ <RT·endnote>René Descartes, <em>Meditationes de Prima Philosophia</em> (Paris, 1641), Meditations III and V. The position is called <RT·term>rationalism</RT·term>. Descartes held the body to be a machine and animals to be machines entire, while reserving the mind from mechanism; the line he drew there was erased a century later by Julien Offray de La Mettrie, <em>L’Homme Machine</em> (Leyden, 1747).</RT·endnote>
+ John Locke (1632−1704) answered that there are no innate ideas: the mind begins without ideas, and what is in it arrives through sensation and through reflection on what sensation delivers. Yet Locke treated mathematics as demonstrative knowledge of relations among ideas rather than as a direct report of sensation.
+ <RT·endnote>John Locke, <em>An Essay Concerning Human Understanding</em> (London, 1690), Book I against innate ideas, Book II on the two sources, and Book IV chap. 4 on mathematical certainty. The position is called <RT·term>empiricism</RT·term>. Locke’s denial concerns innate ideas, not the mind’s innate capacities for receiving and comparing ideas.</RT·endnote>
+ </p>
- <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>George Berkeley (1685−1753) attempted to dissolve the dialectic by identifying sensible objects with ideas as perceived, rather than treating perception as a report about some further material thing standing behind them. The world as sensed is therefore a world of perceived ideas, but Berkeley does not reduce reality to a private person’s perceptions: the order of nature is secured by God’s perception and is not controlled by individual will. When asked what becomes of the furniture in a room when nobody is there, he answered that God perceives it.
+ <RT·endnote>George Berkeley, <em>A Treatise Concerning the Principles of Human Knowledge</em> (Dublin, 1710), §§3 and 6 for the doctrine, §§28−33 and §146 for the argument reaching God, and §48 for the objects that persist unperceived by any man. Put again, and more accessibly, in <em>Three Dialogues between Hylas and Philonous</em> (London, 1713).</RT·endnote>
</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>David Hume (1711−1776) divided all inquiry into relations of ideas and matters of fact. Hume placed mathematical certainty among the relations of ideas while noting that mathematical certainty belongs to intuition and demonstration rather than to empirical observation.
+ <RT·endnote>David Hume, <em>An Enquiry Concerning Human Understanding</em> (London, 1748), §IV part 1.</RT·endnote>
</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>
+ <p>In 1781 Immanuel Kant (1724−1804) placed mathematics within the conditions of human cognition. He argued that space and time are forms of intuition: space is the condition under which geometry is possible, and time is the condition under which arithmetic can be constructed through succession.
+ <RT·endnote>Immanuel Kant, <em>Kritik der reinen Vernunft</em> (Riga: Hartknoch, 1781), Introduction B14−B17 and the Transcendental Aesthetic. Kant does not merely say that mathematics is a private invention. He argues that space and time are forms of intuition, conditions under which objects can be given to us and mathematical cognition can arise.</RT·endnote>
+ </p>
- <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>Kant’s position remained influential until nineteenth-century geometries challenged the identification of Euclidean space with the necessary structure of human intuition. In the 1820s and 1830s, Nikolai Lobachevsky and János Bolyai developed geometries in which Euclid’s parallel postulate fails. In 1868 Eugenio Beltrami constructed a model of Lobachevskian geometry within Euclidean geometry, establishing a relative-consistency result: if the Euclidean background is consistent, then so is the modeled geometry.
+ <RT·endnote>Nikolai Lobachevsky, “On the Principles of Geometry,” <em>Kazan Messenger</em> (1829−1830); János Bolyai, “Appendix Scientiam Spatii Absolute Veram Exhibens,” published with Farkas Bolyai’s <em>Tentamen</em> (Maros-Vásárhely, 1832); Eugenio Beltrami, “Saggio di interpretazione della geometria non-euclidea,” <em>Giornale di Matematiche</em> 6 (1868): 284−312. Gauss had reached similar results and published none of them. The historical point is not that non-Euclidean geometry simply refuted Kant, but that it forced philosophers to reconsider what Kant’s claims about mathematical intuition could mean.</RT·endnote>
+ This did not by itself refute Kant’s philosophy, but it made the location of mathematical necessity in human spatial intuition much more difficult to defend.
</p>
</RT·section>
- <RT·section id="Section·Appendix_Stirling_Numbers·Second_kind">
- <RT·name>Stirling Numbers of the Second Kind, <RT·math>S(n, k)</RT·math></RT·name>
+ <RT·section counter="Appendix,Appendix Section" id="Section·Appendix·Stirling_Numbers">
+ <RT·name>Stirling Numbers</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:
+ 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>
- <RT·math>t^n = \sum_{k=0}^n S(n,k) t^{\underline{k}}</RT·math>
+ 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>
- 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.
+ To understand their mechanical role, a person must look at the mathematical basis used in each domain.
</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>
+ <RT·section id="Section·Appendix·Stirling_Numbers·Continuous_vs._Discrete_Basis">
+ <RT·name>The Continuous vs. Discrete Basis</RT·name>
- </RT·section>
+ <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>
- <RT·section id="Section·Appendix_Stirling_Numbers·First_kind">
- <RT·name>Stirling Numbers of the First Kind, <RT·math>s(n, k)</RT·math></RT·name>
+ <p>
+ However, in the calculus of finite differences, standard exponents are clumsy. Because the Turing Machine evaluates discrete jumps, the natural basis is the falling factorial, denoted as <RT·math>t^{\underline{n}}</RT·math>:
+ </p>
- <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="Equation" id="Equation·falling-factorial_definition">
+ <RT·name>The falling factorial, the natural basis for discrete differences</RT·name>
+ <RT·Counter·snapshot counter="Equation" snapshot="Equation·falling-factorial_definition"></RT·Counter·snapshot>
+ <RT·math>
+ t^{\underline{n}} = t(t - 1)(t - 2) ⋯ (t - n + 1)
+ </RT·math>
+ <RT·Counter·read snapshot="Equation·falling-factorial_definition" key="counter count step"></RT·Counter·read>
+ </RT·Counter·step>
- <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>
+ 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>
- <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>
+ </RT·section>
- <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>
+ <RT·section id="Section·Appendix·Stirling_Numbers·Second_kind">
+ <RT·name>Stirling Numbers of the Second Kind, <RT·math>S(n, k)</RT·math></RT·name>
- <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>
+ <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>
+
+ <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>
+
+ </RT·section>
+
+ <RT·section id="Section·Appendix·Stirling_Numbers·First_kind">
+ <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="Equation" id="Equation·falling-factorial_in_powers">
+ <RT·name>The falling factorial expanded over standard powers</RT·name>
+ <RT·Counter·snapshot counter="Equation" 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>
+ <RT·Counter·read snapshot="Equation·falling-factorial_in_powers" key="counter count step"></RT·Counter·read>
+ </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>
+ </RT·section>
+ </RT·section>
+
+ </RT·section> <!-- end of Appendix -->
<RT·endnotes></RT·endnotes>
projects / TM-2026 / commitdiff
