Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Can you see that D correctly simulated by H remains stuck in
 recursive simulation?
Date: Fri, 24 May 2024 07:14:11 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2psq3$1v3p0$2@i2pn2.org>
References: <v2nsvh$1rd65$2@dont-email.me> <v2oreb$1tsmo$4@i2pn2.org>
 <v2pr71$29rhj$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 May 2024 11:14:11 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2068256"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v2pr71$29rhj$2@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5381
Lines: 92

On 5/24/24 6:46 AM, Fred. Zwarts wrote:
> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>> On 5/23/24 1:04 PM, olcott wrote:
>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>> 00       int H(ptr p, ptr i);
>>> 01       int D(ptr p)
>>> 02       {
>>> 03         int Halt_Status = H(p, p);
>>> 04         if (Halt_Status)
>>> 05           HERE: goto HERE;
>>> 06         return Halt_Status;
>>> 07       }
>>> 08
>>> 09       int main()
>>> 10       {
>>> 11         H(D,D);
>>> 12         return 0;
>>> 13       }
>>>
>>> The above template refers to an infinite set of H/D pairs where D is
>>> correctly simulated by pure function H. This was done because many
>>> reviewers used the shell game ploy to endlessly switch which H/D pair
>>> was being referred to.
>>>
>>> *Correct Simulation Defined*
>>>     This is provided because every reviewer had a different notion of
>>>     correct simulation that diverges from this notion.
>>>
>>>     A simulator is an x86 emulator that correctly emulates at least one
>>>     of the x86 instructions of D in the order specified by the x86
>>>     instructions of D.
>>>
>>>     This may include correctly emulating the x86 instructions of H in
>>>     the order specified by the x86 instructions of H thus calling H(D,D)
>>>     in recursive simulation.
>>>
>>> *Execution Trace*
>>>     Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, 
>>> and 03
>>>     of D. This invokes H(D,D) again to repeat the process in endless
>>>     recursive simulation.
>>>
>>
>> Questions:
>>
>> By your definiton of "Correct Simulation", you do realize that you 
>> have broken connection between the simulaiton not completing and the 
>> program described by the input not halting?
>>
>> Also, you do realize that by your requirement on H just being a "pure 
>> function" that does NOT say that you H qualified to be the 
>> computational equivalent for a Turing Machine?
>>
>> That due to your "strange" definition of what D is, you are putting 
>> yourself outside of the grounds of "Computation Theory", as that deals 
>> with the behavior of specific PROGRAMS, and not the "Program 
>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>
>> Also, your "templagte D" is NOT built per either the Linz or Sipser 
>> rules, as both of those had D built with a COPY of H, which is one of 
>> your problems with a "Pure Function" as the equivelent. You have shown 
>> that your H fails to meet the requirements of a Turing Machine 
>> equivalent, as you can't (or it seems you can't) make equivalent 
>> copies, where all copies always give the same answer for the same 
>> inputs. This is a fundamental property of Turing Machines, which is 
>> why just bing a "Pure Function" isn't good enough.
>>
>> These issus need to be handled or acknowledged, before agreement on 
>> your question, as you have shown a history of taking a statement and 
>> twisting it (perhaps not intentionally, but because you don't 
>> understand what was being communicated) so we need to have a firm 
>> understand of what you mean and evidence that you accept the 
>> limititation causes by your altered definitions from the problem that 
>> you initially claimed to have started on.
>>
>> Of course, it also means that even if/when you get your agreement, you 
>> are no closer to your halting proof, as you have shown that you 
>> undestand that you conditions actually tell you NOTHING about the 
>> actual behavior of halting.
>>
> 
> If olcott wants to be closer to the Linz or Sipser rules, he could do so 
> with a small modification: use different names for H. Use H1 when called 
> by main and use H2 when called by D. H1 and H2 are not required to be 
> exact copies of each other, but only to be functionally equivalent. By 
> doing so, a lot of useless discussions could be avoided.

Yes, he could, but when it was proposed that we make D call its own 
identical copy of H, he rejected it saying it wasn't allowed.

Of course, the reason it isn't allowed is that it makes his method of 
detecting that D calls (a copy of) H not work and his whole method falls 
apart, as his H just never answers.