On Wed, 13 Jul 2022 21:55:25 -0500
olcott <NoOne@NoWhere.com> wrote:

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

I have shown that a simulating halting decider needn't be recursive in
nature thus can terminate normally. You are wrong on all fronts.

/Flibble