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

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

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

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.

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.

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.

Richard Damon <Richard@Damon-Family.org> writes:
> On 7/13/22 9:34 PM, olcott wrote:
[214 lines deleted]

Richard, please stop cross-posting to comp.lang.c and comp.lang.c++.

Followups directed back where they belong.

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

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.

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.

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

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

On Wed, 13 Jul 2022 23:29:53 -0500
olcott <NoOne@NoWhere.com> wrote:

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

On Wed, 13 Jul 2022 23:27:38 -0500
olcott <NoOne@NoWhere.com> wrote:

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

On 7/14/2022 1:53 AM, Mr Flibble wrote:
> On Wed, 13 Jul 2022 23:27:38 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/13/2022 11:18 PM, Mr Flibble wrote:
>>> On Wed, 13 Jul 2022 21:55:25 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/13/2022 9:21 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/13/22 10:08 PM, olcott wrote:
>>>>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
>>>>>>> On 7/13/22 9:34 PM, olcott wrote:
>>>>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 7/13/22 8:06 PM, olcott wrote:
>>>>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
>>>>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago
>>>>>>>>>>>>>>>>>>>>>> when the article came out.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot
>>>>>>>>>>>>>>>>>>>>> called Olcott? He keeps
>>>>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there
>>>>>>>>>>>>>>>>>>>>> are two guys here who
>>>>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing
>>>>>>>>>>>>>>>>>>>>> him.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a
>>>>>>>>>>>>>>>>>>>>> response; Olcott won't go
>>>>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
>>>>>>>>>>>>>>>>>>>>> completely. Just ignore him;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated
>>>>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very
>>>>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading computer
>>>>>>>>>>>>>>>>>>>> scientist.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>>>>>>>>> presentation so that everyone here can easily
>>>>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting
>>>>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would
>>>>>>>>>>>>>>>>>>> you please stop posting this same thing millions of
>>>>>>>>>>>>>>>>>>> times?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For any program H that might determine if programs
>>>>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some
>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to H and
>>>>>>>>>>>>>>>>>> then specifically do the opposite of what H predicts
>>>>>>>>>>>>>>>>>> P will do. *No H can exist that handles this case*
>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is not verified until it is understood that P and
>>>>>>>>>>>>>>>>>> H implement the classical halting problem "impossible
>>>>>>>>>>>>>>>>>> input" template (as shown above) and refutes this
>>>>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its
>>>>>>>>>>>>>>>>>> input never terminates normally.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *This is the key software engineering that I need
>>>>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that
>>>>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly
>>>>>>>>>>>>>>>>>> terminate normally.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The next level of pure software engineering is that
>>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input
>>>>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the
>>>>>>>>>>>>>>>>>> case that only the top 5% of software engineers can
>>>>>>>>>>>>>>>>>> validate this point.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated
>>>>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion.
>>>>>>>>>>>>>>>>>> H aborts its simulation on this basis and rejects
>>>>>>>>>>>>>>>>>> this input as non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The execution trace of function P() simulated by
>>>>>>>>>>>>>>>>>> function H() shows:
>>>>>>>>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
>>>>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *That was all of the software engineering that I need
>>>>>>>>>>>>>>>>>> validated*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of
>>>>>>>>>>>>>>>>>> software engineering
>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it.
>>>>>>>>>>>>>>>>> The CORRECT version of (3) looks ALL the way through
>>>>>>>>>>>>>>>>> the loop, which includes in H, and will find the
>>>>>>>>>>>>>>>>> condtional there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
>>>>>>>>>>>>>>>> possibly terminate normally. (I have better words now).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that the program represented by the input, P(P)
>>>>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
>>>>>>>>>>>>>> its correctly simulated input cannot possibly terminate
>>>>>>>>>>>>>> normally.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WHAT Change of subject?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> IT IS A VERIFIED FACT THAT
>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>>>>> correctly
>>>>>>>>>>>> simulated input cannot possibly terminate normally.
>>>>>>>>>>>>
>>>>>>>>>>>> The only possible correct rebuttal must show all the steps
>>>>>>>>>>>> of exactly how the input to simulating halt decider H(P,P)
>>>>>>>>>>>> does terminate normally when H correctly simulates this
>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Since I already proved that this is false entirely on the
>>>>>>>>>>>> basis of verified fact this is impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> This requires that a function called in essentially
>>>>>>>>>>>> infinite recursion to return a value to its caller this is
>>>>>>>>>>>> impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> Most everyone here knows that every function called in
>>>>>>>>>>>> infinite recursion never returns any value to its caller.
>>>>>>>>>>>> There is no gibberish that you can say that would convince
>>>>>>>>>>>> them otherwise.
>>>>>>>>>>> That can't be a verified fact because the opposite is a
>>>>>>>>>>> verified fact, that the CORRECT simulation of the input to
>>>>>>>>>>> H(P,P), which is the correct simulation of P(P) will
>>>>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does.
>>>>>>>>>>
>>>>>>>>>> I already gave Paul N a great explanation of that on
>>>>>>>>>> comp.theory. I won't be able to see your reply there because
>>>>>>>>>> I have you blocked there.
>>>>>>>>>>
>>>>>>>>>> My explanation to wjj even sums it up better:
>>>>>>>>>>
>>>>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>>>>>>>>  > On 7/13/2022 3:47 PM, wij wrote:
>>>>>>>>>>  >> The property that an arbitrary program P will finish
>>>>>>>>>>  >> running or not is  determined by running P as an
>>>>>>>>>>  >> independent program
>>>>>>>>>>
>>>>>>>>>> Because that would require that a halt decider must sometimes
>>>>>>>>>> make its
>>>>>>>>>> halt status decision on a basis other than the actual
>>>>>>>>>> behavior of its actual input that long standing
>>>>>>>>>> misconception has been refuted.
>>>>>>>>>
>>>>>>>>> No, because all the behavior of that program exists will be
>>>>>>>>> encoded in the representation of the program given to the
>>>>>>>>> decider.
>>>>>>>>
>>>>>>>> The reason that I stop talking to you is that you make false
>>>>>>>> assumptions that are utterly impervious to all reasoning.
>>>>>>>>
>>>>>>>> It is a verified fact that the input that is correctly
>>>>>>>> simulated by H(P,P) cannot possibly terminate normally. It is
>>>>>>>> also a verified fact that the direct execution of P(P) does
>>>>>>>> terminate normally.
>>>>>>>>
>>>>>>>> It is also common knowledge that the correct simulation of a
>>>>>>>> program is a correct measure of the behavior of this program.
>>>>>>>>
>>>>>>>> This conclusively proves that H(P,P) is correct to reject its
>>>>>>>> input as non-halting and the behavior of a non-input cannot
>>>>>>>> possibly contradict this.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly
>>>>>>> simulate the input (since it aborts it to return 0) so it
>>>>>>> doesn't MATTER that if it was a different program it wouldn't
>>>>>>> be able to simulate to a final state.
>>>>>>
>>>>>>
>>>>>> That you (and others) continue to lack the technical capacity to
>>>>>> comprehend that H does correctly predict that its complete and
>>>>>> correct simulation of its input would never result in this input
>>>>>> terminating normally is far less than no rebuttal at all. Until
>>>>>> you (and others) gain this technical capacity there is no sense
>>>>>> continuing a dialogue.
>>>>>
>>>>> How is it correct when H(P,P) sayts P(P) is non-halting when a
>>>>> direct exectuion of P(P) or a correct simulation by simualte(P,P)
>>>>> (where P still calls the previous H) show that it halts.
>>>>
>>>> Most everyone here can see: (from my updated simplified paper)
>>>> It is a verified fact that the input that is correctly simulated by
>>>> H(P,P) cannot possibly terminate normally.
>>>
>>> I have shown that a simulating halting decider needn't be recursive
>>> in nature thus can terminate normally. You are wrong on all fronts.
>>>
>>> /Flibble
>>>
>> No you have not.
>
> Yes I have: see my post "An idea for a simulating halt decider" in
> comp.theory.
>
> /Flibble
>
>

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

On 7/13/22 10:55 PM, olcott wrote:
> On 7/13/2022 9:21 PM, Richard Damon wrote:
>>
>> On 7/13/22 10:08 PM, olcott wrote:
>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
>>>> On 7/13/22 9:34 PM, olcott wrote:
>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/13/22 8:06 PM, olcott wrote:
>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago when
>>>>>>>>>>>>>>>>>>> the article came out.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot called
>>>>>>>>>>>>>>>>>> Olcott? He keeps
>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there are
>>>>>>>>>>>>>>>>>> two guys here who
>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing him.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a response;
>>>>>>>>>>>>>>>>>> Olcott won't go
>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
>>>>>>>>>>>>>>>>>> completely. Just ignore him;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated whether
>>>>>>>>>>>>>>>>> or not anyone responds. I just had a very extensive
>>>>>>>>>>>>>>>>> review (23 emails) by a leading computer scientist.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>>>>>> presentation so that everyone here can easily verify
>>>>>>>>>>>>>>>>> that I have correctly refuted the halting theorem on
>>>>>>>>>>>>>>>>> this pure software engineering basis:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would you
>>>>>>>>>>>>>>>> please stop posting this same thing millions of times?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For any program H that might determine if programs halt,
>>>>>>>>>>>>>>> a "pathological" program P, called with some input, can
>>>>>>>>>>>>>>> pass its own source and its input to H and then
>>>>>>>>>>>>>>> specifically do the opposite of what H predicts P will
>>>>>>>>>>>>>>> do. *No H can exist that handles this case*
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is not verified until it is understood that P and H
>>>>>>>>>>>>>>> implement the classical halting problem "impossible
>>>>>>>>>>>>>>> input" template (as shown above) and refutes this
>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its
>>>>>>>>>>>>>>> input never terminates normally.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *This is the key software engineering that I need validated*
>>>>>>>>>>>>>>> Most anyone here can easily verify that the simulated
>>>>>>>>>>>>>>> input to H(P,P) cannot possibly terminate normally.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The next level of pure software engineering is that
>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input cannot
>>>>>>>>>>>>>>> possibly terminate normally. It may be the case that only
>>>>>>>>>>>>>>> the top 5% of software engineers can validate this point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated
>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion. H
>>>>>>>>>>>>>>> aborts its simulation on this basis and rejects this
>>>>>>>>>>>>>>> input as non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The execution trace of function P() simulated by function
>>>>>>>>>>>>>>> H() shows:
>>>>>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *That was all of the software engineering that I need
>>>>>>>>>>>>>>> validated*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of software
>>>>>>>>>>>>>>> engineering
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it. The
>>>>>>>>>>>>>> CORRECT version of (3) looks ALL the way through the loop,
>>>>>>>>>>>>>> which includes in H, and will find the condtional there.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot possibly
>>>>>>>>>>>>> terminate normally. (I have better words now).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except that the program represented by the input, P(P) DOES
>>>>>>>>>>>> terminate normally if H(P,P) returns 0.
>>>>>>>>>>>
>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>>>> correctly simulated input cannot possibly terminate normally.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WHAT Change of subject?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> IT IS A VERIFIED FACT THAT
>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>> correctly
>>>>>>>>> simulated input cannot possibly terminate normally.
>>>>>>>>>
>>>>>>>>> The only possible correct rebuttal must show all the steps of
>>>>>>>>> exactly how the input to simulating halt decider H(P,P) does
>>>>>>>>> terminate normally when H correctly simulates this input.
>>>>>>>>>
>>>>>>>>> Since I already proved that this is false entirely on the basis
>>>>>>>>> of verified fact this is impossible.
>>>>>>>>>
>>>>>>>>> This requires that a function called in essentially infinite
>>>>>>>>> recursion to return a value to its caller this is impossible.
>>>>>>>>>
>>>>>>>>> Most everyone here knows that every function called in infinite
>>>>>>>>> recursion never returns any value to its caller. There is no
>>>>>>>>> gibberish that you can say that would convince them otherwise.
>>>>>>>>>
>>>>>>>> That can't be a verified fact because the opposite is a verified
>>>>>>>> fact, that the CORRECT simulation of the input to H(P,P), which
>>>>>>>> is the correct simulation of P(P) will actually Halt if H(P,P)
>>>>>>>> returns 0, as you claim it does.
>>>>>>>
>>>>>>> I already gave Paul N a great explanation of that on comp.theory.
>>>>>>> I won't be able to see your reply there because I have you
>>>>>>> blocked there.
>>>>>>>
>>>>>>> My explanation to wjj even sums it up better:
>>>>>>>
>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>>>>>  > On 7/13/2022 3:47 PM, wij wrote:
>>>>>>>  >> The property that an arbitrary program P will finish
>>>>>>>  >> running or not is  determined by running P as an
>>>>>>>  >> independent program
>>>>>>>
>>>>>>> Because that would require that a halt decider must sometimes
>>>>>>> make its
>>>>>>> halt status decision on a basis other than the actual behavior of
>>>>>>> its
>>>>>>> actual input that long standing misconception has been refuted.
>>>>>>>
>>>>>>
>>>>>> No, because all the behavior of that program exists will be
>>>>>> encoded in the representation of the program given to the decider.
>>>>>>
>>>>>
>>>>> The reason that I stop talking to you is that you make false
>>>>> assumptions that are utterly impervious to all reasoning.
>>>>>
>>>>> It is a verified fact that the input that is correctly simulated by
>>>>> H(P,P) cannot possibly terminate normally. It is also a verified
>>>>> fact that the direct execution of P(P) does terminate normally.
>>>>>
>>>>> It is also common knowledge that the correct simulation of a
>>>>> program is a correct measure of the behavior of this program.
>>>>>
>>>>> This conclusively proves that H(P,P) is correct to reject its input
>>>>> as non-halting and the behavior of a non-input cannot possibly
>>>>> contradict this.
>>>>>
>>>>>
>>>>
>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly simulate
>>>> the input (since it aborts it to return 0) so it doesn't MATTER that
>>>> if it was a different program it wouldn't be able to simulate to a
>>>> final state.
>>>
>>>
>>> That you (and others) continue to lack the technical capacity to
>>> comprehend that H does correctly predict that its complete and
>>> correct simulation of its input would never result in this input
>>> terminating normally is far less than no rebuttal at all. Until you
>>> (and others) gain this technical capacity there is no sense
>>> continuing a dialogue.
>>
>> How is it correct when H(P,P) sayts P(P) is non-halting when a direct
>> exectuion of P(P) or a correct simulation by simualte(P,P) (where P
>> still calls the previous H) show that it halts.
>
> Most everyone here can see: (from my updated simplified paper)
> It is a verified fact that the input that is correctly simulated by
> H(P,P) cannot possibly terminate normally.
>

On 7/14/22 6:43 AM, olcott wrote:
> On 7/14/2022 1:53 AM, Mr Flibble wrote:
>> On Wed, 13 Jul 2022 23:27:38 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 7/13/2022 11:18 PM, Mr Flibble wrote:
>>>> On Wed, 13 Jul 2022 21:55:25 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 7/13/2022 9:21 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/13/22 10:08 PM, olcott wrote:
>>>>>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
>>>>>>>> On 7/13/22 9:34 PM, olcott wrote:
>>>>>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/13/22 8:06 PM, olcott wrote:
>>>>>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
>>>>>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago
>>>>>>>>>>>>>>>>>>>>>>> when the article came out.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot
>>>>>>>>>>>>>>>>>>>>>> called Olcott? He keeps
>>>>>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there
>>>>>>>>>>>>>>>>>>>>>> are two guys here who
>>>>>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing
>>>>>>>>>>>>>>>>>>>>>> him.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a
>>>>>>>>>>>>>>>>>>>>>> response; Olcott won't go
>>>>>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
>>>>>>>>>>>>>>>>>>>>>> completely. Just ignore him;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated
>>>>>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very
>>>>>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading computer
>>>>>>>>>>>>>>>>>>>>> scientist.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>>>>>>>>>> presentation so that everyone here can easily
>>>>>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting
>>>>>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would
>>>>>>>>>>>>>>>>>>>> you please stop posting this same thing millions of
>>>>>>>>>>>>>>>>>>>> times?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For any program H that might determine if programs
>>>>>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some
>>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to H and
>>>>>>>>>>>>>>>>>>> then specifically do the opposite of what H predicts
>>>>>>>>>>>>>>>>>>> P will do. *No H can exist that handles this case*
>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is not verified until it is understood that P and
>>>>>>>>>>>>>>>>>>> H implement the classical halting problem "impossible
>>>>>>>>>>>>>>>>>>> input" template (as shown above) and refutes this
>>>>>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its
>>>>>>>>>>>>>>>>>>> input never terminates normally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *This is the key software engineering that I need
>>>>>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that
>>>>>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly
>>>>>>>>>>>>>>>>>>> terminate normally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The next level of pure software engineering is that
>>>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input
>>>>>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the
>>>>>>>>>>>>>>>>>>> case that only the top 5% of software engineers can
>>>>>>>>>>>>>>>>>>> validate this point.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>      if (H(x, x))
>>>>>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>      Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated
>>>>>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion.
>>>>>>>>>>>>>>>>>>> H aborts its simulation on this basis and rejects
>>>>>>>>>>>>>>>>>>> this input as non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The execution trace of function P() simulated by
>>>>>>>>>>>>>>>>>>> function H() shows:
>>>>>>>>>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
>>>>>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *That was all of the software engineering that I need
>>>>>>>>>>>>>>>>>>> validated*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of
>>>>>>>>>>>>>>>>>>> software engineering
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it.
>>>>>>>>>>>>>>>>>> The CORRECT version of (3) looks ALL the way through
>>>>>>>>>>>>>>>>>> the loop, which includes in H, and will find the
>>>>>>>>>>>>>>>>>> condtional there.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
>>>>>>>>>>>>>>>>> possibly terminate normally. (I have better words now).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that the program represented by the input, P(P)
>>>>>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
>>>>>>>>>>>>>>> its correctly simulated input cannot possibly terminate
>>>>>>>>>>>>>>> normally.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WHAT Change of subject?
>>>>>>>>>>>>>
>>>>>>>>>>>>> IT IS A VERIFIED FACT THAT
>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated input cannot possibly terminate normally.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only possible correct rebuttal must show all the steps
>>>>>>>>>>>>> of exactly how the input to simulating halt decider H(P,P)
>>>>>>>>>>>>> does terminate normally when H correctly simulates this
>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since I already proved that this is false entirely on the
>>>>>>>>>>>>> basis of verified fact this is impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This requires that a function called in essentially
>>>>>>>>>>>>> infinite recursion to return a value to its caller this is
>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Most everyone here knows that every function called in
>>>>>>>>>>>>> infinite recursion never returns any value to its caller.
>>>>>>>>>>>>> There is no gibberish that you can say that would convince
>>>>>>>>>>>>> them otherwise.
>>>>>>>>>>>> That can't be a verified fact because the opposite is a
>>>>>>>>>>>> verified fact, that the CORRECT simulation of the input to
>>>>>>>>>>>> H(P,P), which is the correct simulation of P(P) will
>>>>>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does.
>>>>>>>>>>>
>>>>>>>>>>> I already gave Paul N a great explanation of that on
>>>>>>>>>>> comp.theory. I won't be able to see your reply there because
>>>>>>>>>>> I have you blocked there.
>>>>>>>>>>>
>>>>>>>>>>> My explanation to wjj even sums it up better:
>>>>>>>>>>>
>>>>>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>>>>>>>>>    > On 7/13/2022 3:47 PM, wij wrote:
>>>>>>>>>>>    >> The property that an arbitrary program P will finish
>>>>>>>>>>>    >> running or not is  determined by running P as an
>>>>>>>>>>>    >> independent program
>>>>>>>>>>>
>>>>>>>>>>> Because that would require that a halt decider must sometimes
>>>>>>>>>>> make its
>>>>>>>>>>> halt status decision on a basis other than the actual
>>>>>>>>>>> behavior of its actual input that long standing
>>>>>>>>>>> misconception has been refuted.
>>>>>>>>>>
>>>>>>>>>> No, because all the behavior of that program exists will be
>>>>>>>>>> encoded in the representation of the program given to the
>>>>>>>>>> decider.
>>>>>>>>>
>>>>>>>>> The reason that I stop talking to you is that you make false
>>>>>>>>> assumptions that are utterly impervious to all reasoning.
>>>>>>>>>
>>>>>>>>> It is a verified fact that the input that is correctly
>>>>>>>>> simulated by H(P,P) cannot possibly terminate normally. It is
>>>>>>>>> also a verified fact that the direct execution of P(P) does
>>>>>>>>> terminate normally.
>>>>>>>>>
>>>>>>>>> It is also common knowledge that the correct simulation of a
>>>>>>>>> program is a correct measure of the behavior of this program.
>>>>>>>>>
>>>>>>>>> This conclusively proves that H(P,P) is correct to reject its
>>>>>>>>> input as non-halting and the behavior of a non-input cannot
>>>>>>>>> possibly contradict this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly
>>>>>>>> simulate the input (since it aborts it to return 0) so it
>>>>>>>> doesn't MATTER that if it was a different program it wouldn't
>>>>>>>> be able to simulate to a final state.
>>>>>>>
>>>>>>>
>>>>>>> That you (and others) continue to lack the technical capacity to
>>>>>>> comprehend that H does correctly predict that its complete and
>>>>>>> correct simulation of its input would never result in this input
>>>>>>> terminating normally is far less than no rebuttal at all. Until
>>>>>>> you (and others) gain this technical capacity there is no sense
>>>>>>> continuing a dialogue.
>>>>>>
>>>>>> How is it correct when H(P,P) sayts P(P) is non-halting when a
>>>>>> direct exectuion of P(P) or a correct simulation by simualte(P,P)
>>>>>> (where P still calls the previous H) show that it halts.
>>>>>
>>>>> Most everyone here can see: (from my updated simplified paper)
>>>>> It is a verified fact that the input that is correctly simulated by
>>>>> H(P,P) cannot possibly terminate normally.
>>>>
>>>> I have shown that a simulating halting decider needn't be recursive
>>>> in nature thus can terminate normally.  You are wrong on all fronts.
>>>>
>>>> /Flibble
>>> No you have not.
>>
>> Yes I have: see my post "An idea for a simulating halt decider" in
>> comp.theory.
>>
>> /Flibble
>>
>>
>
> Its gibberish, you never provide the halt status criterion measure.
>

On 7/14/22 6:49 AM, olcott wrote:
> On 7/14/2022 1:52 AM, Mr Flibble wrote:
>> On Wed, 13 Jul 2022 23:29:53 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 7/13/2022 11:18 PM, Mr Flibble wrote:
>>>> On Wed, 13 Jul 2022 21:55:25 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 7/13/2022 9:21 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/13/22 10:08 PM, olcott wrote:
>>>>>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
>>>>>>>> On 7/13/22 9:34 PM, olcott wrote:
>>>>>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/13/22 8:06 PM, olcott wrote:
>>>>>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
>>>>>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago
>>>>>>>>>>>>>>>>>>>>>>> when the article came out.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot
>>>>>>>>>>>>>>>>>>>>>> called Olcott? He keeps
>>>>>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there
>>>>>>>>>>>>>>>>>>>>>> are two guys here who
>>>>>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing
>>>>>>>>>>>>>>>>>>>>>> him.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a
>>>>>>>>>>>>>>>>>>>>>> response; Olcott won't go
>>>>>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
>>>>>>>>>>>>>>>>>>>>>> completely. Just ignore him;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated
>>>>>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very
>>>>>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading computer
>>>>>>>>>>>>>>>>>>>>> scientist.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>>>>>>>>>> presentation so that everyone here can easily
>>>>>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting
>>>>>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would
>>>>>>>>>>>>>>>>>>>> you please stop posting this same thing millions of
>>>>>>>>>>>>>>>>>>>> times?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For any program H that might determine if programs
>>>>>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some
>>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to H and
>>>>>>>>>>>>>>>>>>> then specifically do the opposite of what H predicts
>>>>>>>>>>>>>>>>>>> P will do. *No H can exist that handles this case*
>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is not verified until it is understood that P and
>>>>>>>>>>>>>>>>>>> H implement the classical halting problem "impossible
>>>>>>>>>>>>>>>>>>> input" template (as shown above) and refutes this
>>>>>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its
>>>>>>>>>>>>>>>>>>> input never terminates normally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *This is the key software engineering that I need
>>>>>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that
>>>>>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly
>>>>>>>>>>>>>>>>>>> terminate normally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The next level of pure software engineering is that
>>>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input
>>>>>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the
>>>>>>>>>>>>>>>>>>> case that only the top 5% of software engineers can
>>>>>>>>>>>>>>>>>>> validate this point.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>      if (H(x, x))
>>>>>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>      Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated
>>>>>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion.
>>>>>>>>>>>>>>>>>>> H aborts its simulation on this basis and rejects
>>>>>>>>>>>>>>>>>>> this input as non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The execution trace of function P() simulated by
>>>>>>>>>>>>>>>>>>> function H() shows:
>>>>>>>>>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
>>>>>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *That was all of the software engineering that I need
>>>>>>>>>>>>>>>>>>> validated*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of
>>>>>>>>>>>>>>>>>>> software engineering
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it.
>>>>>>>>>>>>>>>>>> The CORRECT version of (3) looks ALL the way through
>>>>>>>>>>>>>>>>>> the loop, which includes in H, and will find the
>>>>>>>>>>>>>>>>>> condtional there.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
>>>>>>>>>>>>>>>>> possibly terminate normally. (I have better words now).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that the program represented by the input, P(P)
>>>>>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
>>>>>>>>>>>>>>> its correctly simulated input cannot possibly terminate
>>>>>>>>>>>>>>> normally.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WHAT Change of subject?
>>>>>>>>>>>>>
>>>>>>>>>>>>> IT IS A VERIFIED FACT THAT
>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated input cannot possibly terminate normally.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only possible correct rebuttal must show all the steps
>>>>>>>>>>>>> of exactly how the input to simulating halt decider H(P,P)
>>>>>>>>>>>>> does terminate normally when H correctly simulates this
>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since I already proved that this is false entirely on the
>>>>>>>>>>>>> basis of verified fact this is impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This requires that a function called in essentially
>>>>>>>>>>>>> infinite recursion to return a value to its caller this is
>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Most everyone here knows that every function called in
>>>>>>>>>>>>> infinite recursion never returns any value to its caller.
>>>>>>>>>>>>> There is no gibberish that you can say that would convince
>>>>>>>>>>>>> them otherwise.
>>>>>>>>>>>> That can't be a verified fact because the opposite is a
>>>>>>>>>>>> verified fact, that the CORRECT simulation of the input to
>>>>>>>>>>>> H(P,P), which is the correct simulation of P(P) will
>>>>>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does.
>>>>>>>>>>>
>>>>>>>>>>> I already gave Paul N a great explanation of that on
>>>>>>>>>>> comp.theory. I won't be able to see your reply there because
>>>>>>>>>>> I have you blocked there.
>>>>>>>>>>>
>>>>>>>>>>> My explanation to wjj even sums it up better:
>>>>>>>>>>>
>>>>>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>>>>>>>>>    > On 7/13/2022 3:47 PM, wij wrote:
>>>>>>>>>>>    >> The property that an arbitrary program P will finish
>>>>>>>>>>>    >> running or not is  determined by running P as an
>>>>>>>>>>>    >> independent program
>>>>>>>>>>>
>>>>>>>>>>> Because that would require that a halt decider must sometimes
>>>>>>>>>>> make its
>>>>>>>>>>> halt status decision on a basis other than the actual
>>>>>>>>>>> behavior of its actual input that long standing
>>>>>>>>>>> misconception has been refuted.
>>>>>>>>>>
>>>>>>>>>> No, because all the behavior of that program exists will be
>>>>>>>>>> encoded in the representation of the program given to the
>>>>>>>>>> decider.
>>>>>>>>>
>>>>>>>>> The reason that I stop talking to you is that you make false
>>>>>>>>> assumptions that are utterly impervious to all reasoning.
>>>>>>>>>
>>>>>>>>> It is a verified fact that the input that is correctly
>>>>>>>>> simulated by H(P,P) cannot possibly terminate normally. It is
>>>>>>>>> also a verified fact that the direct execution of P(P) does
>>>>>>>>> terminate normally.
>>>>>>>>>
>>>>>>>>> It is also common knowledge that the correct simulation of a
>>>>>>>>> program is a correct measure of the behavior of this program.
>>>>>>>>>
>>>>>>>>> This conclusively proves that H(P,P) is correct to reject its
>>>>>>>>> input as non-halting and the behavior of a non-input cannot
>>>>>>>>> possibly contradict this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly
>>>>>>>> simulate the input (since it aborts it to return 0) so it
>>>>>>>> doesn't MATTER that if it was a different program it wouldn't
>>>>>>>> be able to simulate to a final state.
>>>>>>>
>>>>>>>
>>>>>>> That you (and others) continue to lack the technical capacity to
>>>>>>> comprehend that H does correctly predict that its complete and
>>>>>>> correct simulation of its input would never result in this input
>>>>>>> terminating normally is far less than no rebuttal at all. Until
>>>>>>> you (and others) gain this technical capacity there is no sense
>>>>>>> continuing a dialogue.
>>>>>>
>>>>>> How is it correct when H(P,P) sayts P(P) is non-halting when a
>>>>>> direct exectuion of P(P) or a correct simulation by simualte(P,P)
>>>>>> (where P still calls the previous H) show that it halts.
>>>>>
>>>>> Most everyone here can see: (from my updated simplified paper)
>>>>> It is a verified fact that the input that is correctly simulated by
>>>>> H(P,P) cannot possibly terminate normally.
>>>>
>>>> I have shown that a simulating halting decider needn't be recursive
>>>> in nature thus can terminate normally.  You are wrong on all fronts.
>>>>
>>>> /Flibble
>>>
>>> You have shown that you don't fully understand the concept of
>>> unreachable code.
>>
>> Of course I understand the concept of unreachable code in fact I recall
>> giving you several examples of it.
>>
>> /Flibble
>>
>
> I did not say that you have no idea what unreachable code is, you simply
> do not understand that infinite recursion prevents all the code below
> the infinitely recursive function call to ever be reached.
>
> There are a sequence of many posts that prove this where you believe
> that removing the infinite loop eliminates the pathological relationship.
>
> You and Richard are at the bottom 10% of technical competence in this
> forum most everyone else could validate that I am correct.
>

On Thu, 14 Jul 2022 05:43:56 -0500
olcott <NoOne@NoWhere.com> wrote:
>On 7/14/2022 1:53 AM, Mr Flibble wrote:
>> Yes I have: see my post "An idea for a simulating halt decider" in
>> comp.theory.
>>
>> /Flibble
>>
>>
>
>Its gibberish, you never provide the halt status criterion measure.

The irony, strong it is in this one!

On Thu, 14 Jul 2022 05:49:52 -0500
olcott <NoOne@NoWhere.com> wrote:

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

On 14.07.22 02:33, olcott wrote:
> 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.
>>possible to
>> 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.
>
Oh my God! This is the point where you show (as "IT IS A PROVEN AND
VERIFIED FACT") that you don't understand anything about anything at all.

It would even be impossible to start teaching you anything whatsoever.
Your mind just doesn't work the way it should for it to grasp what it's
being taught.

If I had a pupil like you in school I would call his parents and
recommend them to change school. In your case I recommend to change the
subject: maths and computer science just aren't for you. You would
however make a great artist.

On 7/14/2022 4:46 PM, Freethinker wrote:
> On 14.07.22 02:33, olcott wrote:
>> 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.
>>> possible to 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.
>>
> Oh my God! This is the point where you show (as "IT IS A PROVEN AND
> VERIFIED FACT") that you don't understand anything about anything at all.
>
> It would even be impossible to start teaching you anything whatsoever.
> Your mind just doesn't work the way it should for it to grasp what it's
> being taught.
>
> If I had a pupil like you in school I would call his parents and
> recommend them to change school. In your case I recommend to change the
> subject: maths and computer science just aren't for you. You would
> however make a great artist.

Carefully study the first page of my paper and see if you think the same
thing.

*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

Am 12.07.2022 um 14:48 schrieb olcott:

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

Seeing the big picture here means that it is pointless
to deal with this topic so fruitlessly for years.

olcott <NoOne@NoWhere.com> wrote:

> Most everyone here can see: (from my updated simplified paper)
> It is a verified fact that the input that is correctly simulated by
> H(P,P) cannot possibly terminate normally.

"Most everyone" here who sees this, please raise your hand now?

Followup-to: comp.theory
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */