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