Re: How to write a self-referencial TM?

Op 21.mei.2025 om 21:49 schreef olcott:

On 5/21/2025 2:43 PM, Fred. Zwarts wrote:

Op 21.mei.2025 om 06:33 schreef olcott:

On 5/19/2025 7:29 AM, Mikko wrote:

On 2025-05-19 04:07:11 +0000, olcott said:
>

On 5/18/2025 10:21 PM, André G. Isaak wrote:

On 2025-05-18 16:08, olcott wrote:

On 5/18/2025 4:58 PM, André G. Isaak wrote:

>

In English, both 'description' and 'specification' can refer to something which is either complete or only partial.
>

>
Description typically means partial and
specification typically means complete.
>

>
I don't think you'll find that most people will agree with this. That might be your usage.
>
The problem is that 'specification' has already been used in much of this discussion to mean something else. A TM's specification outlines what it is that that TM is supposed to do without going into the details of how it actually does it.
>

>
When you refer to the spec of an algorithm you
are correct. When you refer to the every single
step of the exact behavior that a finite string
specified you are wrong.
>

For example, the specification of a Parity Decider would be a TM takes a representation of a natural number as its initial tape content and accepts it only if it is even.
>
The description of that machine, on the other hand, would describe what the alphabet of this machine is, what it's state transitions are, etc. i.e. it would give all the information necessary to actually construct the machine.
>
André
>

>
I already know how TM machine descriptions actually work.
>
DDD simulated by HHH1 has the exact same
sequence of steps as the directly executed DDD().
>
People here think that when DDD is simulated by
the same simulator that it calls (thus causing
recursive simulation) that DDD must have the same
behavior as DDD simulated by HHH1 that DDD does
not call.

>
The behaviour of DDD is the behaviour that DDD specifies. If some
program simulaates differently then it does not simulate the
behaviour of DDD.
>

>
>
It's not that hard really.
When an input calls its own simulator with itself as input
THIS DOES CHANGE ITS BEHAVIOR.
>

>
There is only one DDD that uses the algorithm of only one HHH. How can that be different?

 Its over-your-head.
You are so indoctrinated with the infallible word
of textbook that you disagree with the verified
facts of actual execution traces.

That is your usual reply when you don't understand the rebuttal. You think it is enough and then repeat the claim with the addition that nobody has shown any errors in your claim. That is only because you dream that you are infallible and don't need to read and think about what I say. You are unwilling to learn, because you trust that your dreams are true.
But the verifiable facts are that the one and only input for HHH specifies a halting program and even the traces you mention do not even show one single difference whit the simulation of HHH1 that shows the halting behaviour. HHH halts before any difference has been seen in the traces.
If you have no counter arguments, it still stands that there is no change in specified behaviour, only HHH is unable to show that specified behaviour.