Path: csiph.com!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx12.ams4.POSTED!not-for-mail From: Mr Flibble Newsgroups: comp.lang.c,comp.lang.c++ Subject: Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Message-ID: <20220714075236.000000ef@reddwarf.jmc.corp> References: <9fc98d2a-f43f-4463-b41b-fe5747056cebn@googlegroups.com> <1tmdnWTZkrczuVP_nZ2dnUU7_8zNnZ2d@giganews.com> <-bWdnc2EzYm6s1P_nZ2dnUU7_81g4p2d@giganews.com> <20220714051854.00007268@reddwarf.jmc.corp> <4fidnYzcRIhcBlL_nZ2dnUU7_8xg4p2d@giganews.com> Organization: Jupiter Mining Corporation X-Newsreader: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lines: 245 X-Complaints-To: abuse@eweka.nl NNTP-Posting-Date: Thu, 14 Jul 2022 06:52:37 UTC Date: Thu, 14 Jul 2022 07:52:36 +0100 X-Received-Bytes: 13324 Xref: csiph.com comp.lang.c:166702 comp.lang.c++:85167 On Wed, 13 Jul 2022 23:29:53 -0500 olcott wrote: > On 7/13/2022 11:18 PM, Mr Flibble wrote: > > On Wed, 13 Jul 2022 21:55:25 -0500 > > olcott wrote: > > =20 > >> On 7/13/2022 9:21 PM, Richard Damon wrote: =20 > >>> > >>> On 7/13/22 10:08 PM, olcott wrote: =20 > >>>> On 7/13/2022 8:55 PM, Richard Damon wrote: =20 > >>>>> On 7/13/22 9:34 PM, olcott wrote: =20 > >>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote: =20 > >>>>>>> > >>>>>>> On 7/13/22 8:06 PM, olcott wrote: =20 > >>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote: =20 > >>>>>>>>> On 7/13/22 8:19 AM, olcott wrote: =20 > >>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote: =20 > >>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote: =20 > >>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote: =20 > >>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote: =20 > >>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote: =20 > >>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote: =20 > >>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote: =20 > >>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote: =20 > >>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote: =20 > >>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote: =20 > >>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this > >>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago > >>>>>>>>>>>>>>>>>>>> when the article came out. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again. =20 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot > >>>>>>>>>>>>>>>>>>> called Olcott? He keeps > >>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there > >>>>>>>>>>>>>>>>>>> are two guys here who > >>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing > >>>>>>>>>>>>>>>>>>> him. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a > >>>>>>>>>>>>>>>>>>> response; Olcott won't go > >>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him > >>>>>>>>>>>>>>>>>>> completely. Just ignore him; > >>>>>>>>>>>>>>>>>>> =20 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated > >>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very > >>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading computer > >>>>>>>>>>>>>>>>>> scientist. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my > >>>>>>>>>>>>>>>>>> presentation so that everyone here can easily > >>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting > >>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis: > >>>>>>>>>>>>>>>>>> =20 > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would > >>>>>>>>>>>>>>>>> you please stop posting this same thing millions of > >>>>>>>>>>>>>>>>> times? =20 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> For any program H that might determine if programs > >>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some > >>>>>>>>>>>>>>>> input, can pass its own source and its input to H and > >>>>>>>>>>>>>>>> then specifically do the opposite of what H predicts > >>>>>>>>>>>>>>>> P will do. *No H can exist that handles this case* > >>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> It is not verified until it is understood that P and > >>>>>>>>>>>>>>>> H implement the classical halting problem "impossible > >>>>>>>>>>>>>>>> input" template (as shown above) and refutes this > >>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its > >>>>>>>>>>>>>>>> input never terminates normally. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> *This is the key software engineering that I need > >>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that > >>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly > >>>>>>>>>>>>>>>> terminate normally. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The next level of pure software engineering is that > >>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input > >>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the > >>>>>>>>>>>>>>>> case that only the top 5% of software engineers can > >>>>>>>>>>>>>>>> validate this point. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> typedef void (*ptr)(); > >>>>>>>>>>>>>>>> int H(ptr p, ptr i); > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> void P(ptr x) > >>>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>>> =A0=A0 if (H(x, x)) > >>>>>>>>>>>>>>>> =A0=A0=A0=A0 HERE: goto HERE; > >>>>>>>>>>>>>>>> =A0=A0 return; > >>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> int main() > >>>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>>> =A0=A0 Output("Input_Halts =3D ", H(P, P)); > >>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated > >>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion. > >>>>>>>>>>>>>>>> H aborts its simulation on this basis and rejects > >>>>>>>>>>>>>>>> this input as non-halting. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The execution trace of function P() simulated by > >>>>>>>>>>>>>>>> function H() shows: > >>>>>>>>>>>>>>>> (1) Function H() is called from P(). > >>>>>>>>>>>>>>>> (2) With the same parameters to H(). > >>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly > >>>>>>>>>>>>>>>> escape this infinitely recursive simulation. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> *That was all of the software engineering that I need > >>>>>>>>>>>>>>>> validated* > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of > >>>>>>>>>>>>>>>> software engineering > >>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halti= ng_problem_proofs_refuted_on_the_basis_of_software_engineering > >>>>>>>>>>>>>>>> =20 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it. > >>>>>>>>>>>>>>> The CORRECT version of (3) looks ALL the way through > >>>>>>>>>>>>>>> the loop, which includes in H, and will find the > >>>>>>>>>>>>>>> condtional there. =20 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot > >>>>>>>>>>>>>> possibly terminate normally. (I have better words now). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> =20 > >>>>>>>>>>>>> > >>>>>>>>>>>>> Except that the program represented by the input, P(P) > >>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0. =20 > >>>>>>>>>>>> > >>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL* > >>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that > >>>>>>>>>>>> its correctly simulated input cannot possibly terminate > >>>>>>>>>>>> normally. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> =20 > >>>>>>>>>>> > >>>>>>>>>>> WHAT Change of subject? > >>>>>>>>>>> =20 > >>>>>>>>>> > >>>>>>>>>> IT IS A VERIFIED FACT THAT > >>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its > >>>>>>>>>> correctly > >>>>>>>>>> simulated input cannot possibly terminate normally. > >>>>>>>>>> > >>>>>>>>>> The only possible correct rebuttal must show all the steps > >>>>>>>>>> of exactly how the input to simulating halt decider H(P,P) > >>>>>>>>>> does terminate normally when H correctly simulates this > >>>>>>>>>> input. > >>>>>>>>>> > >>>>>>>>>> Since I already proved that this is false entirely on the > >>>>>>>>>> basis of verified fact this is impossible. > >>>>>>>>>> > >>>>>>>>>> This requires that a function called in essentially > >>>>>>>>>> infinite recursion to return a value to its caller this is > >>>>>>>>>> impossible. > >>>>>>>>>> > >>>>>>>>>> Most everyone here knows that every function called in > >>>>>>>>>> infinite recursion never returns any value to its caller. > >>>>>>>>>> There is no gibberish that you can say that would convince > >>>>>>>>>> them otherwise. =20 > >>>>>>>>> That can't be a verified fact because the opposite is a > >>>>>>>>> verified fact, that the CORRECT simulation of the input to > >>>>>>>>> H(P,P), which is the correct simulation of P(P) will > >>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does. =20 > >>>>>>>> > >>>>>>>> I already gave Paul N a great explanation of that on > >>>>>>>> comp.theory. I won't be able to see your reply there because > >>>>>>>> I have you blocked there. > >>>>>>>> > >>>>>>>> My explanation to wjj even sums it up better: > >>>>>>>> > >>>>>>>> On 7/13/2022 3:51 PM, olcott wrote: =20 > >>>>>>>> =A0> On 7/13/2022 3:47 PM, wij wrote: =20 > >>>>>>>> =A0>> The property that an arbitrary program P will finish > >>>>>>>> =A0>> running or not is=A0 determined by running P as an > >>>>>>>> =A0>> independent program =20 > >>>>>>>> > >>>>>>>> Because that would require that a halt decider must sometimes > >>>>>>>> make its > >>>>>>>> halt status decision on a basis other than the actual > >>>>>>>> behavior of its actual input that long standing > >>>>>>>> misconception has been refuted. =20 > >>>>>>> > >>>>>>> No, because all the behavior of that program exists will be > >>>>>>> encoded in the representation of the program given to the > >>>>>>> decider. =20 > >>>>>> > >>>>>> The reason that I stop talking to you is that you make false > >>>>>> assumptions that are utterly impervious to all reasoning. > >>>>>> > >>>>>> It is a verified fact that the input that is correctly > >>>>>> simulated by H(P,P) cannot possibly terminate normally. It is > >>>>>> also a verified fact that the direct execution of P(P) does > >>>>>> terminate normally. > >>>>>> > >>>>>> It is also common knowledge that the correct simulation of a > >>>>>> program is a correct measure of the behavior of this program. > >>>>>> > >>>>>> This conclusively proves that H(P,P) is correct to reject its > >>>>>> input as non-halting and the behavior of a non-input cannot > >>>>>> possibly contradict this. > >>>>>> > >>>>>> =20 > >>>>> > >>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly > >>>>> simulate the input (since it aborts it to return 0) so it > >>>>> doesn't MATTER that if it was a different program it wouldn't > >>>>> be able to simulate to a final state. =20 > >>>> > >>>> > >>>> That you (and others) continue to lack the technical capacity to > >>>> comprehend that H does correctly predict that its complete and > >>>> correct simulation of its input would never result in this input > >>>> terminating normally is far less than no rebuttal at all. Until > >>>> you (and others) gain this technical capacity there is no sense > >>>> continuing a dialogue. =20 > >>> > >>> How is it correct when H(P,P) sayts P(P) is non-halting when a > >>> direct exectuion of P(P) or a correct simulation by simualte(P,P) > >>> (where P still calls the previous H) show that it halts. =20 > >> > >> Most everyone here can see: (from my updated simplified paper) > >> It is a verified fact that the input that is correctly simulated by > >> H(P,P) cannot possibly terminate normally. =20 > >=20 > > I have shown that a simulating halting decider needn't be recursive > > in nature thus can terminate normally. You are wrong on all fronts. > >=20 > > /Flibble > > =20 >=20 > You have shown that you don't fully understand the concept of=20 > unreachable code. Of course I understand the concept of unreachable code in fact I recall giving you several examples of it. /Flibble