Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!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: Wed, 21 May 2025 07:16:56 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <ea0cb2fa3ea3f333f5ce2747328ac2a4406c9b89@i2pn2.org>
References: <1e4f1a15826e67e7faf7a3c2104d09e9dadc6f06.camel@gmail.com>
 <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> <100e840$1e4fq$1@dont-email.me>
 <100eapg$1ee1a$2@dont-email.me> <100f87j$1k6ri$1@dont-email.me>
 <100jl2b$2m26r$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 21 May 2025 11:17:37 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1294485"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <100jl2b$2m26r$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5289
Lines: 89

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.