On 7/31/2022 8:29 PM, Richard Damon wrote:
>
> On 7/31/22 9:13 PM, olcott wrote:
>> On 7/31/2022 1:59 PM, Richard Damon wrote:
>>>
>>> On 7/31/22 2:39 PM, 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:
>>>
>>> Right, but that doesn;t mean the PROGRAM P(P) doesn't actually have
>>> the ability to exist.
>>>
>>> we just need to change main() to
>>>
>>> int main() {
>>>      Output("Input_Halts = ", H(P,P));
>>>      P(P);
>>>      Output("P(P) Halted");
>>> }
>>>
>>> To make it come into existance.
>>>
>>> If this isn't allowed, you system isn't Turing complete and you
>>> "universe" you are defining worthless to talk about the Halting Problem.
>>>
>>>>
>>>> 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, "BY H".
>>>
>>> But that DOESN'T prove the the input represents a non-halting input,
>> Within these halt deciding principles it does:
>>
>> 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.
>>
>
> And the ACTUAL BEHAVIOR of the input to H(M,x) is the behavior of M(x).
> DEFINITION.

Yet the execution trace of the provably correct** simulation of the
input to H(P,P) by H proves otherwise.

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.

The ultimate measure of the behavior of the input to H(P,P) is the
provably correct** simulation of this input by H.

** line-by-line the execution trace of the simulation of the input to
H(P,P) by H exactly matches line-by-line of the x86 source-code of P.

Prior to my very extensive work with simulating halt deciders it seems
that no one ever noticed that these behaviors possible could diverge so
they used what they thought was a good proxy for the actual behavior of
the actual input to H. It turns out that this proxy was imperfect.

It seems to me that the input that was specifically designed to have a
"pathological" relationship to H is the only exception to the rule where
the actual behavior of the actual input diverges from the behavior of
the direct execution of this same input.

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

On Sunday, July 31, 2022 at 9:52:48 PM UTC-4, olcott wrote:
> On 7/31/2022 8:29 PM, Richard Damon wrote:
> >
> > On 7/31/22 9:13 PM, olcott wrote:
> >> On 7/31/2022 1:59 PM, Richard Damon wrote:
> >>>
> >>> On 7/31/22 2:39 PM, 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:
> >>>
> >>> Right, but that doesn;t mean the PROGRAM P(P) doesn't actually have
> >>> the ability to exist.
> >>>
> >>> we just need to change main() to
> >>>
> >>> int main() {
> >>> Output("Input_Halts = ", H(P,P));
> >>> P(P);
> >>> Output("P(P) Halted");
> >>> }
> >>>
> >>> To make it come into existance.
> >>>
> >>> If this isn't allowed, you system isn't Turing complete and you
> >>> "universe" you are defining worthless to talk about the Halting Problem.
> >>>
> >>>>
> >>>> 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, "BY H".
> >>>
> >>> But that DOESN'T prove the the input represents a non-halting input,
> >> Within these halt deciding principles it does:
> >>
> >> 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.
> >>
> >
> > And the ACTUAL BEHAVIOR of the input to H(M,x) is the behavior of M(x).
> > DEFINITION.
> Yet the execution trace of the provably correct** simulation of the
> input to H(P,P) by H proves otherwise.

Correct but not complete, so H's simulation is not definitive.

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

Which by the definition of what a halt decider is required to compute:

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.

On 7/31/22 10:00 PM, 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.
>

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

On 7/31/22 9:52 PM, olcott wrote:
> On 7/31/2022 8:29 PM, Richard Damon wrote:
>>
>> On 7/31/22 9:13 PM, olcott wrote:
>>> On 7/31/2022 1:59 PM, Richard Damon wrote:
>>>>
>>>> On 7/31/22 2:39 PM, 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:
>>>>
>>>> Right, but that doesn;t mean the PROGRAM P(P) doesn't actually have
>>>> the ability to exist.
>>>>
>>>> we just need to change main() to
>>>>
>>>> int main() {
>>>>      Output("Input_Halts = ", H(P,P));
>>>>      P(P);
>>>>      Output("P(P) Halted");
>>>> }
>>>>
>>>> To make it come into existance.
>>>>
>>>> If this isn't allowed, you system isn't Turing complete and you
>>>> "universe" you are defining worthless to talk about the Halting
>>>> Problem.
>>>>
>>>>>
>>>>> 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, "BY H".
>>>>
>>>> But that DOESN'T prove the the input represents a non-halting input,
>>> Within these halt deciding principles it does:
>>>
>>> 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.
>>>
>>
>> And the ACTUAL BEHAVIOR of the input to H(M,x) is the behavior of
>> M(x). DEFINITION.
>
> Yet the execution trace of the provably correct** simulation of the
> input to H(P,P) by H proves otherwise.

WHERE??

It shows P(P) calling H(P,P).

We KNOW from elsewhere in the trace that H(P,P) will return 0 to main,
thus, H(P,P) MUST return 0 to P or the simulation is actually INCORRECT,
or at least the logic used to extend past the point of simulation to
predict the final behavior is UNSOUND.

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

And the actual behavior of the input to H(P,P) is the actual behavior of
the program P(P) or you problem is incorrectly defined, because that is
the call that P makes to ask that question.

On Sun, 31 Jul 2022 21:32:31 -0500
olcott <NoOne@NoWhere.com> 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.
>
> When H(P,P) correctly simulates its input this input presents the
> infinite recursion control flow behavior pattern to H.
>
> If the execution trace of function Y() shows:
> (1) Function X() is called twice in sequence from the same machine
> address of Y().
> (2) With the same arguments to X().
> (3) With no control flow instructions between the invocation of Y()
> and its call to X().
>
> Then the function call from Y() to X() is infinitely recursive.

On 7/31/22 10:32 PM, 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.
>
> When H(P,P) correctly simulates its input this input presents the
> infinite recursion control flow behavior pattern to H.
>
> If the execution trace of function Y() shows:
> (1) Function X() is called twice in sequence from the same machine
> address of Y().
> (2) With the same arguments to X().
> (3) With no control flow instructions between the invocation of Y() and
> its call to X().
>
> Then the function call from Y() to X() is infinitely recursive.
>
>

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.

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

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.

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.

olcott <NoOne@NoWhere.com> 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...
>
> 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.
>
> All those not agreeing with the above Key Facts are either:
> (a) Not interested in an honest dialogue or
> (b) Have insufficient software engineering technical competence
> Both will be ignored.

Let us assume, for the sake of discussion that I accept these both
(we will need to return to these points a bit later, though).

Let us compile this program using your H() decider.
When you run this program, what is the output of main()?

--
/* * * 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 8/1/2022 7:09 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> 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...
>>
>> 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.
>>
>> All those not agreeing with the above Key Facts are either:
>> (a) Not interested in an honest dialogue or
>> (b) Have insufficient software engineering technical competence
>> Both will be ignored.
>
> Let us assume, for the sake of discussion that I accept these both
> (we will need to return to these points a bit later, though).
>
> Let us compile this program using your H() decider.
> When you run this program, what is the output of main()?
>

"Input_Halts = 0"

#include <stdint.h>
typedef void (*ptr)();

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

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

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

*Matched infinite recursion detection criteria*
(1) P() calls H(P,P) twice in sequence.
(2) With the same arguments.
(3) With no control flow instructions in P preceding its invocation of
H(P,P) that could escape repeated simulations.

....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages

--
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 Sunday, July 31, 2022 at 11:46:44 PM UTC-4, 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.

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:

On 8/1/2022 7:22 AM, Dennis Bush wrote:
> On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, 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:

>>> 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.
>
> Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
>

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.

When we accept the concept of a UTM then we know that the actual
behavior of the actual input is ultimately determined by the correct
simulation that H(P,P) performs on its input.

This simulation is verified as correct in that the line-by-line
execution trace of the simulated input exactly matches the line-by-line
x86 source-code of P specifies.

H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.

> Pa(Pa) halts, therefore Ha(Pa,Pa)==0 is wrong.
>
>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>
>>> Bottom line: Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>
>>>
>>>>
>>>> When H(P,P) correctly simulates its input this input presents the
>>>> infinite recursion control flow behavior pattern to H.
>>>>
>>>> If the execution trace of function Y() shows:
>>>> (1) Function X() is called twice in sequence from the same machine
>>>> address of Y().
>>>> (2) With the same arguments to X().
>>>> (3) With no control flow instructions between the invocation of Y() and
>>>> its call to X().
>>>
>>> And again you're lying by attempting to make your point with a criteria
>>> you've implicitly admitted is incorrect by your failure to respond to
>>> explanations as to why it is wrong.
>> I never explicitly or implicitly admitted that the following criteria is
>> incorrect and when I called you out on to provide an time and date stamp
>> quote of me admitting this you utterly failed because there was no such
>> quote.
>
> You absolutely implicitly admitted as much, and I did provide a quote of this implicit admission:
>
> On Saturday, July 30, 2022 at 4:03:14 PM UTC-4, Dennis Bush wrote:
>> On Saturday, July 30, 2022 at 3:56:10 PM UTC-4, olcott wrote:
>>> Paste a date-time-stamped quote of me saying that the above criteria is
>>> not valid.
>> You did implicitly when it was explained why it was wrong:
>>
>> On Wednesday, July 27, 2022 at 3:09:51 PM UTC-4, Dennis Bush wrote:
>>> On Wednesday, July 27, 2022 at 2:46:26 PM UTC-4, olcott wrote:
>>>> Below I show that pattern that any expert of the x86 language can spot
>>>> as specifying infinitely recursive simulation right below.
>>> And your pattern is incorrect as proved by UTM(Pa,Pa) halting, and as several people have explained to you.
>>>
>>> It's not enough that there are no instructions in the function P prior to the call to the function H that branch. There have to be no instructions *between successive calls to H* that branch, and there are *several* functions in the function H as well as other functions that it calls.
>>>
>>> So this explains why your criteria 3 is wrong. Failure to explain why the above is wrong will be taken as admission that your criteria 3 is invalid.
>>
>> And you chose not to explain why the refutation is wrong:
>>
>> On Wednesday, July 27, 2022 at 3:36:14 PM UTC-4, Dennis Bush wrote:
>>> I noticed that you failed to explain why my description of your criteria 3 is wrong. That means you implicitly admit that it is in fact wrong. That also means that if you use it again to make your argument that you're explicitly lying.
>
> Just to spell it out, the above shows where I explained why point 3 is wrong and challenged you to refute my explanation, with a failure to do so taken as an admission that it is correct. It also shows where I pointed out that you in fact failed to do so.
>
> In other words, the above is your implicit admission that point 3 is incorrect.
>
> But I'll give you one more chance: explain why my description of point 3 being incorrect is wrong. Failure to do so will be taken as an admission by you that my explanation is correct and that point 3 is invalid.
>
> And if you later claim that you never made such an implicit admission, I will point to this message as proof to the contrary.
>
>>
>> On 7/30/2022 2:37 PM, Dennis Bush wrote:
>>> On Saturday, July 30, 2022 at 3:29:24 PM UTC-4, olcott wrote:
>>>> If the execution trace of function Y() shows:
>>>> (1) Function X() is called twice in sequence from the same machine
>>>> address of Y().
>>>> (2) With the same arguments to X().
>>>> (3) With no control flow instructions between the
>>>> invocation of Y() and its call to X().
>>>
>>> So I see you're back to actively lying about your results by using a
>>> criteria you've admitted is invalid.
>>

So the post just my words and nothing else:
where I explicitly admitted that my criteria is invalid.
You know that no such admission exists.

When you say that I did X knowing full well that I did not do X what do
we have? (a) a box of chocolates (b) a hungry cat (c) a lie

THIS CRITERIA IS PERFECT IN THAT IS HAS NO FALSE POSITIVES
EVERY SINGLE TIME THAT THIS CRITERIA IS MATCHED WE HAVE INFINITE RECURSION
If the execution trace of function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same arguments to X().
(3) With no control flow instructions between the invocation of Y() and
its call to X().

Then the function call from Y() to X() is infinitely recursive.

--
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:

> On 8/1/2022 7:09 AM, Otto J. Makela wrote:
>> Let us assume, for the sake of discussion that I accept these both
>> (we will need to return to these points a bit later, though).
>> Let us compile this program using your H() decider.
>> When you run this program, what is the output of main()?
>
> "Input_Halts = 0"

So the call of H(P,P) in main() returned 0.

Why isn't that incorrect, since the first thing P(P) does
is call H(P,P) and if this returns 0 it exits normally?

--
/* * * 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 Monday, August 1, 2022 at 8:54:10 AM UTC-4, olcott wrote:
> On 8/1/2022 7:22 AM, Dennis Bush wrote:
> > On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, 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:
>
> >>> 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.
> >
> > Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
> >
> 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.

FALSE. A halt decider is required to map the halting function:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

So Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.

On 8/1/2022 7:56 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/1/2022 7:09 AM, Otto J. Makela wrote:
>>> Let us assume, for the sake of discussion that I accept these both
>>> (we will need to return to these points a bit later, though).
>>> Let us compile this program using your H() decider.
>>> When you run this program, what is the output of main()?
>>
>> "Input_Halts = 0"
>
> So the call of H(P,P) in main() returned 0.
>
> Why isn't that incorrect, since the first thing P(P) does
> is call H(P,P) and if this returns 0 it exits normally?
>

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.

When we accept the concept of a UTM then we know that the actual
behavior of the actual input is ultimately determined by the correct
simulation that H(P,P) performs on its input.

This simulation is verified as correct in that the line-by-line
execution trace of the simulated input exactly matches the line-by-line
x86 source-code of P specifies.

H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.

The correctly simulated input to H(P,P) remains stuck in infinite
recursion until H aborts its simulation. In every case where H must
abort its simulation to prevent the infinite simulation of its input H
is correct to abort this simulation and report non-halting.

--
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 8/1/2022 8:11 AM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 8:54:10 AM UTC-4, olcott wrote:
>> On 8/1/2022 7:22 AM, Dennis Bush wrote:
>>> On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, 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:
>>
>>>>> 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.
>>>
>>> Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
>>>
>> 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.
>
> FALSE. A halt decider is required to map the halting function:
>
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt
>
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.

When we accept the concept of a UTM then we know that the actual
behavior of the actual input is ultimately determined by the correct
simulation that H(P,P) performs on its input.

This simulation is verified as correct in that the line-by-line
execution trace of the simulated input exactly matches the line-by-line
x86 source-code of P specifies.

H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.

The correctly simulated input to H(P,P) remains stuck in infinite
recursion until H aborts its simulation. In every case where H must
abort its simulation to prevent the infinite simulation of its input H
is correct to abort this simulation and report non-halting.

--
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 Monday, August 1, 2022 at 9:20:48 AM UTC-4, olcott wrote:
> On 8/1/2022 8:11 AM, Dennis Bush wrote:
> > On Monday, August 1, 2022 at 8:54:10 AM UTC-4, olcott wrote:
> >> On 8/1/2022 7:22 AM, Dennis Bush wrote:
> >>> On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, 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:
> >>
> >>>>> 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.
> >>>
> >>> Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
> >>>
> >> 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.
> >
> > FALSE. A halt decider is required to map the halting function:
> >
> > H(X,Y)==1 if and only if X(Y) halts, and
> > H(X,Y)==0 if and only if X(Y) does not halt
> >
> 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.

FALSE. A halt decider is required to map the halting function:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

So Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.

On 8/1/2022 8:26 AM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 9:20:48 AM UTC-4, olcott wrote:
>> On 8/1/2022 8:11 AM, Dennis Bush wrote:
>>> On Monday, August 1, 2022 at 8:54:10 AM UTC-4, olcott wrote:
>>>> On 8/1/2022 7:22 AM, Dennis Bush wrote:
>>>>> On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, 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:
>>>>
>>>>>>> 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.
>>>>>
>>>>> Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
>>>>>
>>>> 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.
>>>
>>> FALSE. A halt decider is required to map the halting function:
>>>
>>> H(X,Y)==1 if and only if X(Y) halts, and
>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>
>> 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.
>
> FALSE. A halt decider is required to map the halting function:
>
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt
>
> So Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>
>

H must only compute the mapping from the sequence of instructions that
it is presented with and not allowed to compute any other mapping.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and its not allowed to return the
sum of 4+5.

--
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 Monday, August 1, 2022 at 9:34:52 AM UTC-4, olcott wrote:
> On 8/1/2022 8:26 AM, Dennis Bush wrote:
> > On Monday, August 1, 2022 at 9:20:48 AM UTC-4, olcott wrote:
> >> On 8/1/2022 8:11 AM, Dennis Bush wrote:
> >>> On Monday, August 1, 2022 at 8:54:10 AM UTC-4, olcott wrote:
> >>>> On 8/1/2022 7:22 AM, Dennis Bush wrote:
> >>>>> On Sunday, July 31, 2022 at 11:46:44 PM UTC-4, 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:
> >>>>
> >>>>>>> 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.
> >>>>>
> >>>>> Which is not what a halt decider is required to do. Ha(Pa,Pa) is required to report if Pa(Pa) halts.
> >>>>>
> >>>> 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.
> >>>
> >>> FALSE. A halt decider is required to map the halting function:
> >>>
> >>> H(X,Y)==1 if and only if X(Y) halts, and
> >>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>
> >> 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.
> >
> > FALSE. A halt decider is required to map the halting function:
> >
> > H(X,Y)==1 if and only if X(Y) halts, and
> > H(X,Y)==0 if and only if X(Y) does not halt
> >
> > So Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >
> >
> H must only compute the mapping from the sequence of instructions that
> it is presented with and not allowed to compute any other mapping.

And for Ha(Pa,Pa) that sequence of instruction is by definition Pa(Pa), not Pn(Pn) as you claim:

On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> H(P,P) is asking would the input that I correctly emulate ever reach its
> "ret" instruction (final state) if I never stopped emulating it?