Re: How to write a self-referencial TM?

On 5/21/25 12:33 AM, olcott wrote:

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.
 

THen show HOW.
Remember, the decider is a FIXED program, and as such will always do the same thing for a given input.
And thus the program at the input, that is built on that calling is also a fixed program that will always do the same thing for a given input.
Your problem is that in your argument, you "forget" to make your decider actually be a program, and thus the input isn't a program either, and thus your whole argument is a category error.
If you want to disagree, show what instruction ACTUALLY SIMULATED per the x86 language, or the requirements of the C language, that differed between the simulation by HHH and the dirrect execution.
Note, in both of these requirements, a call instruction goes into the routine called and performs the instrutios therein.
Thus the simulation of the called simulator shows HOW that HHH simulates, and the actual instructions it preforms, NOT the simulated results that it is seeing.
Thus your "8000 page" result. Where was the difference?
Your failure to show just proves that you are just lying.