Re: How to write a self-referencial TM?

Op 16.mei.2025 om 17:47 schreef olcott:

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.

You didn't. The input specifies a halting program, but the programmer of HHH made it blind by programming a premature abort, so that it does not see the full behaviour that is specified in the input. In particular, it skips the part where the abort was coded that makes the program halt.
That HHH is blind for a part of the specification, does not mean that the specification is not there.
Apparently, Olcott does not know how to bring anything against this reasoning, either because he does not understand it, or because it disturbs his dreams too much. Therefore, he ignores it, and just repeat his claims again saying that nobody has refuted his proof.
Please, face the facts, not your dreams. Come out of rebuttal mode and try to think.