Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: How to write a self-referencial TM?
Date: Sun, 18 May 2025 19:19:55 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <7246883b9123e12707f337d071f387648e40fee5@i2pn2.org>
References: <1e4f1a15826e67e7faf7a3c2104d09e9dadc6f06.camel@gmail.com>
 <1002akp$2i4bk$2@dont-email.me>
 <479eebef3bd93e82c8fe363908b254b11d15a799.camel@gmail.com>
 <1002jkk$2k00a$3@dont-email.me>
 <05e306f20fcb7c88c497e353aaecd36b30fc752a.camel@gmail.com>
 <10053hb$3759k$1@dont-email.me>
 <879b3c552bad9da9885e41a298b570c92bef1aaf.camel@gmail.com>
 <10061h6$3de5f$1@dont-email.me>
 <4bce5af2b2b8cd198af611e5d8d56598cab15b0a.camel@gmail.com>
 <10067ok$3ib39$1@dont-email.me>
 <e63d3083ddf6b9ab172cc24c07155410d81ce5b4.camel@gmail.com>
 <1007lrp$3r388$1@dont-email.me>
 <0cbe88d46c63af596e4d2ad6a846e61b7efb14bb.camel@gmail.com>
 <1008fhf$53u$1@dont-email.me>
 <cd31647abcc33f0978415df34ec2c8d41d886591.camel@gmail.com>
 <100a7e4$efgi$1@dont-email.me>
 <f94f006b40c3ca204d41be9b4507280a3a4fc17b.camel@gmail.com>
 <100aolc$hq2u$1@dont-email.me>
 <943f3512f1c253f770eb41519145d4159c0cd6aa.camel@gmail.com>
 <100dhiv$167g2$1@dont-email.me> <100dl69$16uka$1@dont-email.me>
 <100dloh$16vdn$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 May 2025 23:23:55 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="946645"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <100dloh$16vdn$2@dont-email.me>
Content-Language: en-US

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é
>>
>>
> 
>