Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #85167
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| 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> (permalink) |
| References | (17 earlier) <I4CdndFs1ZY651L_nZ2dnUU7_8zNnZ2d@giganews.com> <S4LzK.367289$ssF.239028@fx14.iad> <Xf2dnQq8xI0AGFL_nZ2dnUU7_8zNnZ2d@giganews.com> <20220714051854.00007268@reddwarf.jmc.corp> <4fidnYzcRIhcBlL_nZ2dnUU7_8xg4p2d@giganews.com> |
| Organization | Jupiter Mining Corporation |
| Date | 2022-07-14 07:52 +0100 |
Cross-posted to 2 groups.
On Wed, 13 Jul 2022 23:29:53 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/13/2022 11:18 PM, Mr Flibble wrote:
> > On Wed, 13 Jul 2022 21:55:25 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/13/2022 9:21 PM, Richard Damon wrote:
> >>>
> >>> On 7/13/22 10:08 PM, olcott wrote:
> >>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
> >>>>> On 7/13/22 9:34 PM, olcott wrote:
> >>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
> >>>>>>>
> >>>>>>> On 7/13/22 8:06 PM, olcott wrote:
> >>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
> >>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
> >>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
> >>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
> >>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
> >>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
> >>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
> >>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
> >>>>>>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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;
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would
> >>>>>>>>>>>>>>>>> you please stop posting this same thing millions of
> >>>>>>>>>>>>>>>>> times?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Output("Input_Halts = ", 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_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
> >>>>>>>>>>>>>> possibly terminate normally. (I have better words now).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Except that the program represented by the input, P(P)
> >>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
> >>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
> >>>>>>>>>>>> its correctly simulated input cannot possibly terminate
> >>>>>>>>>>>> normally.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> WHAT Change of subject?
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 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:
> >>>>>>>> > On 7/13/2022 3:47 PM, wij wrote:
> >>>>>>>> >> The property that an arbitrary program P will finish
> >>>>>>>> >> running or not is determined by running P as an
> >>>>>>>> >> independent program
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>> No, because all the behavior of that program exists will be
> >>>>>>> encoded in the representation of the program given to the
> >>>>>>> decider.
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> 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.
> >>>>
> >>>>
> >>>> 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.
> >>>
> >>> 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.
> >>
> >> 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.
> >
> > I have shown that a simulating halting decider needn't be recursive
> > in nature thus can terminate normally. You are wrong on all fronts.
> >
> > /Flibble
> >
>
> You have shown that you don't fully understand the concept of
> unreachable code.
Of course I understand the concept of unreachable code in fact I recall
giving you several examples of it.
/Flibble
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: "C: Everyone's favourite programming language isn't a programming language" Albert Arkwright <Albert.Arkwright@gmail.com> - 2022-07-11 22:13 +0100
H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-11 18:14 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Freethinker <freethinker@mymail.com> - 2022-07-12 16:14 +0200
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 20:49 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-12 22:26 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 21:29 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-12 22:39 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 21:52 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 07:51 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 07:19 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-13 18:27 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 19:51 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 19:06 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:20 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 20:34 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:55 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 21:08 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 22:21 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 21:55 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 05:18 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 23:27 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 07:53 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-14 05:43 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:08 -0400
Re: H(P,P) is pure software engineering that correctly refutes the Muttley@dastardlyhq.com - 2022-07-14 16:06 +0000
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 23:29 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 07:52 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-14 05:49 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:12 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 17:48 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:07 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem om@iki.fi (Otto J. Makela) - 2022-07-18 17:51 +0300
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 22:29 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-13 19:41 -0700
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem - Olcott <polcott2@gmail.com> - 2022-07-13 20:03 -0700
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 21:55 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-14 22:04 -0700
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Jens Schweikhardt <usenet@schweikhardt.net> - 2022-07-13 21:08 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Juha Nieminen <nospam@thanks.invalid> - 2022-07-12 09:52 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Vir Campestris <vir.campestris@invalid.invalid> - 2022-07-12 11:27 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-12 13:01 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Manu Raju <MR@invalid.invalid> - 2022-07-12 22:19 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" [Olcott] olcott <NoOne@NoWhere.com> - 2022-07-12 21:04 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Juha Nieminen <nospam@thanks.invalid> - 2022-07-13 10:02 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Muttley@dastardlyhq.com - 2022-07-13 15:24 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Manu Raju <MR@invalid.invalid> - 2022-07-13 19:00 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-13 15:31 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-12 14:29 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-12 14:46 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:48 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Richard Damon <Richard@Damon-Family.org> - 2022-07-12 21:45 -0400
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-17 08:18 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:45 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Richard Damon <Richard@Damon-Family.org> - 2022-07-12 21:39 -0400
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:45 -0500
csiph-web