Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Fred. Zwarts" Newsgroups: comp.theory,sci.logic Subject: Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Date: Sun, 26 May 2024 12:47:58 +0200 Organization: A noiseless patient Spider Lines: 74 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 26 May 2024 12:47:58 +0200 (CEST) Injection-Info: dont-email.me; posting-host="d39f79cd12346f2604f25f3fb37a1545"; logging-data="3558320"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+LUJW+Sz0eunGAsQjNPXO8" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:VNd6CPME5uoOpafjnQBvdtL1cv0= In-Reply-To: Content-Language: en-GB Bytes: 4358 Op 25.mei.2024 om 19:56 schreef olcott: > On 5/25/2024 7:52 AM, Richard Damon wrote: >> On 5/25/24 12:28 AM, olcott wrote: > > > >>>> That you H, by just needing to be a "Pure Funtion" is not >>>> necessarily the computatinal eqivalent of a Turing Machine. >>>> >>> >>> Totally moot for the subject line. >> >> Nope, ESSENTINTIAL. I am not asking you to change your definition, >> just accept its consequences. >> > > 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 many reviewers 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. > > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > *This is only talking about the H/D c function pairs* > The claim is that the simulation of D does not halt, because it call to H does not halt. The simulation does not even reach line 04, so the simulation does not even see that D contradicts H. The claim, therefore does not change if lines 04 and 05 are removed. What remains is that D is a parameter duplicator, so that H can simulate itself. The result is that each H in the infinite set of H finds that H is not halting. A clear indication that a simulating decider is not a good idea.