Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #85100 > unrolled thread

Re: "C: Everyone's favourite programming language isn't a programming language"

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.

Contents

  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 1 of 3  [1] 2 3  Next page →

#85100 — Re: "C: Everyone's favourite programming language isn't a programming language"

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;

[toc] | [next] | [standalone]

#85101 — H(P,P) is pure software engineering that correctly refutes the halting theorem

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:

understanding that the simulated P essentially calls simulating halt 
decider H in infinite recursion such that the simulated P cannot 
possibly terminate normally.

   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

*Any H that does handle this case refutes the halting theorem*

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.

*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


-- 
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]

#85118 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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?

[toc] | [prev] | [next] | [standalone]

#85135 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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



-- 
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]

#85139 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.

If you omit that, then (3) is just incorrect, as the fact that P(P) 
Halts when H(P,P) returns 0 proves.

You don't want to detect "essentially" in infinite recursion, but need 
to detect in ACTUAL infinite recursion.

If the infinite recursion is actual, then H(P,P) is also in infinite 
recursion and thus never answers and thus fails to be a decider.

If the infinite recursion isn't actual, then it doesn't matter that it 
was close, and only the smarts of H stopped it from being so, as that 
smarts in H was PART of the algorithm of P, by the virtual of it calling 
H to ask the question, and the P gets "credit" for those smarts too.

If one H has the smarts, but the one called by P doesn't, then H fails 
to be the needed Pure Function, so you are shown to be incorrect.

[toc] | [prev] | [next] | [standalone]

#85140 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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).


-- 
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]

#85141 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.

If H(P,P) isn't asking about the behavior of P(P), then you have defined 
your P incorrect and you whole proof is worthless as you aren't working 
on the needed case.

Remember, P is defined to as H about what it will do with its input.

THAT is the "impossible" program.

If H(P,P) isn't asking about P(P), then since that is what P is doing, 
it was defined wrong.

if that IS what it is asking about, then H is wrong, since P(P) will 
halt when H(P,P) returns 0.

IF one H(P,P) returns 0, but the H(P,P) that P(P) calls doesn't, then H 
is not a pure function.

If you want to still try to claim it is, what is the first x86 
instruction in the ACTUAL EXECTUION of the H(P,P) called by main and in 
the ACTUAL EXECUTION of the H(P,P) called by P(P) which have different 
results.

Since H is a pure function, and the inputs are the same, the inputs to 
the instruction needs to be the same too, or this isn't the first x86 
instruction with a difference, and you need to go back to the point 
where that difference was created, or admit that they are looking at 
something that wasn't part of the input, and thus H isn't a pure function.

[toc] | [prev] | [next] | [standalone]

#85142 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.



-- 
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]

#85146 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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?

You claim that H(P,P) correctly predicts what its input does.

Showing the definition of what the input does is on topic.

YOU are the one who doesn't follow your own subject, as you CLAIM to be 
talking about the Halting Problem, but whenever anyone tries to point 
out the actual definition of what the Halting Problem requires, you say 
it is off topic.

I guess you mean that the topic is YOU OWN INCORRECT IDEA of what the 
Halting Problem means, and actual facts are not allowed.

H(P,P) does NOT CORRECTLY predict that its correctly simulated input can 
not possible terminate normally because your H never does a correct 
simulation of its input and also make a prediction.

It EITHER correctly simulates the input, and simulates FOREVER (since 
the input then becomes non-halting) but fails to actually predict it,

or H makes a prediction but doesn't do a correct simulation of its 
input, and the actual correct simultion of the input shows that P(P), 
which IS what the input to H(P,P) is if P is done per the requirements, 
will Halt.

You don't seem to understand what the word "Correct" means.

(f you want to go by your claim that the input to H(P,P) doesn't 
actually represent P(P), then you program is meaningless, as P isn't the 
required P to be decided, since P asks H about itself by calling H(P,P), 
so if that doesn't mean P(P), your P isn't the needed on.

[toc] | [prev] | [next] | [standalone]

#85147 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.




-- 
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]

#85149 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

On Wed, 13 Jul 2022 07:19:48 -0500
olcott <NoOne@NoWhere.com> 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.

There is no infinite recursion in [Strachey 1965] or the HP proofs
based on it. I have shown that a simulating halt decider needn't be
recursive in nature: only your broken solution has a problem with
infinite recursion.

/Flibble

[toc] | [prev] | [next] | [standalone]

#85153 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.

It doesn't matter that *H* can't do that emulation (and there is nothing 
in the actual Halting Problem definition that says it should), because H 
is a FIXED program in this case, which is admitted to aborting its 
simulation, based on (provenly incorrect) conditions it detected in its 
emulation of P(P).

You claim that only H's emulation can show it is an error in your 
specification that means that NO program can be proved to be non-halting 
and so indicated by H, since if H indicates it, it didn't do a complete 
emulation of the program to show it. FAIL.

What CAN be shown, and in fact even YOU have posted, is that an actual 
correct simulation of this input does halt.

Note you proof of "essentially infinte recursion" is based on an error 
that ignores the ACTUAL behavor of H, but assumes that H actually meets 
its requirements. The fact that it doesn't meet its design requirements 
just shouws you don't actually know how to debug your own code.

Also note, your claim that the behavior of input to H(P,P) doesn't 
actually match the behavior of P(P) just shows that you have a bug in P 
(or H), as it is supposed to ask H for it to decide on what P(P) will 
do, and if H(P,P) isn't defined to do that, it shouldn't make that call.

[toc] | [prev] | [next] | [standalone]

#85154 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.


-- 
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]

#85155 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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 fact that H can't correct USE that information doesn't mean it 
wasn't given to it.

 From the complete description of a Turing Machine and it input, the 
ENTIRE behavior has been defined, though it may take infinite time to 
determine this if the machine is non-halting.

Give the complete x86 code of a program, and its input, the behavior of 
that program is completely defined.

Thus, H has been given everything that it should need to determine what 
it needs to, if the results are actually computable.

You big problem is you are confusing the phases of the programming process.

During the DESIGN Phase, you get to change your program as you desire 
and work on logic asking how to get the right answer.

When (and if) you comlete that design process, you now have a SPECIFIC 
program that you can test to see if it works.

At this stage, the program does what it has been programmed to do, and 
you don't look at other possible behaviors of it.

At this point you need to actually DEFINE what you H is, you have used 
several different sets of defiitions.

One is that it just DOES a complete and correct simulation of its input, 
that this H has been show to not return an answer to H(P,P) and does 
make P(P) non-halting, but this can't be your "correct" H, since it 
never returns the answer. (and you can't say P is using this, when you 
are deciding with a different one).

THe next design uses your defined rule that you CLAIM proves 
non-halting, that if P(P) calls H with the same input that H started 
with, then it can presume the input is non-halting.

THis is proved incorrect by just running P(P), seeing it call H(P,P) and 
then that H(P,P) sees its simulation do this, it aborting the 
simulation, and returning to P and P(P) halting. This PROVES the rule wrong.

You claim that the input to H(P,P) not being the same as P(P) is shown 
wrong because it MUST be or your P is defined incorrectly. Remember, the 
"impossible" program was defined to ask H about itself with its input 
and doing the opposite. Since P(P) calls H(P,P) to ask that question, if 
it doesn't actually mean that, you have an error in your problem 
construction.

You sometimes go more nebulous and just say that H will simulate until 
it can actually PROVE that the input is non-halting, and while if it can 
actually do that, it will be right, all this is actually doing is saying 
that your Halt Decider will use a Halt Decider to tell it if its input 
is non-halting, and thus your DESIGN recurses and you end up with an 
infinite program.

You ASSUME that there is SOME finite pattern that H can detect, since it 
is clear that if H doesn't abort its simulation it will never halt, but 
the problem is that this doesn't mean that if it does abort it is 
correct to say the input is non-halting, because the proof was based on 
a now false premise, that H will not abort its simulation.

We can (and I have shown you) prove that there IS no finite pattern in 
P(P) that H could detect, because ANY pattern in P(P), if put into H as 
a non-halting pattern, cause H(P,P) to return 0 to P(P) and P(P) then 
halts. Thus there does NOT exist a pattern to detect that this P(P) is 
non-halting that H could use to answer non-halting.

It IS possible for H to detect this fact, it just can't act on that 
knowledge without breaking the premise it uses to make this proof.

The problem is that the Field of Computation Theory requries that 
Deciders actually return the answer, and in a way that another program 
can get it, to be considered a Decider.

THus, we see that ANY H you design by your technique will either not 
answer or give the wrong answer, which is EXACTLY what the proof you are 
trying to refute says will happen.

[toc] | [prev] | [next] | [standalone]

#85156 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.


-- 
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]

#85157 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.

You are just showing you don't understand the nature of what an 
algorithm IS>

P calls H, and YOUR H simulates for a while, INCORRECTLY decides it 
doesn't halt, and returns 0, thus making P(P) a Halting Program.

It doesn't matter that some other H that might exist that doesn't abort 
results in a P(P) that doesn't halt, that isn't the H that we are 
looking at the you claim correctly return 0, as THAT H never returns 
from H(P,P)/

The fact that you see these two DIFFERENT H's as the same thing just 
proves that YOU don't have a firm grip of what is true.

Unless you can actually provide a H that with the EXACT SAME CODE, and 
as a PURE FUNCTION of its ihput does both of these, you are just caught 
in the lie you have been working on for decades. This code is of course 
impossible, which is why you have refused to show any version of this 
code that you have claimed to have had (with "small" errors) for years.

The "Small errors" are fundamental design bugs that you may be trying to 
fix, and if you actually publish your code, it will become obvious that 
you have been lying about what you program does.

You keep on saying that P(P) is a non-input, but then you are shown to 
LIE that your P meets the requirements of the "impossible program", as 
that asks H about the behavior of itself with its input, that is P(P), 
and you have coded that as H(P,P), so if the behavior of the input to 
H(P,P) is not the behabior of P(P) your P is not correct, and you proof 
is INVALID.

You need to change P to call H in the way that DOES ask about P(P), and 
if you can't do that, you H is automattically proven wrong as you have 
shown an machine and input that it can not decide.

Or perhaps more simply, you haven't shown that it gives the right answer 
for the impossible program, because you never asked it about it.

You are showing your total lack of understanding of the basics of 
computation theory, or even basic logic. Your "proof" is a model for how 
not to try to prove something.

[toc] | [prev] | [next] | [standalone]

#85158 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.

My grandfather George P. Olcott MD had a very key brilliant insight that 
my father often repeated to me: "One cannot argue with ignorance.


*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


-- 
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]

#85159 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.

Note, if you claim that the input behavior of the input to H(P,P) isn't 
the same as P(P) then you P isn't defined correctly, as that is how it 
asked H to decide on P(P).

> 
> My grandfather George P. Olcott MD had a very key brilliant insight that 
> my father often repeated to me: "One cannot argue with ignorance.

Yep, YOU are a perfect proof of that.

> 
> 
> *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 condition (3) near the bottom of page 1 is just flat out incorrect, 
showing you don't understand what a PROGRAM actually is. The REAL rule 
you are thinking of includes the code of H in the space that needs to be 
looked at for the conditionals, since the H that P calls IS part of the 
'code' of P.

FAIL.

PROOF OF YOUR IGNORANCE.

Note, this has been pointed out ot you MANY times, but the fact that you 
continue repeating it with out showing how you establish this variant of 
the accepted rules just proves that you are just being intentionally 
deceptive.

[toc] | [prev] | [next] | [standalone]

#85162 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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.

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.

*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

-- 
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]

#85164 — Re: H(P,P) is pure software engineering that correctly refutes the halting theorem

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web