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

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

The smartest software engineers here can also see that H does correctly
predict this. People at the bottom 10% of technical competence may not
see either one of these. No sense continuing to talk to these people.

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

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