Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #85100 > unrolled thread
| Started by | Albert Arkwright <Albert.Arkwright@gmail.com> |
|---|---|
| First post | 2022-07-11 22:13 +0100 |
| Last post | 2022-07-12 07:45 -0500 |
| Articles | 20 on this page of 55 — 15 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-13 23:27 -0500 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <4fidnY3cRIinBlL_nZ2dnUU7_8xg4p2d@giganews.com> |
| In reply to | #85164 |
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
>
No you have not.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-14 07:53 +0100 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <20220714075312.00002d5a@reddwarf.jmc.corp> |
| In reply to | #85165 |
On Wed, 13 Jul 2022 23:27:38 -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
> >
> No you have not.
Yes I have: see my post "An idea for a simulating halt decider" in
comp.theory.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 05:43 -0500 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <8L-dnc-yKYzwblL_nZ2dnUU7_81j4p2d@giganews.com> |
| In reply to | #85168 |
On 7/14/2022 1:53 AM, Mr Flibble wrote:
> On Wed, 13 Jul 2022 23:27:38 -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
>>>
>> No you have not.
>
> Yes I have: see my post "An idea for a simulating halt decider" in
> comp.theory.
>
> /Flibble
>
>
Its gibberish, you never provide the halt status criterion measure.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-14 07:08 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <6PSzK.468694$ntj.296148@fx15.iad> |
| In reply to | #85169 |
On 7/14/22 6:43 AM, olcott wrote:
> On 7/14/2022 1:53 AM, Mr Flibble wrote:
>> On Wed, 13 Jul 2022 23:27:38 -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
>>> No you have not.
>>
>> Yes I have: see my post "An idea for a simulating halt decider" in
>> comp.theory.
>>
>> /Flibble
>>
>>
>
> Its gibberish, you never provide the halt status criterion measure.
>
Pot, Kettle, Black.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-07-14 16:06 +0000 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the |
| Message-ID | <tapeu5$uba$1@gioia.aioe.org> |
| In reply to | #85169 |
On Thu, 14 Jul 2022 05:43:56 -0500 olcott <NoOne@NoWhere.com> wrote: >On 7/14/2022 1:53 AM, Mr Flibble wrote: >> Yes I have: see my post "An idea for a simulating halt decider" in >> comp.theory. >> >> /Flibble >> >> > >Its gibberish, you never provide the halt status criterion measure. The irony, strong it is in this one!
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-13 23:29 -0500 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <4fidnYzcRIhcBlL_nZ2dnUU7_8xg4p2d@giganews.com> |
| In reply to | #85164 |
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.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-14 07:52 +0100 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <20220714075236.000000ef@reddwarf.jmc.corp> |
| In reply to | #85166 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 05:49 -0500 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <TPqdnZvCw81MaVL_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #85167 |
On 7/14/2022 1:52 AM, Mr Flibble wrote:
> 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
>
I did not say that you have no idea what unreachable code is, you simply
do not understand that infinite recursion prevents all the code below
the infinitely recursive function call to ever be reached.
There are a sequence of many posts that prove this where you believe
that removing the infinite loop eliminates the pathological relationship.
You and Richard are at the bottom 10% of technical competence in this
forum most everyone else could validate that I am correct.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-14 07:12 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <ISSzK.95514$%i2.19303@fx48.iad> |
| In reply to | #85170 |
On 7/14/22 6:49 AM, olcott wrote:
> On 7/14/2022 1:52 AM, Mr Flibble wrote:
>> 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
>>
>
> I did not say that you have no idea what unreachable code is, you simply
> do not understand that infinite recursion prevents all the code below
> the infinitely recursive function call to ever be reached.
>
> There are a sequence of many posts that prove this where you believe
> that removing the infinite loop eliminates the pathological relationship.
>
> You and Richard are at the bottom 10% of technical competence in this
> forum most everyone else could validate that I am correct.
>
No, you are in the bottom 0.01 % of technical competence to beleive your
lie that the H that returns 0 for H(P,P) actually generates infinite
recursion.
You believe that you can have simultaneously an immovable object and an
irresistible force that it can be applied to (does it move or is it
resisted?) You think you H can simulate its input forever, but still
finish and answer in finite time.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-14 17:48 +0100 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <20220714174829.00006c4a@reddwarf.jmc.corp> |
| In reply to | #85170 |
On Thu, 14 Jul 2022 05:49:52 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/14/2022 1:52 AM, Mr Flibble wrote:
> > 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
> >
>
> I did not say that you have no idea what unreachable code is, you
> simply do not understand that infinite recursion prevents all the
> code below the infinitely recursive function call to ever be reached.
Of course I have always understood that code after an infinite
recursion is unreachable, I have never claimed otherwise however what I
have claimed is that [Strachey 1965] is NOT recursive nor are the
proofs based on it; I have claimed that your solution is broken if it
invokes infinite recursion and I have shown that a simulating halting
decider needn't be recursive in nature (see my post in comp.theory).
Why don't you try acknowledging and addressing what people actually say
rather than misrepresenting what they say to try to make it fit with
your ongoing false narrative?
>
> There are a sequence of many posts that prove this where you believe
> that removing the infinite loop eliminates the pathological
> relationship.
Nope; see above - your solution is broken if it has an issue with
infinite recursion.
>
> You and Richard are at the bottom 10% of technical competence in this
> forum most everyone else could validate that I am correct.
Are you going to actually address our arguments or are you just going to
rely on ad hominem attacks?
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-14 07:07 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <eOSzK.468693$ntj.379590@fx15.iad> |
| In reply to | #85162 |
On 7/13/22 10:55 PM, olcott 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.
>
But then how do you explain that P(P) does halt, as you have even shown
when H(P,P) returns 0?
Your problem is that you show that *IF* H behaves one way, that the
simulation done by H(P,P) can't stop, and then you have H behave
differently.
You hide the logic flaw with glib words, but it is still an error.
The input to H(P,P) MUST refer to the behavior of P(P) or P isn't asking
H the right question to be the "Impossible Program", and P(P) Halt if
H(P,P) says it will be non-halting, so that isn't a correct anseer.
All you are showing is that you call fool some people some of the time.
And I think if you take an honest look arround, it isn't "most everyone"
who thinks you are correct. Yes, it is a fact that *IF* H does simulate
its input until it can actually PROVE that its input is non-halting,
that for THAT H, P(P) will be non-halting.
H can, by assuming that H is such a machine, detect that IF H WAS such a
machine, this P would be non-halting.
The problem is, that by H assuming that it is such a machine, it no
longer is such a machine, and the logic fails.
> The smartest software engineers here can also see that H does correctly
> predict this. People at the bottom 10% of technical competence may not
> see either one of these. No sense continuing to talk to these people.
>
But it isn't true! H(P,P) MUST decide about P(P) or P isn't correct, and
P(P) Halts if H(P,P) says it is non-halting, so H is just wrong with its
answer.
You are the Emperor who is believing his own lie that he has made a
fabulous set of clothes that only important people can see, but in
reality has gone out into the parade naked.
You logic is just BAD, and doesn't actually prove anything that you are
trying to claim.
H does NOT get the answer right, but you refuse to look at the REAL
evidence that even you have created, because you so want to believe your
lie, because you just can't face the actual truth.
> *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
>
>
[toc] | [prev] | [next] | [standalone]
| From | om@iki.fi (Otto J. Makela) |
|---|---|
| Date | 2022-07-18 17:51 +0300 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <87ilnu8oe8.fsf@tigger.extechop.net> |
| In reply to | #85162 |
olcott <NoOne@NoWhere.com> wrote: > 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. "Most everyone" here who sees this, please raise your hand now? Followup-to: comp.theory -- /* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-13 22:29 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <tcLzK.48986$iR.41893@fx44.iad> |
| In reply to | #85156 |
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.
No, you stop talking to me because I am being too good at pointing out
the errors in your logic.
>
> 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.
Nope. Pointed out elsewhere, the CORRECT simulation of the input to
H(P,P) by a simulator that DOESN'T abort (but P still calls the H that
does) shows that the input to H(P,P) will Halt if H(P,P) returns 0.
>
> It is also common knowledge that the correct simulation of a program is
> a correct measure of the behavior of this program.
Right CORRECT, as in NOT ABORTED part way.
>
> 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.
>
Nope. Since the correct (non-aborted) simulation of the input given to
H(P,P) by a simulator that actually does a complete simulation while the
input still calls the original H shows that the input to H(P,P) will
halt if H(P,P) returns 0.
If you try to claim that the correct simulation of the input to H(P,P)
depends on the simulator that is doing the simulation, then you are
showing you just don't understand how computations and simulations work.
Since H doesn't do a complete simulation, you can't use proofs based on
it doing so to show something. That is the DEFINITION of an UNSOUND
argument.
Since H (the one that gives the answer 0 to H(P,P), and that is the onne
that the P we are talkng about is using) doesn't do a complete and
correct simulation, ANY proof that include a condition "If H doesn't
abort ..." is a false premise.
Note, Halting is based on the program that is ACTUALLY there, not the
theoretical one you were trying to write.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-07-13 19:41 -0700 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <875yk05sbv.fsf@nosuchdomain.example.com> |
| In reply to | #85160 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/13/22 9:34 PM, olcott wrote:
[214 lines deleted]
Richard, please stop cross-posting to comp.lang.c and comp.lang.c++.
Followups directed back where they belong.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | - Olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-07-13 20:03 -0700 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <2a9f515b-eca7-4853-bb39-5f4c8ff4f625n@googlegroups.com> |
| In reply to | #85161 |
On Wednesday, July 13, 2022 at 9:41:40 PM UTC-5, Keith Thompson wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
> > On 7/13/22 9:34 PM, olcott wrote:
> [214 lines deleted]
>
> Richard, please stop cross-posting to comp.lang.c and comp.lang.c++.
>
> Followups directed back where they belong.
>
> --
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
> Working, but not speaking, for Philips
> void Void(void) { Void(); } /* The recursive call of the void */
I will stop cross-posting to comp.theory the posts belong here.
I could very quickly get closure and be done with this if someone
with your degree of technical competence to take ten minutes
to see that I am actually correct.
The newest revision to my paper is much easier to understand no
knowledge of x86 assembly language is required.
*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
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-14 21:55 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <GO3AK.469644$ntj.108377@fx15.iad> |
| In reply to | #85163 |
On 7/13/22 11:03 PM, - Olcott wrote:
> On Wednesday, July 13, 2022 at 9:41:40 PM UTC-5, Keith Thompson wrote:
>> Richard Damon <Ric...@Damon-Family.org> writes:
>>> On 7/13/22 9:34 PM, olcott wrote:
>> [214 lines deleted]
>>
>> Richard, please stop cross-posting to comp.lang.c and comp.lang.c++.
>>
>> Followups directed back where they belong.
>>
>> --
>> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
>> Working, but not speaking, for Philips
>> void Void(void) { Void(); } /* The recursive call of the void */
>
> I will stop cross-posting to comp.theory the posts belong here.
> I could very quickly get closure and be done with this if someone
> with your degree of technical competence to take ten minutes
> to see that I am actually correct.
>
> The newest revision to my paper is much easier to understand no
> knowledge of x86 assembly language is required.
>
> *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
You still haven't fixed your rule (3) which uses the WRONG WORDING of
the actual rule you are thinking of.
The recursion loop can't have a conditional ANYWHERE in the loop, not
even in H. You can't just look at the code for P and not the things it
calls.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-07-14 22:04 -0700 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <871qun55lf.fsf@nosuchdomain.example.com> |
| In reply to | #85227 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/13/22 11:03 PM, - Olcott wrote:
>> On Wednesday, July 13, 2022 at 9:41:40 PM UTC-5, Keith Thompson wrote:
>>> Richard Damon <Ric...@Damon-Family.org> writes:
>>>> On 7/13/22 9:34 PM, olcott wrote:
>>> [214 lines deleted]
>>>
>>> Richard, please stop cross-posting to comp.lang.c and comp.lang.c++.
>>>
>>> Followups directed back where they belong.
[...]
>> I will stop cross-posting to comp.theory the posts belong here.
[...]
I wasn't talking to you, olcott. I never see anything you post
to comp.lang.c or comp.lang.c++. I do wish you'd stop posting
there, but you're clearly won't listen to reasonable requests.
Richard, I was talking to you, and asking *you* to stop posting to
comp.lang.c and comp.lang.c++. There is no C or C++ content in the
article to which I'm replying. If you want to argue with olcott,
knock yourself out. I'm just asking you to remove comp.lang.c and
comp.lang.c++ from the Newsgroups: header.
Richard, I'm considering adding you to my killfile for comp.lang.c and
comp.lang.c++. That's not a threat, and I'm not saying it to change
your behavior; I'm just letting you know what I'll do if this continues.
Followups redirected yet again to comp.theory.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Jens Schweikhardt <usenet@schweikhardt.net> |
|---|---|
| Date | 2022-07-13 21:08 +0000 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <jj8qhvF45m0U1@mid.individual.net> |
| In reply to | #85140 |
In comp.lang.c olcott <NoOne@nowhere.com> wrote:
[...]
# H(P,P) correctly predicts that its input cannot possibly terminate
# normally. (I have better words now).
Please excuse my ignorance, I'm very late to the discussion, if the
following has already been brought forward.
It is my understanding that a "working" halt decider can be used to
prove or disprove any math theorem that can be expressed as a program
that halts or doesn't halt, depending on whether the proposition is true
or false. Simple example: the Riemann Hypothesis that the non-trivial
zeros of the zeta function have real part 0.5.
A C program could halt if it finds a zero with real part not equal 0.5;
if it can't it will run forever (assuming arbitrary large memory for the
bignums).
int main (void) {
/* mycomplex: An arbitrary precision complex type. */
mycomplex zero = 0.0;
for (;;) {
zero = compute_next_zero(zero); /* elided for brevity */
if (realpart(zero) != 0.5)
break;
}
return 0;
}
So if your claim holds true, feed the program to your machine, if it
says "never halts" the RH is proven true, otherwise false. Too easy. But
how does the knowledge about all zeros come into your halt decider? And
abount all the trillions of other programs to prove or disprove a
theorem? What about some of the other non-tractable problems, such as
P=NP? Can we conceive a C program for this question?
I don't think any finite program could be such a general theorem prover
and therefore I am convinced you are chasing a ghost and there's
something you overlooked. I can't say what exactly, but I don't have to,
because the above to me is an reductio ad absurdum. Given the halting
problem could be solved, theorem proving becomes trivial immediately.
I am aware it's not a strict proof in the mathematical sense, but good
enough for me. It's like you are coming to a physicist with a new
perpetual motion machine. They will not spend time finding the exact
weak point in your contraption. They will simply reject it, like any
patent office worth their salt.
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-07-12 09:52 +0000 |
| Message-ID | <tajg9b$1ntj$3@gioia.aioe.org> |
| In reply to | #85100 |
In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: > Olcott comes here because he is getting a response; Olcott won't go > anywhere unless people stop responding to him completely. Just ignore him; Clearly you don't understand how obsessive compulsion works.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2022-07-12 11:27 +0100 |
| Message-ID | <tajia1$20v2g$1@dont-email.me> |
| In reply to | #85108 |
On 12/07/2022 10:52, Juha Nieminen wrote: > In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: >> Olcott comes here because he is getting a response; Olcott won't go >> anywhere unless people stop responding to him completely. Just ignore him; > > Clearly you don't understand how obsessive compulsion works. There are degrees of OCD. By normal standards we've all got it... It's not normal to be able to spend hours at a time staring at code on a screen looking for that annoying little error. But yes, some are worse than others. Andy
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | comp.lang.c++
csiph-web