<p>If we view the <RT·code>empty</RT·code> symbol from within the definition of machine B, it is a category error. It is a sequence element not a container. Even if it were allowed that a position within a sequence were a container and thus could have the property of being empty, the symbol represents that there is no symbol in the very location it is found. Hence, to ascribe an appropriate meaning to the <RT·code>empty</RT·code> symbol, the entire system must be kept including the mapping to machine A, then the empty symbol found on machine B means that if machine A were used instead, the same location in the tape sequence would be an empty set. However, this feels unsatisfactory, because in all other respects, machine B is a perfectly well defined Turing Machine all by itself.</p>
- <p>Going back to Turing's moniker of <RT·code>blank</RT·code>, does not bring the focus solely to machine B, because the original paper by Turing states the definition of <RT·code>blank</RT·code> meaning "no symbol", as was already discussed. Calling it <RT·code>blank</RT·code> is merely the same name colored by the engineering of wood pulp. However, there is a pleasing property of the blank, i.e. the <RT·code>empty</RT·code> symbol, that is valuable and unique to it. It prints as a space in diagrams given in text books, and Turing Machine simulators. There is an analogous symbolic system that also has this characteristic, and is being leveraged in these situations: the ASCII hex 20, called SP. It prints as a space leaving an area of the paper it is printed on blank. Perhaps a better name for the ersatz <RT·code>empty</RT·code> symbol is <RT·code>SP</RT·code>.</p>
+ <p>Going back to Turing's moniker of <RT·code>blank</RT·code> does limit the focus solely to machine B, because the original paper by Turing states the definition of <RT·code>blank</RT·code> meaning "no symbol", as was already discussed. Calling it <RT·code>blank</RT·code> is merely the same name colored by the engineering of wood pulp. However, there is a pleasing property of the blank, i.e. the <RT·code>empty</RT·code> symbol, that is valuable and unique to it. It prints as a space in diagrams given in text books and in the output of Turing Machine simulators. There is an analogous symbolic system that also has this characteristic, and is being leveraged in these situations: the ASCII hex 20, called SP. It prints as a space leaving an area of the paper it is printed on blank. Perhaps a better name for the ersatz <RT·code>empty</RT·code> symbol is <RT·code>SP</RT·code>.</p>
<p>There is more to consider about the former <RT·code>blank</RT·code>, former <RT·code>empty</RT·code>, now <RT·code>SP</RT·code> symbol. Computational theorists often describe a two-step process. First, a Turing Machine writes a string to be studied onto a tape initially filled with all <RT·code>SP</RT·code> symbols; second, the tape is moved to another Turing Machine whose purpose is to recognize a property of the string being studied. In this process, a tape is used as a communication medium, so it follows that communication theory can be applied to this messaging scenario. Messages sent on a channel must be formatted so they can be placed on the channel and later recovered. The specification for such structuring is called a communication <RT·term>protocol</RT·term>. The protocol implies a higher authority, as both the sender and the receiver must have knowledge of the same designed-in protocol. In a sense, a protocol is the meta-message sent before the message itself.</p>
<p>A common technique programmers use for embedding strings with terminators within other strings is to embed escape characters. This is another in-band protocol, and it is inefficient. The escape sequences grow exponentially with nesting levels. Also, such strings with embedded escape sequences cannot be interpreted without knowledge of the intended nesting level of the string author, which requires the interpreter of the string to know the author's intentions.</p>
- <p>For the modified computational Turing machine presented later in this chapter, there will be a separate control alphabet of predefined symbols, as for the Hopcroft-Ullman interpretation. However, so as to support recursion, and because the current scheme does not achieve protocol guarantees, the predefined alphabet will be part of the alphabet <RT·math>Σ</RT·math> rather than distinct from it. Programmers then must explicitly design communication protocols that suit the problems they are working on, and those protocols become opaque for examination by a higher authority. Note that this does not exclude a programmer ssing <RT·code>SP</RT·code> as an EOM marker, rather it removes the embedding of that protocol from the Turing Machine definition.</p>
+ <p>For the modified computational Turing machine presented later in this chapter, there will be a separate control alphabet of predefined symbols, as for the Hopcroft-Ullman interpretation. However, so as to support recursion, and because the current scheme does not achieve protocol guarantees, the predefined alphabet will be part of the alphabet <RT·math>Σ</RT·math> rather than distinct from it. Programmers then must explicitly design communication protocols that suit the problems they are working on, and those protocols become opaque for examination by a higher authority. Note that this does not preclude a programmer from using <RT·code>SP</RT·code> as an EOM marker, rather it removes the embedding of that protocol from the Turing Machine definition.</p>
<h2>The <RT·code>unspecified</RT·code> symbol</h2>
<ol>
<li><strong>Fixed global default (<RT·math>δF_0</RT·math>):</strong> Selects the rule that matches the value in the gate register. There is only one rule in this set; it compares the gate register to the <RT·code>unspecified</RT·code> symbol, then transitions to the <RT·code>unspecified_decision</RT·code> state.</li>
<li><strong>Programmed Conditional (<RT·math>δ_1</RT·math>):</strong> Selects the transition rule that matches the current state and the value of the gate register.</li>
- <li><strong>Programmed Default (<RT·math>δ_2</RT·math>):</strong> If no programmed conditional next state rule is found, selects the default transition rule that matches the current state.</li>
+ <li><strong>Programmed Default (<RT·math>δ_2</RT·math>):</strong> If no conditional next state rule is found, selects the default transition rule that matches the current state.</li>
<li><strong>Global Fallback (<RT·math>δ_3</RT·math>):</strong> An unconditional transition of last resort if no prior layer provides a valid next state.</li>
</ol>
<p>There is a mechanical procedure for converting a Moore Machine into a Mealy Machine, and the reverse. Two such converted machines are equally expressive. Making the read operation an explicit action, instead of having it implied by a state transition, increases the number of states in a controller, and consequently the number of steps that must be taken. However, the new machine can do in two steps anything the former machine could do in one; consequently, this change affects the multiplier constant on the linear term of the step count formula but does not change the computation complexity class determined from such a step count. The layers of next-state functions can be collapsed into one layer, where the missing arguments are filled in with all possible unused values. This potentially increases the number of state transition arcs that must be specified, but the state transition logic and the number of states remain unchanged. Partitioning the machine definition by separation of concerns does not change the total specification. Hence, these modifications are computationally inconsequential.</p>
- <h3>The TTCA Turing Machine fixed part</h3>
+<h3>The TTCA Turing Machine fixed part</h3>
<div style="margin-left: 2em;">
<RT·math>
- MF = (QF, ΣF, AF, δF_0)
+ MF = (QF, ΣF, AF, δF_0, HF)
</RT·math>
</div>
<p>In any state if the <RT·code>g</RT·code> register holds the symbol <RT·math>\mathtt{ΣF{·}unspecified}</RT·math>, then the next state will be <RT·math>\mathtt{QF{·}unspecified\_decision}</RT·math>, independent of all other defined next state transitions.</p>
+ <p>The set of predefined halting states (only one):</p>
+ <div style="margin-left: 2em;">
+ <RT·math>HF = \{QF{·}\mathtt{unspecified\_decision}\}</RT·math>
+ </div>
<h3>The TTCA Turing Machine variables</h3>
<div style="margin-left: 2em;">
<RT·math>
- MP = (QP, ΣP, λP, δ_1, δ_2, δ_3)
+ MP = (QP, ΣP, λP, δ_1, δ_2, δ_3, HP)
</RT·math>
</div>
<p>This is the transition of last resort. It is unconditional, the next state becomes <RT·math>q_1</RT·math>.</p>
+ <p>A set of programmer defined halting states:</p>
+ <div style="margin-left: 2em;">
+ <RT·math>HP</RT·math>
+ </div>
+
+
<h3>The TTCA Turing Machine in total</h3>
<div style="margin-left: 2em;">
<RT·math>
- M = (Q, Σ, AF, λP, δ)
+ M = (Q, Σ, AF, λP, δ, H)
</RT·math>
</div>
<RT·math>δ = [δF_0 | δ_1 | δ_2 | δ_3]</RT·math>
</div>
-
+ <p>The complete set of halting states, uniting the fixed predefined states and the programmed states:</p>
+ <div style="margin-left: 2em;">
+ <RT·math>H = HF \cup HP</RT·math>
+ </div>
<h2>TTCA computation theoretic TM executor directions</h2>
- <p>To execute the programmed TTCA Turing Machine, a person must maintain the current machine variables <RT·math>MV</RT·math> and evaluate the programmed logic in an infinitely repeating two-phase cycle. Because this is a Moore-style architecture, the execution of an action is isolated from the evaluation of the next state transition.</p>
+ <p>To execute the programmed TTCA Turing Machine, a person must maintain the current machine variables <RT·math>MV</RT·math> and evaluate the programmed logic in an repeating two-phase cycle, until a halting state is reached. Because this is a Moore-style architecture, the execution of an action is isolated from the evaluation of the next state transition.</p>
<h3>Initialization</h3>
- <p>Before the first cycle begins, a tape selected and mounted. The read/write head is positioned over the leftmost tape cell. The machine variables are initialized as follows:</p>
+ <p>Before the first cycle begins, a tape is selected and mounted. The read/write head is positioned over the leftmost tape cell. The machine variables are initialized as follows:</p>
<ul>
<li>The current state <RT·math>q</RT·math> is set to <RT·math>QF{·}\mathtt{initial}</RT·math>.</li>
<li>The data register <RT·math>d</RT·math> is initialized to hold the <RT·math>ΣF{·}\mathtt{unspecified}</RT·math> symbol.</li>
</ol>
<h3>Continuation</h3>
- <p>After the state transition phase completes, the cycle repeats. The executor returns to Phase 1 using the newly updated state <RT·math>q</RT·math>. This loop continues until the machine transitions into a designated programmed halting state or triggers the <RT·math>QF{·}\mathtt{unspecified\_decision}</RT·math> trap, which requires external architectural resolution.</p>
+ <p>If the machine reaches a point where there is no next state, or the head has walked off of the tape, the machine hangs. If, after the state transition phase completes, the current state is a member of <RT·math>H</RT·math>, the machine halts. Otherwise the cycle repeats.
+ </p>
-<h2>The TTCA programmed string reverse</h2>
+ <h2>The TTCA programmed string reverse</h2>
- <p>Because the TTCA architecture cleanly separates the data path from the control path, and isolates actions into a Moore-style programmed controller, it is possible to definitively prove that reversing a string does not require inspecting the payload. The programmed controller only needs to recognize the structural boundaries of the data protocol.</p>
+ <p>Because the TTCA architecture cleanly 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.</p>
- <p>In the Hopcroft and Ullman machine, the controller was forced to read the data payload, branching into parallel states. If the input alphabet were expanded from binary to the full ASCII set, that controller would require an explosion of state definitions just to ferry characters across the tape. The TTCA machine avoids this entirely. It uses the gate register <RT·math>g</RT·math> exclusively to scan for control symbols (the <RT·code>unspecified</RT·code> space, the EOM marker 'E', and the read marker '*'). When a payload character is encountered, the controller executes a <RT·math>\mathtt{read\_d}</RT·math> action, blind to the symbol's actual value, and carries that opaque data across the tape to deposit it using <RT·math>\mathtt{write\_d}</RT·math>.</p>
+ <p>With a Turing Machine, the controller is forced to read the data payload and branch into parallel states. If the input alphabet were expanded from binary to the full ASCII set, that controller would require proportional increase in state definitions just to ferry characters across the tape. The TTCA machine avoids this entirely. It uses the gate register <RT·code>g</RT·code> exclusively to scan for control symbols (the protocol terminator 'SP', the EOM marker 'E', and the read marker '*'). It explicitly avoids reading <RT·code>unspecified</RT·code> memory by pushing a bounding 'SP' symbol rightward before advancing. When a payload character is encountered, the controller executes a <RT·code>read_d</RT·code> action, blind to the symbol's actual value, and carries that opaque data across the tape to deposit it using <RT·code>write_d</RT·code>.</p>
<p>Here is the programmed controller for the TTCA string reverse. Because actions (<RT·math>λ</RT·math>) are bound to states rather than transitions, reading and stepping are distinct states, resulting in a strictly serialized execution.</p>
- ```yaml
+ <RT·code>
# TTCA String Reverse
- # The payload alphabet is completely abstracted. The machine operates
- # solely on structural markers.
-
- start state: q_scan_end_read
-
+ # message: (σ ∈ Σ)* EOM
+ # output: SP* EOM (σ ∈ Σ in reverse)* EOR
+
+ halt: Q·Done
+
table:
- # Phase 1: Scan to the rightmost end and place the EOM terminator 'E'
- q_scan_end_read:
- action: read_g
- gate:
- unspecified: q_scan_end_mark
- next: q_scan_end_step
-
- q_scan_end_step:
- action: right
- next: q_scan_end_read
-
- q_scan_end_mark:
- action: write_σ('E')
- next: q_find_next_read
-
- # Phase 2: Walk left to find the next unprocessed payload symbol
- q_find_next_read:
- action: read_g
- gate:
- '*' : q_find_next_step
- 'E' : q_find_next_step
- unspecified: q_cleanup_read # All data processed, begin cleanup
- next: q_load_d # Payload encountered
-
- q_find_next_step:
- action: left
- next: q_find_next_read
-
- # Phase 3: Pick up the unknown data symbol and mark its original location
- q_load_d:
- action: read_d
- next: q_mark_read
-
- q_mark_read:
- action: write_σ('*')
- next: q_carry_right_read
-
- # Phase 4: Carry the opaque data rightward over payload and markers
- q_carry_right_read:
- action: read_g
- gate:
- unspecified: q_drop_d
- next: q_carry_right_step
-
- q_carry_right_step:
- action: right
- next: q_carry_right_read
-
- # Phase 5: Deposit the data at the new end of the sequence
- q_drop_d:
- action: write_d
- next: q_find_next_step # Return to Phase 2
-
- # Phase 6: Erase the structural markers, leaving only the reversed string
- q_cleanup_read:
- action: read_g
- gate:
- '*' : q_cleanup_erase
- 'E' : q_cleanup_erase
- unspecified: done
- next: done
-
- q_cleanup_erase:
- action: write_σ('unspecified')
- next: q_cleanup_step
-
- q_cleanup_step:
- action: left
- next: q_cleanup_read
+ # Phase 1: Scan right to EOM and initialize the EOR marker.
+ Q·initial:
+ λ: read_g
+ δ:
+ (EOM: Q·Setup_EOR)
+ Q·Search_EOM_0
+
+ Q·Search_EOM_0:
+ λ: right
+ δ:
+ Q·initial
+
+ Q·Setup_EOR:
+ λ: right
+ δ:
+ Q·Write_EOR
+
+ Q·Write_EOR:
+ λ: write_σ(EOR)
+ δ:
+ Q·Fetch_0
+
+ # Phase 2: Fetch the next unprocessed character and check boundaries.
+ Q·Fetch_0:
+ λ: left
+ δ:
+ Q·Fetch_1
+
+ Q·Fetch_1:
+ λ: read_g
+ δ:
+ (EOM: Q·Fetch_0)
+ (SP: Q·Fetch_0)
+ Q·Fetch_2
+
+ Q·Fetch_2:
+ λ: read_d
+ δ:
+ Q·Fetch_3
+
+ Q·Fetch_3:
+ λ: status
+ δ:
+ (on_leftmost: Q·Place_Last)
+ Q·Place_SP
+
+ # Phase 3: Mark the location and carry the opaque data rightward.
+ Q·Place_SP:
+ λ: write_σ(SP)
+ δ:
+ Q·Carry_0
+
+ Q·Carry_0:
+ λ: right
+ δ:
+ Q·Carry_1
+
+ Q·Carry_1:
+ λ: read_g
+ δ:
+ (EOR: Q·Drop)
+ Q·Carry_0
+
+ # Phase 4: Deposit the data and advance the EOR boundary.
+ Q·Drop:
+ λ: write_d
+ δ:
+ Q·Advance_EOR_0
+
+ Q·Advance_EOR_0:
+ λ: right
+ δ:
+ Q·Advance_EOR_1
+
+ Q·Advance_EOR_1:
+ λ: write_σ(EOR)
+ δ:
+ Q·Return_0
+
+ # Phase 5: Return left to the EOM to begin the next fetch cycle.
+ Q·Return_0:
+ λ: left
+ δ:
+ Q·Return_1
+
+ Q·Return_1:
+ λ: read_g
+ δ:
+ (EOM: Q·Fetch_0)
+ Q·Return_0
+
+ # Phase 6: Final character carry and clean halt.
+ Q·Place_Last:
+ λ: write_σ(SP)
+ δ:
+ Q·Carry_Last_0
+
+ Q·Carry_Last_0:
+ λ: right
+ δ:
+ Q·Carry_Last_1
+
+ Q·Carry_Last_1:
+ λ: read_g
+ δ:
+ (EOR: Q·Drop_Last)
+ Q·Carry_Last_0
+
+ Q·Drop_Last:
+ λ: write_d
+ δ:
+ Q·Advance_EOR_Last_0
+
+ Q·Advance_EOR_Last_0:
+ λ: right
+ δ:
+ Q·Advance_EOR_Last_1
+
+ Q·Advance_EOR_Last_1:
+ λ: write_σ(EOR)
+ δ:
+ Q·Done
+ </RT·code>
- done:
- action: no_op
- ```
- <p>By relying on the unconditional next state transition to handle payload characters, the controller logic remains perfectly static regardless of the size or complexity of the programmed alphabet <RT·math>ΣP</RT·math>. The programmer is freed from managing the data, allowing him to focus entirely on the structural organization of the algorithm.</p>
<RT·chapter>The Turing Machine architecture/organization</RT·chapter>
projects / TM-2026 / commitdiff