Re: How to write a self-referencial TM?

On 5/16/2025 2:45 AM, Mikko wrote:

On 2025-05-15 20:08:54 +0000, wij said:
 

On Thu, 2025-05-15 at 14:15 -0500, olcott wrote:

On 5/15/2025 1:49 PM, wij wrote:

On Thu, 2025-05-15 at 17:08 +0100, Mike Terry wrote:

On 14/05/2025 18:53, wij wrote:

On Wed, 2025-05-14 at 12:24 -0500, olcott wrote:

On 5/14/2025 11:43 AM, wij wrote:

On Wed, 2025-05-14 at 09:51 -0500, olcott wrote:

On 5/14/2025 12:13 AM, wij wrote:

Q: Write a turing machine that performs D function (which calls itself):
>
void D() {
     D();
}
>
Easy?
>
>

>
That is not a TM.

>
It is a C program that exists. Therefore, there must be a equivalent TM.
>

To make a TM that references itself the closest
thing is a UTM that simulates its own TM source-code.

>
How does a UTM simulate its own TM source-code?
>

>
You run a UTM that has its own source-code on its tape.

>
What is exactly the source-code on its tape?
>

>
Every UTM has some scheme which can be applied to a (TM & input tape) that is to be simulated.
The
scheme says how to turn the (TM + input tape) into a string of symbols that represent that
computation.
>
So to answer your question, the "source-code on its tape" is the result of applying the UTM's
particular scheme to the combination (UTM, input tape) that is to be simulated.
>
If you're looking for the exact string symbols, obviously you would need to specify the exact
UTM
being used, because every UTM will have a different answer to your question.
>
>
Mike.

>
People used to say UTM can simulate all TM. I was questing such a UTM.
Because you said "Every UTM ...", so what is the source of such UTM?
>
>

>
The TM description language is more accurately
referred to as the TM specification language.
>
A UTM is a hypothetical thing that is specified
to have some source source-code that it operates
on yet none of the details of this are ever
fully elaborated.
>
That is why I needed to use the x86 language
as a fully specified proxy. With my x86utm
operating system we make a 100% concrete
simulating termination analyzer such that
zero of the details are "abstracted away".
>
It is the details that have been "abstracted away"
by the abstractions that cause the conventional
halting problem proofs to be insufficiently
understood.

>
Unfortunely, refuting HP suggests halting decider is a real thing.
Proving by "abstracted away" the real part?

 In which way can a proof that a halting decider does not exist
suggest that a halting decider is a real thing?
 The concept of halting decider is a real concept in the same sense
as Arsitotle's concept of unicorn is a real concept but does that
mean that a unicorn and a halting decider are real things?
 

I have only refuted the standard proof.
A halt decider HHH having a domain of DD and DDD
correctly maps its inputs to the actual behavior
that they actually specify.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer