Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott 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 23:28:24 -0500 Organization: A noiseless patient Spider Lines: 171 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 25 May 2024 06:28:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="010db72b80f31f696ef17c51994f71bb"; logging-data="2883357"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19wWY8/tVJx7bgU4oRdjGKa" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:Hme+qM7sP+Gu2rem6mtFbzk6vPE= Content-Language: en-US In-Reply-To: Bytes: 8353 On 5/24/2024 6:20 PM, Richard Damon wrote: > On 5/24/24 6:20 PM, olcott wrote: >> On 5/24/2024 4:39 PM, olcott wrote: >>> On 5/24/2024 4:03 PM, Richard Damon wrote: >>>> On 5/24/24 4:01 PM, olcott wrote: >>>>> On 5/24/2024 12:25 PM, Richard Damon wrote: >>>>>> On 5/24/24 1:10 PM, olcott wrote: >>>>>>> On 5/24/2024 2:37 AM, Fred. Zwarts wrote: >>>>>>>> Op 23.mei.2024 om 19:04 schreef olcott: >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> Of course this depends very much on the exact meaning of >>>>>>>> 'correct simulation', or 'correctly emulating'. >>>>>>> >>>>>>> Not when these are defined above. >>>>>>> >>>>>>>> E.g., take the call to H(p, p). If H recognizes that it is a >>>>>>>> call to a H with the same algorithm as is it using itself, and >>>>>>>> it knows that itself returns a certain integer value K, than it >>>>>>>> can be argued that it is a correct emulation to substitute the >>>>>>>> call to H with this integer value K, which is assigned to >>>>>>>> Halt_Status. Then the simulation of D can proceed to line 04. >>>>>>>> What we need is an exact definition of 'correct simulation', in >>>>>>>> this >>>>>>> >>>>>>> No, you simply need to pay complete attention to the fact that this >>>>>>> has already been provided. >>>>>>> >>>>>>> I have been over the exact same issue with dozens and dozen of >>>>>>> people >>>>>>> though hundreds and hundreds of messages over two years. >>>>>> >>>>>> Excpet that we have two contradictory definitions present, >>>>> >>>>> Yes you have a definition of simulation where the x86 machine >>>>> language of D is simulated incorrectly or in the wrong order. >>>> >>>> Nope. The UTM definition still simulates EVERY x86 machine language >>>> instruction of D simulated correctly in the exact order. The added >>>> requirement is that we look at a simulation that is never aborted. >>> >>> H is a pure function that always returns 56 at some point other >>> than that H is isomorphic to a UTM. >>> >> >> I have learned from decades as a software engineer that complexity >> is only manageable when it is isolated and minimized. >> >> It is impossible to correctly understand termination analyzer H until >> after one first has 100% perfectly complete and total understanding of >> pure function simulator H/D pairs. >> > > > So, do you agree with my comments about what you actual definitons are, > and what they imply? > No I only agree that you are doing everything that you can to derail an honest dialogue and it cannot possibly succeed against the basis of my raw facts basis. > 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. > That your definition of "Correct Simulation" differs from that used in > Computation Theory, Totally moot for the subject line. > and thus the fact that H does abort its simulation > means it is NOT a "UTM equivalent" and that your aborted correct > simulation not reaching a final state is not =, by itself, proof that > the machine represented by the input is non-halting. > The easily verified fact that for the infinite set of H/D pairs where D is correctly simulated by pure function H that no D ever reaches its own line 06 and halts. It is like I say red cars are red in color and you disagree by saying blue cars are not red in color. > That you definition of "Correct Simulation" means that H actually > simulated a call to H by going into H and looking at those instructions, *YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE* *YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE* *YOU KEEP READING THINGS INTO MY SPEC THAT ARE JUST NOT THERE* H is exactly a UTM except that it eventually halts and returns 56 even on non-halting inputs. Think of each H as counting the number of instructions that it simulates and then stopping. > and not switch to looking at the machine the simulation being simulated > is simulating. > > I will also add, that you agree that if you get the agreement that if H > can do this, then you will produce an actual H that meets the > requirements, and not just claim that it must be trivial to write, and > such example program actually gives the claimed answer. > Until you understand that D correctly simulated by pure function H never halts we can never get to the next step. > You agree that your funky "Infinite set of H/D pairs" is NOT what Linz > or Sipser were using in their proof, and that you H and D are not built > fully in conformance to the sample machines in the proofs. > Once you understand that H is correct about D proving that embedded_H is correct about ⟨Ĥ⟩ is easy. Until then it remains impossible > > If you don't agree to these interpreations, a necessary precondition to > coming to an agreement on what H sees, is to reach the agreement on what > hte conditions imply and what those conditions actually are. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer