Re: How to write a self-referencial TM?

On 5/18/25 6:08 PM, olcott wrote:

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

On 2025-05-18 14:57, olcott wrote:
>

TM description is a misnomer in that they never
merely describe some of the details of the TM
(as all mere descriptions always do).
>
Instead they specify ALL of the details, thus have
always actually been a TM specification language more
commonly understood as the source-code for a TM.

>
You seem to be getting bogged down in a relatively inconsequential terminological issue here which contributes nothing to the overall debate.
>

 It is not inconsequential. It is the misnomer that an
input is merely described that enables people to believe
that DDD simulated by HHH must have the same behavior
as DDD simulated by HHH1 even when they SPECIFY different
behavior.

No, it just says you don't understand the Term-of-Art meaning of the word "Described" as used here.

 

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.

"Typically", but not in this case.
That is the danger of trying to use "common" meanings for Terms-of-Art.
One key point is that in this case, "Description" allows for the use of "Higher Level Terms" perhaps the "Turing Machine Description Language" that the decider/UTM uses includes short-cuts to call up a macro-library of predefined operations that might have been encoded in the actual program, but described with the higher level description. (The key is such higher level descriptions must reflect a specific set of instrucitosn that are equivalent to how the actual machine was coded.

 

When people talk about passing a UTM a description of a TM, it is understood that this refers to a *complete* description rather than a partial one.
>

 If this was true then they would understand that
the input to HHH(DDD) specifies behavior that is
not the same behavior as DDD().

Then the description is incorrect.
As the requirements are that the description specify that program, and thus the behavior of that program.
This is your problme with you non-program input, the description of it doesn't actually fully describe the behavior of the call to HHH. Saying it calls whatever is at that location is *NOT* a sufficient description, as that doesn't specify what that actually does.

 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 They would understand that no matter how many
instructions of DDD are emulated by HHH according
to the rules of the x86 language that this
correctly emulated DDD cannot possibly halt.

But "simulated by HHH" is not the criteria of a description, or more precisely, HHH must define a way to describe as an input the exact behavior of every program, including the DDD that is based on that HHH, and that is what needed to have been given to that HHH. So the "behavior" of that input must be the behavior of the PROGRAM DDD when run (and that program by the proof calls the HHH that is claimed to be correctly answering).
All you are doing is admitting that your setup is just not meeting the requirments, and all your claims are thus just pathoolgoical lies.

 

If you prefer the term 'specification', you're free to use it, but there's no sense in which 'description' is a misnomer.
>
André
>
>