From: Thomas Walker Lynch Date: Mon, 20 Jul 2026 08:41:52 +0000 (+0000) Subject: completes for now the computational theoretic derivation of TTCAM X-Git-Url: https://git.reasoningtechnology.com/%5B%5E?a=commitdiff_plain;h=63c2b53103431a8d503be176ce92ce6e4b39ec01;p=TM-2026 completes for now the computational theoretic derivation of TTCAM --- diff --git a/document/book/TM-2026.html b/document/book/TM-2026.html index 8f840b4..b529b10 100644 --- a/document/book/TM-2026.html +++ b/document/book/TM-2026.html @@ -528,7 +528,7 @@

Given that the number of symbols expands with 2^ϡ, where ϡ is the number of bits in a word, doing a reverse string operation with a Turing Machine becomes impractical even for small word widths. So it isn't the infinite tape, per sé that binds the Turing Machine to the abstract, but it is this attribute of enumerating symbols on branches that does so.

-

The total number of steps for reversing an n character string:

+

The total number of steps for reversing an n symbol string:

@@ -633,7 +633,7 @@

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 a proportional increase in the number of states for the reverse string controller when the number of symbols, symbols that could have been ignored for control purposes, is expanded.

-

The TTCA computation theoretic Turing Machine

+

The computation theoretic TTCA Machine

A goal of the computation theorist in defining a Turing Machine is to make the math concise and elegant. However, the goal of the computer architect is to define a machine that is intuitive to design and test, and that performs well. Perhaps if a computer architect were to define the computation theoretic Turing Machine, this change in emphasis would favor a different definition.

@@ -657,7 +657,7 @@

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.

-

The TTCA Turing Machine fixed part

+

The TTCA Machine fixed part

@@ -715,7 +715,7 @@ HF = \{QF{·}\mathtt{unspecified\_decision}\}
-

The TTCA Turing Machine variables

+

The TTCA Machine variables

@@ -730,7 +730,7 @@

g: is the gate register.

-

The TTCA Turing Machine programmable part

+

The TTCA Machine programmable part

@@ -779,7 +779,7 @@
-

The TTCA Turing Machine in total

+

The TTCA Machine in total

@@ -808,9 +808,9 @@
-

TTCA computation theoretic TM executor directions

+

Computation theoretic TTCA Machine executor

-

To execute the programmed TTCA Turing Machine, a person must maintain the current machine variables MV 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.

+

To execute the programmed TTCA Machine, a person must maintain the current machine variables MV 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.

Initialization

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:

@@ -841,16 +841,16 @@

-

The TTCA programmed string reverse

+

The TTCA Machine programmed string reverse

-

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.

+

Because the TTCA Machine 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.

-

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 g exclusively to scan for control symbols (the protocol terminator 'SP', the EOM marker 'E', and the read marker '*'). It explicitly avoids reading unspecified memory by pushing a bounding 'SP' symbol rightward before advancing. When a payload character is encountered, the controller executes a read_d action, blind to the symbol's actual value, and carries that opaque data across the tape to deposit it using write_d.

+

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 a proportional increase in state definitions just to ferry symbols across the tape. When the number of symbols increases exponentially when represented binary words that are expanded, there is an explosion in the number of states. The TTCA Machine does not have this property. It uses the gate register g exclusively to scan for control symbols (the protocol terminator 'SP', the EOM marker 'E', and the read marker '*'). When a payload symbol is encountered, the controller executes a read_d action, placing the value into a data register, which is not examined for decision making purposes.

-

Here is the programmed controller for the TTCA string reverse. Because actions (λ) are bound to states rather than transitions, reading and stepping are distinct states, resulting in a strictly serialized execution.

+

Here is the programmed controller for the TTCA Machine string reverse. Because actions (λ) are bound to states rather than transitions, reading and stepping are distinct states, resulting in a strictly serialized execution.

- # TTCA String Reverse + # TTCA Machine String Reverse # input: (σ ∈ Σ)* EOM (starting on the leftmost cell) # output: SP* EOM (σ ∈ Σ in reverse)* EOR @@ -879,7 +879,7 @@ δ: Q·Fetch_0 - # Phase 2: Fetch the next unprocessed character and check boundaries. + # Phase 2: Fetch the next unprocessed symbol and check boundaries. Q·Fetch_0: λ: left δ: @@ -954,7 +954,7 @@ (EOM: Q·Fetch_0) Q·Return_0 - # Phase 6: Final character carry and clean halt. + # Phase 6: Final symbol carry and clean halt. Q·Place_Last: λ: write_σ(SP) δ: @@ -987,9 +987,9 @@ Q·Done - HU reverse machine + TTCAM reverse machine -

With data payload examination removed from the controller, long strings of states with a few decision points emerge. There is a loop on the left, and a tail leading to done, on the right. The number of states and arcs is a constant independent of how much data is to be reversed.

+

With data payload examination removed from the controller, long strings of states with a few decision points emerge. There is a loop on the left, and a tail leading to done on the right. The number of states and arcs is a constant independent of how much data is to be reversed.

void TTCA·reverse_string() { @@ -1000,7 +1000,7 @@ write_σ(EOR); while(true){ - // The Fetch Pivot: Locate the next unprocessed character + // The Fetch Pivot: Locate the next unprocessed symbol left(); read_g(); while(g == EOM || g == SP){ @@ -1031,7 +1031,7 @@ while(g != EOM){left(); read_g();} } - // Final Character Chain: Handle the last payload without a return sweep + // Final Symbol Chain: Handle the last payload without a return sweep write_σ(SP); right(); read_g(); @@ -1045,7 +1045,7 @@ } -

The total number of steps for reversing an n character string using the TTCA architecture:

+

The total number of steps for reversing an n symbol string using the TTCA Machine:

@@ -1057,9 +1057,173 @@
-

This machine spends a lot of time shuttling the head between two context area. One with the original string, and one with the result reverse machine. This suggests that a two head version would be faster.

+

This machine spends a lot of time shuttling the head between two context areas. One context area 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:

+ + # TTCA Two-Head String Reverse + # input: (σ ∈ Σ)* EOM (starting on the leftmost cell) + # output: SP* EOM (σ ∈ Σ in reverse)* EOR + + halt: Q·Done + + table: + # Phase 1: Both heads scan right to the EOM pivot + Q·initial: + λ: read_g(0) + δ: + (EOM: Q·Check_Empty) + Q·Scan_Right_0 + + Q·Scan_Right_0: + λ: right(0) + δ: + Q·Scan_Right_1 + + Q·Scan_Right_1: + λ: right(1) + δ: + Q·initial + + # Phase 2: Setup pointers for reading and writing + Q·Check_Empty: + λ: status(0) + δ: + (on_leftmost: Q·Empty_Setup_1) + Q·Setup_Write_1 + + Q·Empty_Setup_1: + λ: right(1) + δ: + Q·Write_EOR_Done + + Q·Setup_Write_1: + λ: right(1) + δ: + Q·Setup_Write_2 + + Q·Setup_Write_2: + λ: left(0) + δ: + Q·Copy_Read + + # Phase 3: The Linear Copy Loop + Q·Copy_Read: + λ: read_d(0) + δ: + Q·Copy_Status + + Q·Copy_Status: + λ: status(0) + δ: + (on_leftmost: Q·Copy_Last_Erase) + Q·Copy_Erase + + Q·Copy_Erase: + λ: write_σ(0, SP) + δ: + Q·Copy_Write + + Q·Copy_Write: + λ: write_d(1) + δ: + Q·Copy_Advance_1 + + Q·Copy_Advance_1: + λ: right(1) + δ: + Q·Copy_Advance_0 + + Q·Copy_Advance_0: + λ: left(0) + δ: + Q·Copy_Read + + # Phase 4: Final Symbol and Clean Halt + Q·Copy_Last_Erase: + λ: write_σ(0, SP) + δ: + Q·Copy_Last_Write + + Q·Copy_Last_Write: + λ: write_d(1) + δ: + Q·Copy_Last_Advance + + Q·Copy_Last_Advance: + λ: right(1) + δ: + Q·Write_EOR_Done + + Q·Write_EOR_Done: + λ: write_σ(1, EOR) + δ: + Q·Done + + + TTCAM 2 hd reverse machine +

The number of states has dropped from 24 to 17, while the speed increase is dramatic, with the former quadratic performance becoming linear performance. The total number of steps for reversing an n symbol long string using a two-head TTCA architecture:

+ +
+ + \text{steps} = + \begin{cases} + 4 & \text{if } n = 0 \\ + 9n + 4 & \text{if } n \ge 1 + \end{cases} + +
+ +

The two paths through the state machine, and the one loop, translate well into code:

+ + + void TTCA·reverse_string_2_head() { + // Phase 1: Both heads scan right to the EOM pivot + read_g(0); + while(g != EOM){right(0); right(1); read_g(0);} + + // Phase 2: Setup pointers or short-circuit on empty string + status(0); + if(g == on_leftmost){ + right(1); + write_σ(1, EOR); + return; + } + + right(1); + left(0); + + // Phase 3: The Linear Copy Loop + while(true){ + read_d(0); + status(0); + + // Break out to process the final character + if(g == on_leftmost) break; + + write_σ(0, SP); + write_d(1); + right(1); + left(0); + } + + // Phase 4: Final character, advance, and clean halt + write_σ(0, SP); + write_d(1); + right(1); + write_σ(1, EOR); + + return; + } + + +

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 multiple tape or multi-head Turing Machine on a single-tape machine incurs a quadratic time penalty J. Hartmanis and R. E. Stearns, "On the computational complexity of algorithms," Transactions of the American Mathematical Society 117 (1965): 285-306.. Hopcroft and Ullman formalize this relationship in their text John E. Hopcroft and Jeffrey D. Ullman, Introduction to Automata Theory, Languages, and Computation (Reading: Addison Wesley, 1979), 292.. The quadratic term in the step formula that disappeared when we added the second head was the quadratic penalty incurred by shuttling the head between two context areas.

+ +

Thus, adding heads to a Turing Machine tape, or adding tapes with their own heads, can prevent head shuttling. For the two reverse machines, the time complexity of the longest compute time input of length n dropped from O(n^2) to O(n). Because the answer to a specific question of time complexity changes, the transformation is computation theoretic consequential. Furthermore, real computers have multiple pointers into different memory contexts, making the multi-head Turing Machine a more suitable model for our purposes.

+ +

This is not a general method for improving performance complexity. A quadratic performance improvement is not strong enough to change the asymptotic performance if there are higher-order terms in a step count polynomial. Also, eliminating shuttling will never reduce a linear step count to a constant time step count; the simple reason is that n is unbounded, while adding k heads can only divide the work by a fixed constant k. Consequently, while the transformation is consequential for this specific asymptotic bound, it cannot change the broader time complexity class.

+ + The Turing Machine architecture/organization

@@ -3041,13 +3205,13 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos

Suppose we unmount a tape from a halted Turing Machine, say machine T0, and then mount the tape on another Turing Machine as input, say machine T1. Suppose we do this so that machine T1 may calculate the length of the output made by the first machine. When we do this, we run into some problems.

-

Firstly, for a conventional Turing Machine, the tape that is mounted on T1 will be infinite, so no computational T1 machine will be able to process it unless there is a message on the tape telling T1 where the end of the input is. For our TTCA machines, if T0 starts with a null tape, and then expands it, and T0 is computational, then at the time T0 halts, the tape will be finite. T1 can then use the continuation of stepping beyond rightmost to know that it has processed all of its input.

+

Firstly, for a conventional Turing Machine, the tape that is mounted on T1 will be infinite, so no computational T1 machine will be able to process it unless there is a message on the tape telling T1 where the end of the input is. For our TTCA Machines, if T0 starts with a null tape, and then expands it, and T0 is computational, then at the time T0 halts, the tape will be finite. T1 can then use the continuation of stepping beyond rightmost to know that it has processed all of its input.

-

If a Turing Machine does nothing then halts, it will implement an identity relationship between input and output. If we do not want the input given to a machine to 'bleed through', we will have to erase it. A computational TTCA Machine starting from a null tape can only produce finite tapes, so T1 can erase whatever T0 writes to the tape. However, if we are analyzing, instead of running the TTCA machine, we might discover that the tape length would be infinite if the machine could be run. We know that if we pass an infinite tape to a computational TTCA, it would not be able to erase the tape. Fortunately we can derive this fact through analysis and proof without having to run the computational machine to see if it erased the tape.

+

If a Turing Machine does nothing then halts, it will implement an identity relationship between input and output. If we do not want the input given to a machine to 'bleed through', we will have to erase it. A computational TTCA Machine starting from a null tape can only produce finite tapes, so T1 can erase whatever T0 writes to the tape. However, if we are analyzing, instead of running the TTCA Machine, we might discover that the tape length would be infinite if the machine could be run. We know that if we pass an infinite tape to a computational TTCA Machine, it would not be able to erase the tape. Fortunately we can derive this fact through analysis and proof without having to run the computational machine to see if it erased the tape.

Hence if we allow for infinite inputs, we should add an 'erase-to-end-of-tape' command to our machines, so that the computational machines may leave a tape with only their outputs on them. Our erase-to-end-of-tape command will be executed in a single step.

-

Once an input tape is mounted, T0 is a computational TTCA machine given a finite tape, its output is a finite tape, and that is taken to be the input for T1.

+

Once an input tape is mounted, T0 is a computational TTCA Machine given a finite tape, its output is a finite tape, and that is taken to be the input for T1.

T0 is required to provide meta information about the length of the active area. This approach is known as in-band signaling. Because length information is mixed with the data.

@@ -3063,7 +3227,7 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos

A system for creating the appearance of many tapes over a single tape is called a memory manager or a memory allocation system. It is typically better to use one of these and multiple tape models rather than solving the problem of moving objects around in memory in an ad hoc manner.

-

Here is an important question for the TTCA model: is it possible to define a memory manager that creates the appearance of multiple expanding tapes over the top of a single expandable tape? This problem is solved for managing files on a hard disk. However, all current file systems break at some point when pumped. So the question being asked here is equivalent to asking if a files system can be made without such architectural limits. The answer to this is yes, it is possible, as we will see in a later chapter of this book.

+

Here is an important question for the TTCA Machine model: is it possible to define a memory manager that creates the appearance of multiple expanding tapes over the top of a single expandable tape? This problem is solved for managing files on a hard disk. However, all current file systems break at some point when pumped. So the question being asked here is equivalent to asking if a files system can be made without such architectural limits. The answer to this is yes, it is possible, as we will see in a later chapter of this book.

Hence there are multiple conventions we may use for implementing the abstraction of multiple tapes on a tape machine. Multiple tape machine are equivalent in power to one tape machines, but sometimes they are easier to think about.

@@ -3348,11 +3512,11 @@ Now suppose defining a Turing Machine that initially has the head on the leftmos

1. When attempting to step into the inactive area, instead keep a counter for the number of steps the machine would take. Only allow reads or writes or head movement when the counter is no longer needed due to the head having moved back into the active area.

-

2. Write an alphabet character and change the inactive area traversed into an active area.

+

2. Write an alphabet symbol and change the inactive area traversed into an active area.

-

The TTCA Turing Machine variation

+

The TTCA Machine variation

-

The active area on the tape can grow at most by one unit for each machine step. This largest growth occurs when the Turing Machine steps right and writes an alphabet character in every visited state. This means that for computational machines that start with a tape that has a finite input (active area), the output (active area) will be finite. This also means that space complexity can never be larger than time complexity.

+

The active area on the tape can grow at most by one unit for each machine step. This largest growth occurs when the Turing Machine steps right and writes an alphabet symbol in every visited state. This means that for computational machines that start with a tape that has a finite input (active area), the output (active area) will be finite. This also means that space complexity can never be larger than time complexity.

A fixed value is one that is provided with a Turing Machine definition, and does not change while the machine runs. Suppose we chose a fixed length Turing Machine tape. The tape would then have a rightmost cell. That cell would have no right neighbor, but would have a left neighbor. We would also add another error, that of right from rightmost. This error would be invoked when the controller attempted to step right from the rightmost cell.

diff --git a/document/book/TTCA_2_hd_reverse.png b/document/book/TTCA_2_hd_reverse.png new file mode 100644 index 0000000..4856f54 Binary files /dev/null and b/document/book/TTCA_2_hd_reverse.png differ diff --git a/document/book/trick_YAML_TTCA.yaml b/document/book/trick_YAML_TTCA.yaml new file mode 100644 index 0000000..1bc75bb --- /dev/null +++ b/document/book/trick_YAML_TTCA.yaml @@ -0,0 +1,74 @@ +# TTCA String Reverse - Structural Diagram Generator +# The read/write/move values are dummies designed solely to draw the arcs. +input: ' ' +blank: ' ' +start state: Q·initial +table: + # Phase 1 + Q·initial: + 'E': {R: Q·Setup_EOR} + ' ': {R: Q·Search_EOM_0} + Q·Search_EOM_0: + ' ': {R: Q·initial} + Q·Setup_EOR: + ' ': {R: Q·Write_EOR} + Q·Write_EOR: + ' ': {R: Q·Fetch_0} + + # Phase 2 + Q·Fetch_0: + ' ': {R: Q·Fetch_1} + Q·Fetch_1: + 'E': {R: Q·Check_Boundary} + 'S': {R: Q·Check_Boundary} + ' ': {R: Q·Read_Data} + Q·Check_Boundary: + 'L': {R: Q·Done} + ' ': {R: Q·Fetch_0} + Q·Read_Data: + ' ': {R: Q·Check_Last_Char} + Q·Check_Last_Char: + 'L': {R: Q·Place_Last} + ' ': {R: Q·Place_SP} + + # Phase 3 + Q·Place_SP: + ' ': {R: Q·Carry_0} + Q·Carry_0: + ' ': {R: Q·Carry_1} + Q·Carry_1: + 'O': {R: Q·Drop} + ' ': {R: Q·Carry_0} + + # Phase 4 + Q·Drop: + ' ': {R: Q·Advance_EOR_0} + Q·Advance_EOR_0: + ' ': {R: Q·Advance_EOR_1} + Q·Advance_EOR_1: + ' ': {R: Q·Return_0} + + # Phase 5 + Q·Return_0: + ' ': {R: Q·Return_1} + Q·Return_1: + 'E': {R: Q·Fetch_0} + ' ': {R: Q·Return_0} + + # Phase 6 + Q·Place_Last: + ' ': {R: Q·Carry_Last_0} + Q·Carry_Last_0: + ' ': {R: Q·Carry_Last_1} + Q·Carry_Last_1: + 'O': {R: Q·Drop_Last} + ' ': {R: Q·Carry_Last_0} + Q·Drop_Last: + ' ': {R: Q·Advance_EOR_Last_0} + Q·Advance_EOR_Last_0: + ' ': {R: Q·Advance_EOR_Last_1} + Q·Advance_EOR_Last_1: + ' ': {R: Q·Done} + + Q·Done: +