On Tuesday, July 12, 2022 at 3:35:11 AM UTC+3, Lynn McGuire wrote:
> On 7/11/2022 2:40 PM, Michael S wrote:
> > On Monday, July 11, 2022 at 10:24:51 PM UTC+3, Lynn McGuire wrote:
> >> On 7/11/2022 5:28 AM, Mark Bluemel wrote:
> >>> On Monday, 11 July 2022 at 06:44:31 UTC+1, Lynn McGuire wrote:
> >>>> "C: Everyone's favourite programming language isn't a programming language"
> >>>> https://www.theregister.com/2022/03/23/c_not_a_language/
> >>>
> >>> 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.
> >> Do you have the date and time of the original posting ? I cannot find it.
> >>
> >> I sure do not remember the posting but, I have slept since then.
> >>
> >> Lynn
> >
> > From Mar 24, 2022, 5:36:11 PM to Apr 25, 2022, 9:05:03 PM
> > Your own post: Mar 28, 2022, 7:54:33 PM
> > https://groups.google.com/g/comp.lang.c/c/S5ygO3G3Jqg/m/usau9_tqAwAJ
> Sorry, that posting was not me.
>
> Lynn

My bad.
Your names sound similar to non--Scotsman like myself.

On 7/12/2022 3:27 AM, Vir Campestris wrote:
> On 12/07/2022 10:52, Juha Nieminen wrote:
>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>> Olcott comes here because he is getting a response; Olcott won't go
>>> anywhere unless people stop responding to him completely. Just ignore
>>> him;
>>
>> Clearly you don't understand how obsessive compulsion works.
>
> There are degrees of OCD. By normal standards we've all got it... It's
> not normal to be able to spend hours at a time staring at code on a
> screen looking for that annoying little error.

Yup! However, you are working toward a goal... To slay the error. A
little OCD can be "useful", from time to time...

> But yes, some are worse than others.

Big time. Some people have to wash their hands 42 times a day. No more,
no less.

On 12/07/2022 21:01, Chris M. Thomasson wrote:
>
> Big time. Some people have to wash their hands 42 times a day. No
> more, no less.
>

At college we had a Muslim woman who cleaned the keyboard and laid blank
papers on chair before sitting down to use a computer. She was just
obsessed with silly things.

On 7/12/22 8:45 AM, olcott wrote:
> On 7/12/2022 7:29 AM, Bonita Montero wrote:
>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>> anywhere unless people stop responding to him completely. Just
>>>> ignore him;
>>>
>>> Clearly you don't understand how obsessive compulsion works.
>>
>> I don't think he has OCD per se, because people like
>> that don't have that delusional sense of mission.
>
> Do you really have to go around and around with all this ad hominen
> stuff instead of simply validating that the simulated input to H(P,P)
> would never terminate normally ???
>
> 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 and would never terminate
> normally. H aborts its simulation on this basis and rejects this input
> as non-halting.
>
>

And is WRONG, because you have just shown that a call to H(P,P) returns
0 and NOT get into infinite recursion, BECAUSE H is smarter than H gives
it credit for, and know enough to abort its simulation, but isn't smart
enough to know that it will do so.

The ONLY way that H is correct that the call fo H(P,P) inside P(P) leads
to infinite recursion is if H isn't actually a Pure Function, at which
point it fails to be the equivalent of the Turing Machine required by
the proof, or to be a proper decider.

Note, you needed to add the "essentially" to you statment, because it
isn't actually infinite recursion, at least not if H makes the decision
to ever abort its simulation.

H, to be correct, needs to judge P based on the ACTUAL H that exists,
not some close approximation like the essentially tries to let in.

On 7/12/22 8:48 AM, olcott wrote:
> On 7/12/2022 7:46 AM, Bonita Montero wrote:
>> Am 12.07.2022 um 14:29 schrieb Bonita Montero:
>>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>>> anywhere unless people stop responding to him completely. Just
>>>>> ignore him;
>>>>
>>>> Clearly you don't understand how obsessive compulsion works.
>>>
>>> I don't think he has OCD per se, because people like
>>> that don't have that delusional sense of mission.
>>
>> What it has in common with OCD is that Pete only sees details
>> and is unable to see the big picture. This is also something
>> that there is in common with circles of thought.
>
> 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
>
> The big picture is that H(P,P) correctly determines that its input would
> never terminate normally and H(P,P) does handle the above "impossible"
> case.
>

Except that it doesn't, at least if it is trying to meet the actual
requirements of the Halting Problem.

Remember the DEFINITION:

H(M,x) accepts its input (returns 1) if M(x) will Halt (return), and
H(M,x) rejects its input (returns 0) if M(x) will NEVER Halt (return).

Thus H(P,P) to correctly return 0, means that P(P) must never return,
but by construction, P(P) WILL return if H(P,P) returns 0.

Your dishonest dodge of saying that the input to H(P,P) somehow doesn't
represent P(P) fails, because that says that P wasn't defined correctly,
as P was defined in the proof to be given an input so P asks H what it
will do when called with its input, and sincd your P(x) calls H(x,x),
athat means that P(P) calls H(P,P) which needs to mean that P is asking
about P(P), and not something else.

Thus, your claim is just an admission that you didn't write P correctly
(or are just lying that H is actually able to do what you claim).

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

On 7/12/2022 3:01 PM, Chris M. Thomasson wrote:
> On 7/12/2022 3:27 AM, Vir Campestris wrote:
>> On 12/07/2022 10:52, Juha Nieminen wrote:
>>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>> anywhere unless people stop responding to him completely. Just
>>>> ignore him;
>>>
>>> Clearly you don't understand how obsessive compulsion works.
>>
>> There are degrees of OCD. By normal standards we've all got it... It's
>> not normal to be able to spend hours at a time staring at code on a
>> screen looking for that annoying little error.
>
> Yup! However, you are working toward a goal... To slay the error. A
> little OCD can be "useful", from time to time...
>

It works for Elon Musk.

>
>> But yes, some are worse than others.
>
> Big time. Some people have to wash their hands 42 times a day. No more,
> no less.
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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.

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

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.

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

On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes:

> > I have some hope Lynn may take some notice. It's clear that Olcott won't.
> Lynn clearly made an honest mistake, posting a relevant link without
> realizing that it had been discussed previously.

My response to Lynn was possibly a little brusque, but my perception
is that she pops up from time-to-time to post some link or other, but
doesn't really participate in discussions.

> Olcott is a crank (take a look at comp.theory if you're curious). They
> are not comparable.

I know, and no thank you, I'm not curious.

> If you must reply to olcott here, at least don't quote his entire
> article and continue arguing with him.

You must be mistaking me for someone else - I don't reply to
olcott, let alone quote his drivel.

I note that he and Richard (who should surely know better) have
now hijacked this thread.

In comp.lang.c++ Vir Campestris <vir.campestris@invalid.invalid> wrote:
> On 12/07/2022 10:52, Juha Nieminen wrote:
>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>> Olcott comes here because he is getting a response; Olcott won't go
>>> anywhere unless people stop responding to him completely. Just ignore him;
>>
>> Clearly you don't understand how obsessive compulsion works.
>
> There are degrees of OCD. By normal standards we've all got it... It's
> not normal to be able to spend hours at a time staring at code on a
> screen looking for that annoying little error.

I don't think that fulfills the "D" part (except if in canses where it's
arguably unreasonable and has a tangible and chronic negative impact on
one's life and social relationships).

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.

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

On Wed, 13 Jul 2022 10:02:40 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>In comp.lang.c++ Vir Campestris <vir.campestris@invalid.invalid> wrote:
>> On 12/07/2022 10:52, Juha Nieminen wrote:
>>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>> anywhere unless people stop responding to him completely. Just ignore him;
>>>
>>> Clearly you don't understand how obsessive compulsion works.
>>
>> There are degrees of OCD. By normal standards we've all got it... It's
>> not normal to be able to spend hours at a time staring at code on a
>> screen looking for that annoying little error.
>
>I don't think that fulfills the "D" part (except if in canses where it's
>arguably unreasonable and has a tangible and chronic negative impact on
>one's life and social relationships).

I wonder if Olcott and that religious nutjob who used to post on here (forget
his name) are one and the same. In this thread from 2018:

https://groups.google.com/g/comp.theory/c/0i86aQ3WPaA

Olcott posts a link to his own website:

http://the-pete.org

Looks very familiar.

Mark Bluemel <mark.bluemel@gmail.com> writes:
> On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
[...]
>> If you must reply to olcott here, at least don't quote his entire
>> article and continue arguing with him.
>
> You must be mistaking me for someone else - I don't reply to
> olcott, let alone quote his drivel.

Sorry, that wasn't addressed to you specifically.

> I note that he and Richard (who should surely know better) have
> now hijacked this thread.

Yes, Richard should know better.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

On 13/07/2022 16:24, Muttley@dastardlyhq.com wrote:
>
>
> Olcott posts a link to his own website:
>

Olcott can improve his chances of winning a "Nobel" price by posting his
article on <https://www.dreamwidth.org/> and spend as much time as
possible to promote it. the problem is Olcott hasn't got the necessary
qualification to have any credibility in his work. the guy is a jobless
troll dying of "advance stage of cancer". that's what he told us so we
should take his word. Please don't send any money to him because his
claim of dying of cancer is also dubious. The guy is liar and fraudster.

He's is wasting time by posting here because people responding to him
are only interested to waste his time and their own time. i doubt if any
of them have any interest in advancing anything new here. I don't see
any posts from them but I have simply kill-filed them and I try to
kill-file anybody who responds to his posts.

On Wednesday, July 13, 2022 at 12:24:04 PM UTC-5, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes:
> > On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
> [...]
> >> If you must reply to olcott here, at least don't quote his entire
> >> article and continue arguing with him.
> >
> > You must be mistaking me for someone else - I don't reply to
> > olcott, let alone quote his drivel.
> Sorry, that wasn't addressed to you specifically.
> > I note that he and Richard (who should surely know better) have
> > now hijacked this thread.
> Yes, Richard should know better.
> --
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
> Working, but not speaking, for Philips
> void Void(void) { Void(); } /* The recursive call of the void */

5.5 years of feedback have made my words much clearer.
My words are so much more plausible now that a leading
computer scientist extensively reviewed my work in a 23 email
dialogue last weekend.

You are certainly competent enough to validate the software engineering of this

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

H Simulates its input until it correctly predicts that this simulated input
would never terminate normally then rejects this input as non-halting.

void P(ptr x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

The simulated P essentially calls H in infinite recursion.
Because basic software engineering knows that no function
called in infinite recursion ever returns to its caller we know
that the simulated P never terminates normally for these reasons:

*When the execution trace of function P() simulated by function H() shows:*
(1) Function H() is called from P().<br>
(2) With the same parameters to H().<br>
(3) With no instructions in P() that could escape this infinitely recursive
simulation: {index jump, conditional branch, return}

As soon as H correctly predicts that its simulated P would never terminate
normally it aborted its simulation of P and rejects this input a s non-haling.

Then the function call from P() to H() would never terminate normally.
In this case H aborts its simulation of P and rejects its input as non-halting.

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

Because H(P,P) does handle this case the above halting problem undecidable input template has been refuted.

*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually specified by these inputs.

*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until it correctly predicts that this simulated input would never terminate normally, correctly rejects this input as non-halting.

H is a *Pure function* https://en.wikipedia.org/wiki/Pure_function
thus implements a *Computable function*
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions

In comp.lang.c olcott <NoOne@nowhere.com> wrote:
[...]
# H(P,P) correctly predicts that its input cannot possibly terminate
# normally. (I have better words now).

Please excuse my ignorance, I'm very late to the discussion, if the
following has already been brought forward.

It is my understanding that a "working" halt decider can be used to
prove or disprove any math theorem that can be expressed as a program
that halts or doesn't halt, depending on whether the proposition is true
or false. Simple example: the Riemann Hypothesis that the non-trivial
zeros of the zeta function have real part 0.5.

A C program could halt if it finds a zero with real part not equal 0.5;
if it can't it will run forever (assuming arbitrary large memory for the
bignums).

int main (void) {
/* mycomplex: An arbitrary precision complex type. */
mycomplex zero = 0.0;
for (;;) {
zero = compute_next_zero(zero); /* elided for brevity */
if (realpart(zero) != 0.5)
break;
}
return 0;
}

So if your claim holds true, feed the program to your machine, if it
says "never halts" the RH is proven true, otherwise false. Too easy. But
how does the knowledge about all zeros come into your halt decider? And
abount all the trillions of other programs to prove or disprove a
theorem? What about some of the other non-tractable problems, such as
P=NP? Can we conceive a C program for this question?

I don't think any finite program could be such a general theorem prover
and therefore I am convinced you are chasing a ghost and there's
something you overlooked. I can't say what exactly, but I don't have to,
because the above to me is an reductio ad absurdum. Given the halting
problem could be solved, theorem proving becomes trivial immediately.

I am aware it's not a strict proof in the mathematical sense, but good
enough for me. It's like you are coming to a physicist with a new
perpetual motion machine. They will not spend time finding the exact
weak point in your contraption. They will simply reject it, like any
patent office worth their salt.

Regards,

Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

On 7/13/2022 11:00 AM, Manu Raju wrote:
> On 13/07/2022 16:24, Muttley@dastardlyhq.com wrote:
>>
>>
>> Olcott posts a link to his own website:
>>
>
> Olcott can improve his chances of winning a "Nobel" price by posting his
> article on <https://www.dreamwidth.org/>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

dreamwidth sounds interesting.

https://en.wikipedia.org/wiki/Dreamwidth

The invite code reminds me of SIGGRAPH for some reason...

> and spend as much time as
> possible to promote it. the problem is Olcott hasn't got the necessary
> qualification to have any credibility in his work. the guy is a jobless
> troll dying of "advance stage of cancer". that's what he told us so we
> should take his word. Please don't send any money to him because his
> claim of dying of cancer is also dubious. The guy is liar and fraudster.
>
> He's is wasting time by posting here because people responding to him
> are only interested to waste his time and their own time. i doubt if any
> of them have any interest in advancing anything new here. I don't see
> any posts from them but I have simply kill-filed them and I try to
> kill-file anybody who responds to his posts.
>
>
>

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.

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.

On 7/13/2022 4:08 PM, Jens Schweikhardt wrote:
> In comp.lang.c olcott <NoOne@nowhere.com> wrote:
> [...]
> # H(P,P) correctly predicts that its input cannot possibly terminate
> # normally. (I have better words now).
>
> Please excuse my ignorance, I'm very late to the discussion, if the
> following has already been brought forward.
>
> It is my understanding that a "working" halt decider can be used to
> prove or disprove any math theorem that can be expressed as a program
> that halts or doesn't halt, depending on whether the proposition is true
> or false. Simple example: the Riemann Hypothesis that the non-trivial
> zeros of the zeta function have real part 0.5.
>
> A C program could halt if it finds a zero with real part not equal 0.5;
> if it can't it will run forever (assuming arbitrary large memory for the
> bignums).
>
> int main (void) {
> /* mycomplex: An arbitrary precision complex type. */
> mycomplex zero = 0.0;
> for (;;) {
> zero = compute_next_zero(zero); /* elided for brevity */
> if (realpart(zero) != 0.5)
> break;
> }
> return 0;
> }
>
> So if your claim holds true, feed the program to your machine, if it
> says "never halts" the RH is proven true, otherwise false. Too easy. But
> how does the knowledge about all zeros come into your halt decider? And
> abount all the trillions of other programs to prove or disprove a
> theorem? What about some of the other non-tractable problems, such as
> P=NP? Can we conceive a C program for this question?
>
> I don't think any finite program could be such a general theorem prover
> and therefore I am convinced you are chasing a ghost and there's
> something you overlooked. I can't say what exactly, but I don't have to,
> because the above to me is an reductio ad absurdum. Given the halting
> problem could be solved, theorem proving becomes trivial immediately.
>
> I am aware it's not a strict proof in the mathematical sense, but good
> enough for me. It's like you are coming to a physicist with a new
> perpetual motion machine. They will not spend time finding the exact
> weak point in your contraption. They will simply reject it, like any
> patent office worth their salt.
>
> Regards,
>
> Jens

There is a huge difference between solving the halting problem and
refuting the conventional proofs that solving the halting problem is
impossible. I am only doing the latter.

It may not even be the case that solving the halting problem could
answer currently unknown problems of mathematics. This would require
infallible mathematical reasoning about all of mathematics such that it
could deduce every mathematical unknown. This is a very much broader
scope than simply correctly determining whether or not a computer
program will stop running.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer