Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Can you see that D correctly simulated by H remains stuck in
 recursive simulation?
Date: Thu, 23 May 2024 21:22:49 -0500
Organization: A noiseless patient Spider
Lines: 113
Message-ID: <v2otlq$24vfk$1@dont-email.me>
References: <v2nsvh$1rd65$2@dont-email.me> <v2oreb$1tsmo$4@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 May 2024 04:22:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="853a48eea7a3e841565c364baea8e5bf";
	logging-data="2260468"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX192bVtQ2+k6FCpUiyVU4499"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gf9mdBVTJuG8GjNPF6drK2yUz8M=
Content-Language: en-US
In-Reply-To: <v2oreb$1tsmo$4@i2pn2.org>
Bytes: 5744

On 5/23/2024 8:44 PM, Richard Damon wrote:
> 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?
> 

In other words you are requiring that the x86 instructions of D
(and possibly H) be simulated incorrectly and/or in the wrong order.

> 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 I require it to be a pure function
(a) Disallows you use of static local data.
(b) Does mean that H is Turing computable even if you don't understand 
this.

> 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"?
> 

How you can fail to understand that this <is> such a template?
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

> 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 

This post is only talking about the above specified H, you keep
forgetting that.

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

For simulator H it is plenty 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.
> 

You just claimed that you do not understand that the Linz example is a 
template. That does not seem like an honest mistake to me.

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

You just claimed that you do not understand that the Linz example is a 
template. That does not seem like an honest mistake to me.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer