Deutsch English Français Italiano |
<v2qrpt$2fesr$4@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
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: Fri, 24 May 2024 15:03:09 -0500 Organization: A noiseless patient Spider Lines: 117 Message-ID: <v2qrpt$2fesr$4@dont-email.me> References: <v2nsvh$1rd65$2@dont-email.me> <v2oreb$1tsmo$4@i2pn2.org> <v2pr71$29rhj$2@dont-email.me> <v2qhef$2dpfr$4@dont-email.me> <v2qihr$1vblq$3@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 22:03:10 +0200 (CEST) Injection-Info: dont-email.me; posting-host="853a48eea7a3e841565c364baea8e5bf"; logging-data="2603931"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18p7ltr6jsNNH5KBuFpJfpe" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:DcB/N0XrTPcuq0YcDe01TyBXScw= Content-Language: en-US In-Reply-To: <v2qihr$1vblq$3@i2pn2.org> Bytes: 6444 On 5/24/2024 12:25 PM, Richard Damon wrote: > On 5/24/24 1:06 PM, olcott wrote: >> On 5/24/2024 5: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. >> >> *That violates this* >> For any program H that might determine whether programs halt, a >> "pathological" program D, called with some input, can pass its own >> source and its input to H and then specifically do the opposite of >> what H predicts D will do. No H can exist that handles this case. >> https://en.wikipedia.org/wiki/Halting_problem >> > > Nope, D, that pathological program, is supposed to be built with its own > COPY of the decider, since to BE a program, it needs a complete source set. > OFF-TOPIC OF THE SUBJECT LINE OFF-TOPIC OF THE SUBJECT LINE OFF-TOPIC OF THE SUBJECT LINE OFF-TOPIC OF THE SUBJECT LINE OFF-TOPIC OF THE SUBJECT LINE OFF-TOPIC OF THE SUBJECT LINE OFF-TOPIC OF THE SUBJECT LINE OFF-TOPIC OF THE SUBJECT LINE -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer