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

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 * * * * * * */

On 7/18/2022 9:51 AM, Otto J. Makela wrote:
> 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

Everyone here that does not see this only does not see this because they
make sure to never look at the paper having already made up their mind
and closed it that I must be wrong.

*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

olcott <NoOne@NoWhere.com> wrote:

> Everyone here that does not see this only does not see this because
> they make sure to never look at the paper having already made up their
> mind and closed it that I must be wrong.
>
> *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

I did read your (single-page!?) paper, but I must admit I cannot see how
"The above shows that the simulated P cannot possibly terminate normally"
follows from 1, 2 and 3.

Would you care to explain that deduction in more detail, using me as your
rubber duck?

https://en.wikipedia.org/wiki/Rubber_duck_debugging
--
/* * * 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 * * * * * * */

On 7/18/22 11:08 AM, olcott wrote:
> On 7/18/2022 9:51 AM, Otto J. Makela wrote:
>> 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
>
> Everyone here that does not see this only does not see this because they
> make sure to never look at the paper having already made up their mind
> and closed it that I must be wrong.
>
>
> *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
>
>
>

Nope, YOU are the one that doesn't see the truth because you refuse to
actually look at the evidence.

Perhaps the problem is that you are too ignorant of the actual rules to
understand what things mean, but that doesn't mean your false statements
based on that ignorance is actually True.

2022-07-18, Otto J. Makela <om@iki.fi> schrieb:
> 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?

Personally I fail to see the relevance of this subject for c.l.c
--
Jan v/d Broek
balglaas@dds.nl

On 7/18/2022 10:47 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> Everyone here that does not see this only does not see this because
>> they make sure to never look at the paper having already made up their
>> mind and closed it that I must be wrong.
>>
>> *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
>
> I did read your (single-page!?) paper, but I must admit I cannot see how
> "The above shows that the simulated P cannot possibly terminate normally"
> follows from 1, 2 and 3.
>
> Would you care to explain that deduction in more detail, using me as your
> rubber duck?
>
> https://en.wikipedia.org/wiki/Rubber_duck_debugging

*I have been very sick in the hospital since Monday, I just got out*

Understanding how my halt decider works requires understanding how it
correctly rejects Example 02 Infinite_Recursion(). Only on this basis
can it be understood how infinite recursion detection has been adapted
to detect infinitely nested simulation without the need for static local
data.

The following linked paper now includes five pages of the complete C
source-code of my halt decider.

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

H may or may not be a computable function. Even if H is not a computable
function it might still be applied to the broader field of termination
analysis. https://en.wikipedia.org/wiki/Termination_analysis

I want it to be fully evaluated from the software engineering level so
that mutual agreement is reached before anything related to computable
functions is even mentioned.

*Here is the claim I want evaluated* H(P,P) does correctly predict that
its simulated P would never reach its "return" instruction.

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

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

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

When simulating halt decider H(P,P) simulates its input it can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.

This is the same criteria used for infinite recursion detection that has
been adapted so that it does not need static local memory to see that
the same function has been called with the same arguments twice in
sequence with no conditional-branch escape.

Because H knows its own machine address H need not see P call H(P,P)
more than once because H already knows that it was called with these
same arguments. This eliminates the need for H to have static local
memory that communicates between different invocations of itself.

--
Copyright 2022 Pete Olcott

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

On 7/21/2022 7:48 AM, Jan van den Broek wrote:
> 2022-07-18, Otto J. Makela <om@iki.fi> schrieb:
>> 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?
>
> Personally I fail to see the relevance of this subject for c.l.c

It is an algorithm written in C and the source-code is now published.
I need to have the algorithm validated.

*Halting problem proofs refuted on the basis of software engineering*?

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

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

On 7/21/22 5:46 PM, olcott wrote:
> On 7/18/2022 10:47 AM, Otto J. Makela wrote:
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> Everyone here that does not see this only does not see this because
>>> they make sure to never look at the paper having already made up their
>>> mind and closed it that I must be wrong.
>>>
>>> *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
>>>
>>
>> I did read your (single-page!?) paper, but I must admit I cannot see how
>> "The above shows that the simulated P cannot possibly terminate normally"
>> follows from 1, 2 and 3.
>>
>> Would you care to explain that deduction in more detail, using me as your
>> rubber duck?
>>
>> https://en.wikipedia.org/wiki/Rubber_duck_debugging
>
> *I have been very sick in the hospital since Monday, I just got out*
>
> Understanding how my halt decider works requires understanding how it
> correctly rejects Example 02 Infinite_Recursion(). Only on this basis
> can it be understood how infinite recursion detection has been adapted
> to detect infinitely nested simulation without the need for static local
> data.
>
> The following linked paper now includes five pages of the complete C
> source-code of my halt decider.
>
> 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
>
>
>
>
>
> H may or may not be a computable function. Even if H is not a computable
> function it might still be applied to the broader field of termination
> analysis. https://en.wikipedia.org/wiki/Termination_analysis
>
> I want it to be fully evaluated from the software engineering level so
> that mutual agreement is reached before anything related to computable
> functions is even mentioned.
>
> *Here is the claim I want evaluated* H(P,P) does correctly predict that
> its simulated P would never reach its "return" instruction.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> When simulating halt decider H(P,P) simulates its input it can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.
>

Except that (3) doesn't show that P(P is non-halting, since the H(P,P)
that P calls can decide to terminate further operations and return to it
and make it Halting.

That copy of H is PART of that algorithm of P, and thus, this is a
"normal" halting for P.

> This is the same criteria used for infinite recursion detection that has
> been adapted so that it does not need static local memory to see that
> the same function has been called with the same arguments twice in
> sequence with no conditional-branch escape.
>
> Because H knows its own machine address H need not see P call H(P,P)
> more than once because H already knows that it was called with these
> same arguments. This eliminates the need for H to have static local
> memory that communicates between different invocations of itself.
>

But it uses the incorrect assumed behavior of H when it makes the analysis.

H shows that if H was written so that it never aborted, then P(P) would
never halt.

But the fact is, that isn't the H that this P is calling, so the
conclusion isn't applicable to the P we have.

On Thu, 21 Jul 2022 16:46:59 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/18/2022 10:47 AM, Otto J. Makela wrote:
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> Everyone here that does not see this only does not see this because
> >> they make sure to never look at the paper having already made up
> >> their mind and closed it that I must be wrong.
> >>
> >> *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
> >>
> >
> > I did read your (single-page!?) paper, but I must admit I cannot
> > see how "The above shows that the simulated P cannot possibly
> > terminate normally" follows from 1, 2 and 3.
> >
> > Would you care to explain that deduction in more detail, using me
> > as your rubber duck?
> >
> > https://en.wikipedia.org/wiki/Rubber_duck_debugging
>
> *I have been very sick in the hospital since Monday, I just got out*
>
> Understanding how my halt decider works requires understanding how it
> correctly rejects Example 02 Infinite_Recursion(). Only on this basis
> can it be understood how infinite recursion detection has been
> adapted to detect infinitely nested simulation without the need for
> static local data.
>
> The following linked paper now includes five pages of the complete C
> source-code of my halt decider.
>
> 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
>
>
>
>
> H may or may not be a computable function. Even if H is not a
> computable function it might still be applied to the broader field of
> termination analysis.
> https://en.wikipedia.org/wiki/Termination_analysis
>
> I want it to be fully evaluated from the software engineering level
> so that mutual agreement is reached before anything related to
> computable functions is even mentioned.
>
> *Here is the claim I want evaluated* H(P,P) does correctly predict
> that its simulated P would never reach its "return" instruction.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> When simulating halt decider H(P,P) simulates its input it can see
> that: (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.
>
> This is the same criteria used for infinite recursion detection that
> has been adapted so that it does not need static local memory to see
> that the same function has been called with the same arguments twice
> in sequence with no conditional-branch escape.
>
> Because H knows its own machine address H need not see P call H(P,P)
> more than once because H already knows that it was called with these
> same arguments. This eliminates the need for H to have static local
> memory that communicates between different invocations of itself.
>

Your H still gets the answer to the following wrong:

void Px(ptr x)
{ int Halt_Status = H(x, x);
(void) Halt_Status;
return;
}

Px always halts; the fact that your H disagrees is a symptom of the
fact that:

1) [Strachey 1965] and associated proofs have no recursion.
2) You are incorrect to map "infinite recursion" to "non-halting".
3) Given (1) and (2) your H is invalid.

/Flibble

olcott <NoOne@NoWhere.com> wrote:

> It is an algorithm written in C and the source-code is now published.
> I need to have the algorithm validated.

To see what people say of it, please publish the complete, compilable
C source, instead of something incomplete embedded in a pdf document.
Thank you.
--
/* * * 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 * * * * * * */

On 7/22/2022 6:39 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> It is an algorithm written in C and the source-code is now published.
>> I need to have the algorithm validated.
>
> To see what people say of it, please publish the complete, compilable
> C source, instead of something incomplete embedded in a pdf document.
> Thank you.

https://www.liarparadox.org/2022_07_22.zip

--
Copyright 2022 Pete Olcott

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

olcott <NoOne@NoWhere.com> wrote:

> https://www.liarparadox.org/2022_07_22.zip

Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
small errors from decode.c, because of two variable loop declarations.

decode.c: In function ‘x86emu_run’:
decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^
decode.c:251:5: note: use option -std=c99 or -std=gnu99 to compile your code
decode.c:257:14: error: redefinition of ‘N’
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^
decode.c:251:14: note: previous definition of ‘N’ was here
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^
decode.c:257:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^

Trying to add the -std=c99 compiler flag broke the assembly stuff from
x86emu_int.h, so maybe easiest is to edit that single variable "int N"
into a separate declaration?

The same issue for a couple of declarations in Halt7_Commented_Out.c

----

Unfortunately "make all" still fails rather catastrophically with
Halt7_Commented_Out.c but I have no time to debug why, I suspect that
I'm doing this on a x86_64 may have something to do with it:

% make all
true --changelog changelog
gcc -c -g -O2 -fPIC -fvisibility=hidden -fomit-frame-pointer -Wall Halt7_Commented_Out.c
Halt7_Commented_Out.c:5:0: warning: ignoring #pragma warning [-Wunknown-pragmas]
#pragma warning (disable: 4717)
^
Halt7_Commented_Out.c: In function ‘Decide_Halting’:
Halt7_Commented_Out.c:288:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
PushBack(*execution_trace, (u32)*decoded, sizeof(Decoded_Line_Of_Code));
^
Halt7_Commented_Out.c:289:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Aborted = Needs_To_Be_Aborted((Decoded_Line_Of_Code*)*execution_trace, Address_of_H, P, I);
^
Halt7_Commented_Out.c: In function ‘Init_slave_state’:
Halt7_Commented_Out.c:355:7: warning: variable ‘Size’ set but not used [-Wunused-but-set-variable]
u32 Size;
^
Halt7_Commented_Out.c:354:7: warning: variable ‘Capacity’ set but not used [-Wunused-but-set-variable]
u32 Capacity;
^
Halt7_Commented_Out.c: In function ‘H’:
Halt7_Commented_Out.c:9:13: error: a label can only be part of a statement and a declaration is not a statement
#define u32 uint32_t
^
Halt7_Commented_Out.c:493:3: note: in expansion of macro ‘u32’
u32 End_Of_Code;
^
Halt7_Commented_Out.c:9:13: error: expected expression before ‘uint32_t’
#define u32 uint32_t
^
Halt7_Commented_Out.c:494:3: note: in expansion of macro ‘u32’
u32 Address_of_H; // 2022-06-17
^
Halt7_Commented_Out.c:495:48: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
u32 code_end = get_code_end((u32)P);
^
Halt7_Commented_Out.c:501:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 10000);
^
Halt7_Commented_Out.c:503:9: error: expected ‘(’ before ‘lea’
__asm lea eax, HERE // 2022-06-18
^
Halt7_Commented_Out.c:503:9: error: unknown type name ‘lea’
Halt7_Commented_Out.c:504:9: error: expected ‘(’ before ‘sub’
__asm sub eax, 6 // 2022-06-18
^
Halt7_Commented_Out.c:511:27: error: ‘Address_of_H’ undeclared (first use in this function)
Output("Address_of_H:", Address_of_H); // 2022-06-11
^
Halt7_Commented_Out.c:511:27: note: each undeclared identifier is reported only once for each function it appears in
Halt7_Commented_Out.c:513:64: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
&slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
^
Halt7_Commented_Out.c:513:72: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
&slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
^
Halt7_Commented_Out.c:503:18: warning: unused variable ‘HERE’ [-Wunused-variable]
__asm lea eax, HERE // 2022-06-18
^
Halt7_Commented_Out.c:503:13: warning: unused variable ‘eax’ [-Wunused-variable]
__asm lea eax, HERE // 2022-06-18
^
Halt7_Commented_Out.c:493:7: warning: unused variable ‘End_Of_Code’ [-Wunused-variable]
u32 End_Of_Code;
^
Halt7_Commented_Out.c:492:1: warning: label ‘HERE’ defined but not used [-Wunused-label]
HERE:
^
Halt7_Commented_Out.c: In function ‘main’:
Halt7_Commented_Out.c:700:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make: *** [Halt7_Commented_Out.o] Error 1

--
/* * * 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 * * * * * * */

olcott <NoOne@NoWhere.com> wrote:

> https://www.liarparadox.org/2022_07_22.zip

Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
small errors from decode.c, because of two variable loop declarations.

decode.c: In function ‘x86emu_run’:
decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^
decode.c:251:5: note: use option -std=c99 or -std=gnu99 to compile your code
decode.c:257:14: error: redefinition of ‘N’
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^
decode.c:251:14: note: previous definition of ‘N’ was here
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^
decode.c:257:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
^

Trying to add the -std=c99 compiler flag broke the assembly stuff from
x86emu_int.h, so maybe easiest is to edit that single variable "int N"
into a separate declaration?

The same issue for a couple of "s32" declarations in Halt7_Commented_Out.c

----

Unfortunately "make all" still fails rather catastrophically with
Halt7_Commented_Out.c but I have no time to debug why, I suspect that
I'm doing this on a x86_64 machine may have something to do with it:

% make all
true --changelog changelog
gcc -c -g -O2 -fPIC -fvisibility=hidden -fomit-frame-pointer -Wall Halt7_Commented_Out.c
Halt7_Commented_Out.c:5:0: warning: ignoring #pragma warning [-Wunknown-pragmas]
#pragma warning (disable: 4717)
^
Halt7_Commented_Out.c: In function ‘Decide_Halting’:
Halt7_Commented_Out.c:288:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
PushBack(*execution_trace, (u32)*decoded, sizeof(Decoded_Line_Of_Code));
^
Halt7_Commented_Out.c:289:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Aborted = Needs_To_Be_Aborted((Decoded_Line_Of_Code*)*execution_trace, Address_of_H, P, I);
^
Halt7_Commented_Out.c: In function ‘Init_slave_state’:
Halt7_Commented_Out.c:355:7: warning: variable ‘Size’ set but not used [-Wunused-but-set-variable]
u32 Size;
^
Halt7_Commented_Out.c:354:7: warning: variable ‘Capacity’ set but not used [-Wunused-but-set-variable]
u32 Capacity;
^
Halt7_Commented_Out.c: In function ‘H’:
Halt7_Commented_Out.c:9:13: error: a label can only be part of a statement and a declaration is not a statement
#define u32 uint32_t
^
Halt7_Commented_Out.c:493:3: note: in expansion of macro ‘u32’
u32 End_Of_Code;
^
Halt7_Commented_Out.c:9:13: error: expected expression before ‘uint32_t’
#define u32 uint32_t
^
Halt7_Commented_Out.c:494:3: note: in expansion of macro ‘u32’
u32 Address_of_H; // 2022-06-17
^
Halt7_Commented_Out.c:495:48: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
u32 code_end = get_code_end((u32)P);
^
Halt7_Commented_Out.c:501:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 10000);
^
Halt7_Commented_Out.c:503:9: error: expected ‘(’ before ‘lea’
__asm lea eax, HERE // 2022-06-18
^
Halt7_Commented_Out.c:503:9: error: unknown type name ‘lea’
Halt7_Commented_Out.c:504:9: error: expected ‘(’ before ‘sub’
__asm sub eax, 6 // 2022-06-18
^
Halt7_Commented_Out.c:511:27: error: ‘Address_of_H’ undeclared (first use in this function)
Output("Address_of_H:", Address_of_H); // 2022-06-11
^
Halt7_Commented_Out.c:511:27: note: each undeclared identifier is reported only once for each function it appears in
Halt7_Commented_Out.c:513:64: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
&slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
^
Halt7_Commented_Out.c:513:72: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
&slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
^
Halt7_Commented_Out.c:503:18: warning: unused variable ‘HERE’ [-Wunused-variable]
__asm lea eax, HERE // 2022-06-18
^
Halt7_Commented_Out.c:503:13: warning: unused variable ‘eax’ [-Wunused-variable]
__asm lea eax, HERE // 2022-06-18
^
Halt7_Commented_Out.c:493:7: warning: unused variable ‘End_Of_Code’ [-Wunused-variable]
u32 End_Of_Code;
^
Halt7_Commented_Out.c:492:1: warning: label ‘HERE’ defined but not used [-Wunused-label]
HERE:
^
Halt7_Commented_Out.c: In function ‘main’:
Halt7_Commented_Out.c:700:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make: *** [Halt7_Commented_Out.o] Error 1

--
/* * * 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 * * * * * * */

On 7/22/22 9:36 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> https://www.liarparadox.org/2022_07_22.zip
>
> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
> small errors from decode.c, because of two variable loop declarations.
>
> decode.c: In function ‘x86emu_run’:
> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
> decode.c:251:5: note: use option -std=c99 or -std=gnu99 to compile your code
> decode.c:257:14: error: redefinition of ‘N’
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
> decode.c:251:14: note: previous definition of ‘N’ was here
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
> decode.c:257:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
>
> Trying to add the -std=c99 compiler flag broke the assembly stuff from
> x86emu_int.h, so maybe easiest is to edit that single variable "int N"
> into a separate declaration?
>
> The same issue for a couple of "s32" declarations in Halt7_Commented_Out.c
>

His issue is he is using the non-standard conforming Visual Studio to
compile his code. I would need to look closer to figure out which version.

Microsoft has for a LONG time been "off" in their support for the C
programming language.

> ----
>
> Unfortunately "make all" still fails rather catastrophically with
> Halt7_Commented_Out.c but I have no time to debug why, I suspect that
> I'm doing this on a x86_64 machine may have something to do with it:
>
> % make all
> true --changelog changelog
> gcc -c -g -O2 -fPIC -fvisibility=hidden -fomit-frame-pointer -Wall Halt7_Commented_Out.c
> Halt7_Commented_Out.c:5:0: warning: ignoring #pragma warning [-Wunknown-pragmas]
> #pragma warning (disable: 4717)
> ^
> Halt7_Commented_Out.c: In function ‘Decide_Halting’:
> Halt7_Commented_Out.c:288:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> PushBack(*execution_trace, (u32)*decoded, sizeof(Decoded_Line_Of_Code));
> ^
> Halt7_Commented_Out.c:289:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> Aborted = Needs_To_Be_Aborted((Decoded_Line_Of_Code*)*execution_trace, Address_of_H, P, I);
> ^
> Halt7_Commented_Out.c: In function ‘Init_slave_state’:
> Halt7_Commented_Out.c:355:7: warning: variable ‘Size’ set but not used [-Wunused-but-set-variable]
> u32 Size;
> ^
> Halt7_Commented_Out.c:354:7: warning: variable ‘Capacity’ set but not used [-Wunused-but-set-variable]
> u32 Capacity;
> ^
> Halt7_Commented_Out.c: In function ‘H’:
> Halt7_Commented_Out.c:9:13: error: a label can only be part of a statement and a declaration is not a statement
> #define u32 uint32_t
> ^
> Halt7_Commented_Out.c:493:3: note: in expansion of macro ‘u32’
> u32 End_Of_Code;
> ^
> Halt7_Commented_Out.c:9:13: error: expected expression before ‘uint32_t’
> #define u32 uint32_t
> ^
> Halt7_Commented_Out.c:494:3: note: in expansion of macro ‘u32’
> u32 Address_of_H; // 2022-06-17
> ^
> Halt7_Commented_Out.c:495:48: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> u32 code_end = get_code_end((u32)P);
> ^
> Halt7_Commented_Out.c:501:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 10000);
> ^
> Halt7_Commented_Out.c:503:9: error: expected ‘(’ before ‘lea’
> __asm lea eax, HERE // 2022-06-18
> ^
> Halt7_Commented_Out.c:503:9: error: unknown type name ‘lea’
> Halt7_Commented_Out.c:504:9: error: expected ‘(’ before ‘sub’
> __asm sub eax, 6 // 2022-06-18
> ^
> Halt7_Commented_Out.c:511:27: error: ‘Address_of_H’ undeclared (first use in this function)
> Output("Address_of_H:", Address_of_H); // 2022-06-11
> ^
> Halt7_Commented_Out.c:511:27: note: each undeclared identifier is reported only once for each function it appears in
> Halt7_Commented_Out.c:513:64: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> &slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
> ^
> Halt7_Commented_Out.c:513:72: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> &slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
> ^
> Halt7_Commented_Out.c:503:18: warning: unused variable ‘HERE’ [-Wunused-variable]
> __asm lea eax, HERE // 2022-06-18
> ^
> Halt7_Commented_Out.c:503:13: warning: unused variable ‘eax’ [-Wunused-variable]
> __asm lea eax, HERE // 2022-06-18
> ^
> Halt7_Commented_Out.c:493:7: warning: unused variable ‘End_Of_Code’ [-Wunused-variable]
> u32 End_Of_Code;
> ^
> Halt7_Commented_Out.c:492:1: warning: label ‘HERE’ defined but not used [-Wunused-label]
> HERE:
> ^
> Halt7_Commented_Out.c: In function ‘main’:
> Halt7_Commented_Out.c:700:1: warning: control reaches end of non-void function [-Wreturn-type]
> }
> ^
> make: *** [Halt7_Commented_Out.o] Error 1
>

On 7/22/2022 8:35 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> https://www.liarparadox.org/2022_07_22.zip
>
> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
> small errors from decode.c, because of two variable loop declarations.
>
> decode.c: In function ‘x86emu_run’:
> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
> decode.c:251:5: note: use option -std=c99 or -std=gnu99 to compile your code
> decode.c:257:14: error: redefinition of ‘N’
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
> decode.c:251:14: note: previous definition of ‘N’ was here
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
> decode.c:257:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^
>
> Trying to add the -std=c99 compiler flag broke the assembly stuff from
> x86emu_int.h, so maybe easiest is to edit that single variable "int N"
> into a separate declaration?
>
> The same issue for a couple of declarations in Halt7_Commented_Out.c
>
> ----
>
> Unfortunately "make all" still fails rather catastrophically with
> Halt7_Commented_Out.c but I have no time to debug why, I suspect that
> I'm doing this on a x86_64 may have something to do with it:
>
> % make all
> true --changelog changelog
> gcc -c -g -O2 -fPIC -fvisibility=hidden -fomit-frame-pointer -Wall Halt7_Commented_Out.c
> Halt7_Commented_Out.c:5:0: warning: ignoring #pragma warning [-Wunknown-pragmas]
> #pragma warning (disable: 4717)
> ^
> Halt7_Commented_Out.c: In function ‘Decide_Halting’:
> Halt7_Commented_Out.c:288:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> PushBack(*execution_trace, (u32)*decoded, sizeof(Decoded_Line_Of_Code));
> ^
> Halt7_Commented_Out.c:289:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> Aborted = Needs_To_Be_Aborted((Decoded_Line_Of_Code*)*execution_trace, Address_of_H, P, I);
> ^
> Halt7_Commented_Out.c: In function ‘Init_slave_state’:
> Halt7_Commented_Out.c:355:7: warning: variable ‘Size’ set but not used [-Wunused-but-set-variable]
> u32 Size;
> ^
> Halt7_Commented_Out.c:354:7: warning: variable ‘Capacity’ set but not used [-Wunused-but-set-variable]
> u32 Capacity;
> ^
> Halt7_Commented_Out.c: In function ‘H’:
> Halt7_Commented_Out.c:9:13: error: a label can only be part of a statement and a declaration is not a statement
> #define u32 uint32_t
> ^
> Halt7_Commented_Out.c:493:3: note: in expansion of macro ‘u32’
> u32 End_Of_Code;
> ^
> Halt7_Commented_Out.c:9:13: error: expected expression before ‘uint32_t’
> #define u32 uint32_t
> ^
> Halt7_Commented_Out.c:494:3: note: in expansion of macro ‘u32’
> u32 Address_of_H; // 2022-06-17
> ^
> Halt7_Commented_Out.c:495:48: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> u32 code_end = get_code_end((u32)P);
> ^
> Halt7_Commented_Out.c:501:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 10000);
> ^
> Halt7_Commented_Out.c:503:9: error: expected ‘(’ before ‘lea’
> __asm lea eax, HERE // 2022-06-18
> ^
> Halt7_Commented_Out.c:503:9: error: unknown type name ‘lea’
> Halt7_Commented_Out.c:504:9: error: expected ‘(’ before ‘sub’
> __asm sub eax, 6 // 2022-06-18
> ^
> Halt7_Commented_Out.c:511:27: error: ‘Address_of_H’ undeclared (first use in this function)
> Output("Address_of_H:", Address_of_H); // 2022-06-11
> ^
> Halt7_Commented_Out.c:511:27: note: each undeclared identifier is reported only once for each function it appears in
> Halt7_Commented_Out.c:513:64: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> &slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
> ^
> Halt7_Commented_Out.c:513:72: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> &slave_state, &slave_stack, Address_of_H, (u32)P, (u32)I))
> ^
> Halt7_Commented_Out.c:503:18: warning: unused variable ‘HERE’ [-Wunused-variable]
> __asm lea eax, HERE // 2022-06-18
> ^
> Halt7_Commented_Out.c:503:13: warning: unused variable ‘eax’ [-Wunused-variable]
> __asm lea eax, HERE // 2022-06-18
> ^
> Halt7_Commented_Out.c:493:7: warning: unused variable ‘End_Of_Code’ [-Wunused-variable]
> u32 End_Of_Code;
> ^
> Halt7_Commented_Out.c:492:1: warning: label ‘HERE’ defined but not used [-Wunused-label]
> HERE:
> ^
> Halt7_Commented_Out.c: In function ‘main’:
> Halt7_Commented_Out.c:700:1: warning: control reaches end of non-void function [-Wreturn-type]
> }
> ^
> make: *** [Halt7_Commented_Out.o] Error 1
>

*Microsoft Visual Studio Community 2017*
https://visualstudio.microsoft.com/vs/older-downloads/

--
Copyright 2022 Pete Olcott

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

om@iki.fi (Otto J. Makela) writes:

> olcott <NoOne@NoWhere.com> wrote:
>
>> https://www.liarparadox.org/2022_07_22.zip
>
> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
> small errors from decode.c, because of two variable loop declarations.
>
> decode.c: In function ‘x86emu_run’:
> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> ^

And so on...

But this code a distraction because:

(a) Every file that defines H will dump core as soon as any allocated
storage is used. (Look at the definition of Allocate.)

(b) (And I can't stress this enough...) *He has already told us that H
gives the wrong answer*. There is no dispute about the fact that H(P,P)
== false even though P(P) halts.

The only reason to look at this junk code would be to work out what PO
thinks is the justification for claiming the wrong answer is the right
one. But there's no need to do that either has he has published the
criterion by which H gets the wrong answer. Presumably, the complete
code, when posted, will implement this incorrect criterion.

--
Ben.