On Mon, 1 Aug 2022 07:08:07 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/1/2022 6:17 AM, Richard Damon wrote:
> >
> > On 7/31/22 11:46 PM, olcott wrote:
> >> On 7/31/2022 9:58 PM, Dennis Bush wrote:
> >>> On Sunday, July 31, 2022 at 10:32:39 PM UTC-4, olcott wrote:
> >>>> On 7/31/2022 9:20 PM, Dennis Bush wrote:
> >>>>> On Sunday, July 31, 2022 at 10:00:34 PM UTC-4, olcott wrote:
> >>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>
> >>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>> 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));
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider
> >>>>>>>>>>>>>>>> that correctly
> >>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the
> >>>>>>>>>>>>>>>> simulation will
> >>>>>>>>>>>>>>>> never
> >>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of
> >>>>>>>>>>>>>>>> its input:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this
> >>>>>>>>>>>>>>>> again. (3) Emulated H(P,P) simulates its input with
> >>>>>>>>>>>>>>>> an x86 emulator.
> >>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this
> >>>>>>>>>>>>>>>> again. (5) Emulated H(P,P) simulates its input with
> >>>>>>>>>>>>>>>> an x86 emulator...
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is what happens if H doesn't abort its
> >>>>>>>>>>>>>>> simulation. If H ever
> >>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY
> >>>>>>>>>>>>>>> determine that
> >>>>>>>>>>>>>>> its
> >>>>>>>>>>>>>>> input is non-halting, will match this pattern,
> >>>>>>>>>>>>>>> because it will
> >>>>>>>>>>>>>>> NEVER
> >>>>>>>>>>>>>>> in finite time be able to actually correctly prove
> >>>>>>>>>>>>>>> the input is
> >>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined
> >>>>>>>>>>>>>>> (incorrectly) as non-halting, if it is seen by H in
> >>>>>>>>>>>>>>> the simulation, and H stops its
> >>>>>>>>>>>>>>> simulation and returns 0, causes the actual program
> >>>>>>>>>>>>>>> P(P) to Halt.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Since that is the actual meaning of the question
> >>>>>>>>>>>>>>> H(P,P) if H is
> >>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is
> >>>>>>>>>>>>>>> incorrect to return 0
> >>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it
> >>>>>>>>>>>>>>> is Halting.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If you want to repeat you LIE that the input to
> >>>>>>>>>>>>>>> H(P,P) generate a
> >>>>>>>>>>>>>>> different sequence of configurations that P(P),
> >>>>>>>>>>>>>>> please provide the
> >>>>>>>>>>>>>>> FIRST configuration in the sequence that is
> >>>>>>>>>>>>>>> different, and is
> >>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the
> >>>>>>>>>>>>>>> input.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to
> >>>>>>>>>>>>>>> H(P,P) is "proof"
> >>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and
> >>>>>>>>>>>>>>> thus falls into the
> >>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is
> >>>>>>>>>>>>>>>> correctly
> >>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret"
> >>>>>>>>>>>>>>>> instruction
> >>>>>>>>>>>>>>>> whether or not H aborts its simulation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No, that is only true if H doesn't abort its
> >>>>>>>>>>>>>>> simuation.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So you believe that when H aborts its simulation this
> >>>>>>>>>>>>>> causes the
> >>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after
> >>>>>>>>>>>>>> it has been
> >>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>> reviewers
> >>>>>>>>>>>>>> will
> >>>>>>>>>>>>>> understand that you are not a sufficiently technically
> >>>>>>>>>>>>>> competent
> >>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If H aborts its simulation, then a correct and
> >>>>>>>>>>>>>>> complete simulation of
> >>>>>>>>>>>>>>> the input will reach the return instruction.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P
> >>>>>>>>>>>>>> that is no
> >>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>> running will continue several more execution steps and
> >>>>>>>>>>>>>> reach its
> >>>>>>>>>>>>>> "ret"
> >>>>>>>>>>>>>> instruction even though it has been forced to stop
> >>>>>>>>>>>>>> running before ever
> >>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
> >>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>> 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));
> >>>>>>>>>>>> }
> >>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>> simulated
> >>>>>>>>>>>> by H
> >>>>>>>>>>>> cannot possibly reach the "ret" instruction of this
> >>>>>>>>>>>> simulated P whether
> >>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, I agree that there is no implementation of the
> >>>>>>>>>>> function H that
> >>>>>>>>>>> can simulate the function call P(P) to a final state.
> >>>>>>>>>>> Which has nothing to do with the requirements of a halt
> >>>>>>>>>>> decider.
> >>>>>>>>>>>
> >>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>> A halt decider must compute the mapping from its inputs to
> >>>>>>>>>> an accept
> >>>>>>>>>> or reject state on the basis of the actual behavior that
> >>>>>>>>>> is actually
> >>>>>>>>>> specified by these inputs.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> No, just that the "Actual Behvior" is determined by the
> >>>>>>>>> actual behavior of the program the input represents,
> >>>>>>>> In other words you do not believe that the correct
> >>>>>>>> simulation of an input necessarily has the exact same
> >>>>>>>> sequence of instructions that are
> >>>>>>>> specified by this input, thus you reject the concept of UTM
> >>>>>>>> simulation.
> >>>>>>>>
> >>>>>>>
> >>>>>>> No. a COMPLETE and correct simulation will recreate the
> >>>>>>> behavior of the
> >>>>>>> input. The COMPLETE part is important.
> >>>>>>>
> >>>>>> Not at all, as long as the partial simulation correctly
> >>>>>> matches any correct infinite behavior pattern then there is no
> >>>>>> need to wait until the end of time to see that an infinite
> >>>>>> loop never halts.
> >>>>>
> >>>>> But it doesn't match an infinite behavior pattern as
> >>>>> demonstrated by Pa(Pa) halting, or equivalently the correct and
> >>>>> COMPLETE simulation by UTM(Pa,Pa).
> >>>> That is like checking for black dogs in your living room by
> >>>> looking for white cats in your kitchen.
> >>>>
> >>>> A halt decider must only examine the sequence of instructions
> >>>> that it was presented with, not any other sequence.
> >>>
> >>> Then why do you insist that Ha(Pa,Pa) must report the halt status
> >>> of Pn(Pn)?
> >>>
> >>
> >> H(P,P) correctly predicts that its correct and complete simulation
> >> of its input would never reach the "ret" instruction of this
> >> input.
> >
> > No, it doesn't.
>
> *When you deny basic facts than I have to stop talking to you*
> *When you deny basic facts than I have to stop talking to you*
> *When you deny basic facts than I have to stop talking to you*
> *When you deny basic facts than I have to stop talking to you*
> *When you deny basic facts than I have to stop talking to you*
>
> H(P,P) correctly aborts its simulation when the simulated input
> matches correctly this correct generic infinite recursion behavior
> pattern:

There is no infinite recursion in [Strachey 1965] and associated proofs
so your decider is wrong to rely on detecting it.

/Flibble