Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon 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 13:25:15 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 24 May 2024 17:25:15 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2076346"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US Bytes: 6708 Lines: 118 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. Since your curreent defined program envionment (incorrectly) mixes the address and name space of the program being decided on and the decider, the act of making a copy will entail giving the copy a new name. Then we can pass to your decider H, the COMPLETE source code for the progrma D, INCLUDING its copy of the decider, which has been given a new name to handle your error of putting them into a common name space. Since in the actual problem, the decider is given just the description of the program to decide, and that doesn't need to be "compiled" into its namespace, but can just be interpreted in its own environment, there is no need for the renaming. And, as the article says, it has been shown impossible to do that, so if you want to refute that, you need to recreate EXACTLY what it describes, and show how you get the right answer. Changing the definition of the problem doesn't show a refutation of the origianal problem.