olcott <NoOne@NoWhere.com> wrote:

> 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?
[...]
> 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.

Why does the correctly simulated H(P,P) not similarly detect infinite
recursion (inside the simulation) and return 0?

--
/* * * 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 8:54 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> 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?
> [...]
>> 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.
>
> Why does the correctly simulated H(P,P) not similarly detect infinite
> recursion (inside the simulation) and return 0?
>

Of the nested simulations the outermost one sees that the infinite
recursion criteria is met first.

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

On 7/31/2022 9:30 PM, Richard Damon wrote:
> 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.
>>
>
> But the pattern is only a CORRECT infinite behavior pattern if the
> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> H(P,P) aborts its simulation.
So then you agree the H(P,P) does correctly determine the halt status of
its input, yet disagree that H is supposed to examine its input instead
it must examine the behavior of the non-input P(P) ?

On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> On 7/31/2022 9:30 PM, Richard Damon wrote:
> > 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.
> >>
> >
> > But the pattern is only a CORRECT infinite behavior pattern if the
> > PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> > H(P,P) aborts its simulation.
> So then you agree the H(P,P) does correctly determine the halt status of
> its input, yet disagree that H is supposed to examine its input instead
> it must examine the behavior of the non-input P(P) ?

On Monday, August 1, 2022 at 11:34:37 PM UTC+1, olcott wrote:
> So then you agree the H(P,P) does correctly determine the halt status of
> its input, yet disagree that H is supposed to examine its input instead
> it must examine the behavior of the non-input P(P) ?

The first argument in the call H(P, P) is P. The second argument is also P. Thus H(P, P) is supposed to determine whether P(P) halts or not. That is the "input" to H.

On 8/1/22 8:08 AM, olcott 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*

On 8/1/22 8:54 AM, 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.
>
> 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.
>
>

Nope, it fails for H(P,P) and P(P) since P(P) halts when H)P,P) returns 0.

This has been pointed out MANY times, so you are just shown to be a bald
face LIAR, or an IDIOT.

On 8/1/22 9:34 AM, 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.
>
> 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.
>
>

So, you are just proving that yoou don't even understand what a Decider
is, and particularly a Halt Decider.

Nor do you know what the meaning of the word DEFINITION.

YOU FAIL.

On 8/1/22 6:34 PM, olcott wrote:
> On 7/31/2022 9:30 PM, Richard Damon wrote:
>> 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.
>>>
>>
>> But the pattern is only a CORRECT infinite behavior pattern if the
>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't
>> if H(P,P) aborts its simulation.
> So then you agree the H(P,P) does correctly determine the halt status of
> its input, yet disagree that H is supposed to examine its input instead
> it must examine the behavior of the non-input P(P) ?
>
>

On 8/1/22 11:24 AM, olcott wrote:
> On 8/1/2022 8:54 AM, Otto J. Makela wrote:
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> 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?
>> [...]
>>> 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.
>>
>> Why does the correctly simulated H(P,P) not similarly detect infinite
>> recursion (inside the simulation) and return 0?
>>
>
> Of the nested simulations the outermost one sees that the infinite
> recursion criteria is met first.

But the inner one would if the input was correcctly simulated to that point.

Just because H can't do it, doesn't mean that it doesn't happen.
>
> 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.
>
>

(3) is FALSE, as explained many times before.

On 8/1/2022 6:06 PM, Paul N wrote:
> On Monday, August 1, 2022 at 11:34:37 PM UTC+1, olcott wrote:
>> So then you agree the H(P,P) does correctly determine the halt status of
>> its input, yet disagree that H is supposed to examine its input instead
>> it must examine the behavior of the non-input P(P) ?
>
> The first argument in the call H(P, P) is P. The second argument is also P. Thus H(P, P) is supposed to determine whether P(P) halts or not. That is the "input" to H.

No it is not the input to H.

The behavior of directly executed P(P) is NOT the same behavior
as when H(P,P) correctly simulates its input because the execution
order of P(P) first is reversed when H(P,P) is invoked first.

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

int main()
{ P(P);
}

When P calls H(P,P) this is essentially the first call of
infinite recursion. When H(P,P) simulates its input this
is essentially the second call of infinite recursion.

H can see the infinite recursion specified by its input and
aborts its simulation on that basis. As with all infinite
recursion when any call is aborted the whole sequence stops.
In this case when H(P,P) aborts its simulation it returns to
its caller.

The input to H(P,P) is infinitely recursive (as proven by the fact
the the simulation never stops unless aborted) therefore H did
correctly determine the halt status of this input.

That is was supposed to determine the halt status of a non-input
seems absurd and is rejected on the basis that software engineering
won't allow it.

--
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 6:06 PM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>> 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.
>>>>
>>>
>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>> H(P,P) aborts its simulation.
>> So then you agree the H(P,P) does correctly determine the halt status of
>> its input, yet disagree that H is supposed to examine its input instead
>> it must examine the behavior of the non-input P(P) ?
>
> Sure, Ha(Pa,Pa) reports the halt status of "its input".

On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> > On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>> 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.
> >>>>
> >>>
> >>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>> H(P,P) aborts its simulation.
> >> So then you agree the H(P,P) does correctly determine the halt status of
> >> its input, yet disagree that H is supposed to examine its input instead
> >> it must examine the behavior of the non-input P(P) ?
> >
> > Sure, Ha(Pa,Pa) reports the halt status of "its input".
> I count that as a huge breakthrough when 99% of of reviewers reject
> everything that I say out-of-hand without even looking at it and
> the remaining 1% are so laser focused on finding fault that they hardly
> pay any attention to what I say.

On 8/1/2022 7:16 PM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>> 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.
>>>>>>
>>>>>
>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>> H(P,P) aborts its simulation.
>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>> its input, yet disagree that H is supposed to examine its input instead
>>>> it must examine the behavior of the non-input P(P) ?
>>>
>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>> I count that as a huge breakthrough when 99% of of reviewers reject
>> everything that I say out-of-hand without even looking at it and
>> the remaining 1% are so laser focused on finding fault that they hardly
>> pay any attention to what I say.
>
> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>
>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>
>>> 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
>>>
>
> Where I point out you're answering the wrong question.
>
> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>
>> The behavior of directly executed P(P) is NOT the same behavior
>> as when H(P,P) correctly simulates its input because the execution
>> order of P(P) first is reversed when H(P,P) is invoked first.
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> P(P);
>> }
>>
>> When P calls H(P,P) this is essentially the first call of
>> infinite recursion. When H(P,P) simulates its input this
>> is essentially the second call of infinite recursion.
>>
>> H can see the infinite recursion specified by its input and
>> aborts its simulation on that basis. As with all infinite
>> recursion when any call is aborted the whole sequence stops.
>> In this case when H(P,P) aborts its simulation it returns to
>> its caller.
>>
>> The input to H(P,P) is infinitely recursive (as proven by the fact
>> the the simulation never stops unless aborted) therefore H did
>> correctly determine the halt status of this input.
>>
>> That is was supposed to determine the halt status of a non-input
>> seems absurd and is rejected on the basis that software engineering
>> won't allow it.
>
> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>

On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> > On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>> 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.
> >>>>>>
> >>>>>
> >>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>> H(P,P) aborts its simulation.
> >>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>> its input, yet disagree that H is supposed to examine its input instead
> >>>> it must examine the behavior of the non-input P(P) ?
> >>>
> >>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >> I count that as a huge breakthrough when 99% of of reviewers reject
> >> everything that I say out-of-hand without even looking at it and
> >> the remaining 1% are so laser focused on finding fault that they hardly
> >> pay any attention to what I say.
> >
> > But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >
> >>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>
> >>> 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
> >>>
> >
> > Where I point out you're answering the wrong question.
> >
> > Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >
> >> The behavior of directly executed P(P) is NOT the same behavior
> >> as when H(P,P) correctly simulates its input because the execution
> >> order of P(P) first is reversed when H(P,P) is invoked first.
> >> void P(ptr x)
> >> {
> >> int Halt_Status = H(x, x);
> >> if (Halt_Status)
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> P(P);
> >> }
> >>
> >> When P calls H(P,P) this is essentially the first call of
> >> infinite recursion. When H(P,P) simulates its input this
> >> is essentially the second call of infinite recursion.
> >>
> >> H can see the infinite recursion specified by its input and
> >> aborts its simulation on that basis. As with all infinite
> >> recursion when any call is aborted the whole sequence stops.
> >> In this case when H(P,P) aborts its simulation it returns to
> >> its caller.
> >>
> >> The input to H(P,P) is infinitely recursive (as proven by the fact
> >> the the simulation never stops unless aborted) therefore H did
> >> correctly determine the halt status of this input.
> >>
> >> That is was supposed to determine the halt status of a non-input
> >> seems absurd and is rejected on the basis that software engineering
> >> won't allow it.
> >
> > If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >
> You know that never said anything like that:
>
> Try and find a date-and-time stamped quote of me
> saying anything like that.

On 8/1/2022 7:36 PM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>> H(P,P) aborts its simulation.
>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>
>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>> everything that I say out-of-hand without even looking at it and
>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>> pay any attention to what I say.
>>>
>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>
>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>
>>>>> 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
>>>>>
>>>
>>> Where I point out you're answering the wrong question.
>>>
>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>
>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>> as when H(P,P) correctly simulates its input because the execution
>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>> void P(ptr x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P(P);
>>>> }
>>>>
>>>> When P calls H(P,P) this is essentially the first call of
>>>> infinite recursion. When H(P,P) simulates its input this
>>>> is essentially the second call of infinite recursion.
>>>>
>>>> H can see the infinite recursion specified by its input and
>>>> aborts its simulation on that basis. As with all infinite
>>>> recursion when any call is aborted the whole sequence stops.
>>>> In this case when H(P,P) aborts its simulation it returns to
>>>> its caller.
>>>>
>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>> the the simulation never stops unless aborted) therefore H did
>>>> correctly determine the halt status of this input.
>>>>
>>>> That is was supposed to determine the halt status of a non-input
>>>> seems absurd and is rejected on the basis that software engineering
>>>> won't allow it.
>>>
>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>
>> You know that never said anything like that:
>>
>> Try and find a date-and-time stamped quote of me
>> saying anything like that.
>
> That's precisely what the comment I've been quoting is saying:
>
> 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?
>
> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>
> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).

On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> > On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>> 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.
> >>>>>>>>
> >>>>>>>
> >>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>> H(P,P) aborts its simulation.
> >>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>
> >>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>> everything that I say out-of-hand without even looking at it and
> >>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>> pay any attention to what I say.
> >>>
> >>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>
> >>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>
> >>>>> 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
> >>>>>
> >>>
> >>> Where I point out you're answering the wrong question.
> >>>
> >>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>
> >>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>> as when H(P,P) correctly simulates its input because the execution
> >>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>> void P(ptr x)
> >>>> {
> >>>> int Halt_Status = H(x, x);
> >>>> if (Halt_Status)
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> P(P);
> >>>> }
> >>>>
> >>>> When P calls H(P,P) this is essentially the first call of
> >>>> infinite recursion. When H(P,P) simulates its input this
> >>>> is essentially the second call of infinite recursion.
> >>>>
> >>>> H can see the infinite recursion specified by its input and
> >>>> aborts its simulation on that basis. As with all infinite
> >>>> recursion when any call is aborted the whole sequence stops.
> >>>> In this case when H(P,P) aborts its simulation it returns to
> >>>> its caller.
> >>>>
> >>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>> the the simulation never stops unless aborted) therefore H did
> >>>> correctly determine the halt status of this input.
> >>>>
> >>>> That is was supposed to determine the halt status of a non-input
> >>>> seems absurd and is rejected on the basis that software engineering
> >>>> won't allow it.
> >>>
> >>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>
> >> You know that never said anything like that:
> >>
> >> Try and find a date-and-time stamped quote of me
> >> saying anything like that.
> >
> > That's precisely what the comment I've been quoting is saying:
> >
> > 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?
> >
> > If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >
> > So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).

On 8/1/22 8:42 PM, olcott wrote:
> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it
>>>>>>>> doesn't if
>>>>>>>> H(P,P) aborts its simulation.
>>>>>>> So then you agree the H(P,P) does correctly determine the halt
>>>>>>> status of
>>>>>>> its input, yet disagree that H is supposed to examine its input
>>>>>>> instead
>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>
>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>> everything that I say out-of-hand without even looking at it and
>>>>> the remaining 1% are so laser focused on finding fault that they
>>>>> hardly
>>>>> pay any attention to what I say.
>>>>
>>>> But is seems you're reading comprehension is failing you again. I
>>>> know that when you say "H(P,P) does correctly determine the halt
>>>> status of its input", what you really mean is "there is no
>>>> implementation of the function H that can simulate the function call
>>>> P(P) to a final state". And that is true, and is what I was agreeing
>>>> about. That become more clear with what I said next:
>>>>
>>>>>> But that's apparently not the same as the halt status of the
>>>>>> machine the input represents, specifically Pa(Pa), as per the
>>>>>> definition of the function a halt decider is required to compute:
>>>>>>
>>>>>> 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
>>>>>>
>>>>
>>>> Where I point out you're answering the wrong question.
>>>>
>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that
>>>> follows from here down is bunk because it depends on the wrong
>>>> answer being right.
>>>>
>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>> void P(ptr x)
>>>>> {
>>>>> int Halt_Status = H(x, x);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> P(P);
>>>>> }
>>>>>
>>>>> When P calls H(P,P) this is essentially the first call of
>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>> is essentially the second call of infinite recursion.
>>>>>
>>>>> H can see the infinite recursion specified by its input and
>>>>> aborts its simulation on that basis. As with all infinite
>>>>> recursion when any call is aborted the whole sequence stops.
>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>> its caller.
>>>>>
>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>> the the simulation never stops unless aborted) therefore H did
>>>>> correctly determine the halt status of this input.
>>>>>
>>>>> That is was supposed to determine the halt status of a non-input
>>>>> seems absurd and is rejected on the basis that software engineering
>>>>> won't allow it.
>>>>
>>>> If determining the halt status of a non-input seems so absurd, why
>>>> do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>
>>> You know that never said anything like that:
>>>
>>> Try and find a date-and-time stamped quote of me
>>> saying anything like that.
>>
>> That's precisely what the comment I've been quoting is saying:
>>
>> 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?
>>
>> If Ha never stops emulating, then it is no longer Ha.  It is Hn.  That
>> also means that Pa is no longer Pa since it's now calling Hn.  It is
>> now Pn.
>>
>> So by postulating that Ha has different behavior, you change the
>> input.  So the above is EXACTLY saying that Ha(Pa,Pa) must report on
>> the behavior of Pn(Pn).
>
> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> A simulating halt decider is always correct to abort the simulation of
> any input that it correctly predicts would never otherwise never stop
> running.

On 8/1/2022 7:50 PM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>
>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>> pay any attention to what I say.
>>>>>
>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>
>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>
>>>>> Where I point out you're answering the wrong question.
>>>>>
>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>
>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> int Halt_Status = H(x, x);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> P(P);
>>>>>> }
>>>>>>
>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>> is essentially the second call of infinite recursion.
>>>>>>
>>>>>> H can see the infinite recursion specified by its input and
>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>> its caller.
>>>>>>
>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>> correctly determine the halt status of this input.
>>>>>>
>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>> won't allow it.
>>>>>
>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>
>>>> You know that never said anything like that:
>>>>
>>>> Try and find a date-and-time stamped quote of me
>>>> saying anything like that.
>>>
>>> That's precisely what the comment I've been quoting is saying:
>>>
>>> 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?
>>>
>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>
>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>
> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> of Hn it is essentially the same as a UTM.
>
>> A simulating halt decider is always correct to abort the simulation of
>> any input that it correctly predicts would never otherwise never stop
>> running.
>
> A simulating halt decider, like any 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
>

On 8/1/22 7:38 PM, olcott wrote:
> On 8/1/2022 6:06 PM, Paul N wrote:
>> On Monday, August 1, 2022 at 11:34:37 PM UTC+1, olcott wrote:
>>> So then you agree the H(P,P) does correctly determine the halt status of
>>> its input, yet disagree that H is supposed to examine its input instead
>>> it must examine the behavior of the non-input P(P) ?
>>
>> The first argument in the call H(P, P) is P. The second argument is
>> also P. Thus H(P, P) is supposed to determine whether P(P) halts or
>> not. That is the "input" to H.
>
> No it is not the input to H.
>
> The behavior of directly executed P(P) is NOT the same behavior
> as when H(P,P) correctly simulates its input because the execution
> order of P(P) first is reversed when H(P,P) is invoked first.
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> When P calls H(P,P) this is essentially the first call of
> infinite recursion. When H(P,P) simulates its input this
> is essentially the second call of infinite recursion.

Maybe "essentially", but only in the sense of not quite. It WOULD be
infiite recursion if H(P,P) doesn't abort its simulation, but since it
does, it isn't.

Not because H aborted its simulation, but because it returns 0 to its
caller, which might be P(P), which makes P(P) Halting.

>
> H can see the infinite recursion specified by its input and
> aborts its simulation on that basis. As with all infinite
> recursion when any call is aborted the whole sequence stops.
> In this case when H(P,P) aborts its simulation it returns to
> its caller.

No, H THINKS it sees infinite recursion because it isn't smart enough to
see that the H that it sees being called WILL abort its simulation too
(if this one does) and thus breaks the recursion that it thinks it sees.

>
> The input to H(P,P) is infinitely recursive (as proven by the fact
> the the simulation never stops unless aborted) therefore H did
> correctly determine the halt status of this input.

Nope, your using the wrong definition. Once H(P,P) includes the
instructions to abort its simulation then because of the "pathological"
self-reference, the input it is simulating will do so also, just after
the point that H simulates.

>
> That is was supposed to determine the halt status of a non-input
> seems absurd and is rejected on the basis that software engineering
> won't allow it.
>
>

It isn't a non-input, it is EXACTLY what the input represents, and that
is what has behavior.

The input EXACTLY preresents P(P), or you are LYING about everything you
have been talking about.

Of course, it seems that most things you say are a lie, so that isn't new.

On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> > On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>
> >>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>> pay any attention to what I say.
> >>>>>
> >>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>
> >>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>
> >>>>>>> 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
> >>>>>>>
> >>>>>
> >>>>> Where I point out you're answering the wrong question.
> >>>>>
> >>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>
> >>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> int Halt_Status = H(x, x);
> >>>>>> if (Halt_Status)
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> P(P);
> >>>>>> }
> >>>>>>
> >>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>> is essentially the second call of infinite recursion.
> >>>>>>
> >>>>>> H can see the infinite recursion specified by its input and
> >>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>> its caller.
> >>>>>>
> >>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>> correctly determine the halt status of this input.
> >>>>>>
> >>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>> won't allow it.
> >>>>>
> >>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>
> >>>> You know that never said anything like that:
> >>>>
> >>>> Try and find a date-and-time stamped quote of me
> >>>> saying anything like that.
> >>>
> >>> That's precisely what the comment I've been quoting is saying:
> >>>
> >>> 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?
> >>>
> >>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>
> >>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >
> > No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> > of Hn it is essentially the same as a UTM.
> >
> >> A simulating halt decider is always correct to abort the simulation of
> >> any input that it correctly predicts would never otherwise never stop
> >> running.
> >
> > A simulating halt decider, like any 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
> >
> Yet in the case of H and P that would require a software function to
> return the result of analyzing a non-input which from a software
> engineering perspective is pure nonsense.

On 8/1/22 9:05 PM, olcott wrote:
> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if
>>>>>>>>>> the
>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it
>>>>>>>>>> doesn't if
>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt
>>>>>>>>> status of
>>>>>>>>> its input, yet disagree that H is supposed to examine its input
>>>>>>>>> instead
>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>
>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>> the remaining 1% are so laser focused on finding fault that they
>>>>>>> hardly
>>>>>>> pay any attention to what I say.
>>>>>>
>>>>>> But is seems you're reading comprehension is failing you again. I
>>>>>> know that when you say "H(P,P) does correctly determine the halt
>>>>>> status of its input", what you really mean is "there is no
>>>>>> implementation of the function H that can simulate the function
>>>>>> call P(P) to a final state". And that is true, and is what I was
>>>>>> agreeing about. That become more clear with what I said next:
>>>>>>
>>>>>>>> But that's apparently not the same as the halt status of the
>>>>>>>> machine the input represents, specifically Pa(Pa), as per the
>>>>>>>> definition of the function a halt decider is required to compute:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>> Where I point out you're answering the wrong question.
>>>>>>
>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that
>>>>>> follows from here down is bunk because it depends on the wrong
>>>>>> answer being right.
>>>>>>
>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>> int Halt_Status = H(x, x);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> P(P);
>>>>>>> }
>>>>>>>
>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>
>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>> its caller.
>>>>>>>
>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>> correctly determine the halt status of this input.
>>>>>>>
>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>> won't allow it.
>>>>>>
>>>>>> If determining the halt status of a non-input seems so absurd, why
>>>>>> do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>
>>>>> You know that never said anything like that:
>>>>>
>>>>> Try and find a date-and-time stamped quote of me
>>>>> saying anything like that.
>>>>
>>>> That's precisely what the comment I've been quoting is saying:
>>>>
>>>> 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?
>>>>
>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That
>>>> also means that Pa is no longer Pa since it's now calling Hn. It is
>>>> now Pn.
>>>>
>>>> So by postulating that Ha has different behavior, you change the
>>>> input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on
>>>> the behavior of Pn(Pn).
>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>
>> No, it was correct.  If Ha(Pa,Pa) predicts what its input will do if
>> its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of
>> Pn(Pn).  UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and
>> given the
>> of Hn it is essentially the same as a UTM.
>>
>>> A simulating halt decider is always correct to abort the simulation of
>>> any input that it correctly predicts would never otherwise never stop
>>> running.
>>
>> A simulating halt decider, like any 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
>>
>
> Yet in the case of H and P that would require a software function to
> return the result of analyzing a non-input which from a software
> engineering perspective is pure nonsense.

On 8/1/2022 8:06 PM, Richard Damon wrote:
> On 8/1/22 7:38 PM, olcott wrote:
>> On 8/1/2022 6:06 PM, Paul N wrote:
>>> On Monday, August 1, 2022 at 11:34:37 PM UTC+1, olcott wrote:
>>>> So then you agree the H(P,P) does correctly determine the halt
>>>> status of
>>>> its input, yet disagree that H is supposed to examine its input instead
>>>> it must examine the behavior of the non-input P(P) ?
>>>
>>> The first argument in the call H(P, P) is P. The second argument is
>>> also P. Thus H(P, P) is supposed to determine whether P(P) halts or
>>> not. That is the "input" to H.
>>
>> No it is not the input to H.
>>
>> The behavior of directly executed P(P) is NOT the same behavior
>> as when H(P,P) correctly simulates its input because the execution
>> order of P(P) first is reversed when H(P,P) is invoked first.
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    P(P);
>> }
>>
>> When P calls H(P,P) this is essentially the first call of
>> infinite recursion. When H(P,P) simulates its input this
>> is essentially the second call of infinite recursion.
>
> Maybe "essentially", but only in the sense of not quite. It WOULD be
> infiite recursion if H(P,P) doesn't abort its simulation, but since it
> does, it isn't.
>
> Not because H aborted its simulation, but because it returns 0 to its
> caller, which might be P(P), which makes P(P) Halting.
>
>>
>> H can see the infinite recursion specified by its input and
>> aborts its simulation on that basis. As with all infinite
>> recursion when any call is aborted the whole sequence stops.
>> In this case when H(P,P) aborts its simulation it returns to
>> its caller.
>
> No, H THINKS it sees infinite recursion because it isn't smart enough to
> see that the H that it sees being called WILL abort its simulation too
> (if this one does) and thus breaks the recursion that it thinks it sees.
>
>>
>> The input to H(P,P) is infinitely recursive (as proven by the fact
>> the the simulation never stops unless aborted) therefore H did
>> correctly determine the halt status of this input.
>
> Nope, your using the wrong definition. Once H(P,P) includes the
> instructions to abort its simulation then because of the "pathological"
> self-reference, the input it is simulating will do so also, just after
> the point that H simulates.
The correctly simulated input to H(P,P) cannot possibly reach is "ret"
instruction (final state) and halt even when its simulation is aborted.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

--
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:17 PM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>
>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>> pay any attention to what I say.
>>>>>>>
>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>
>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>
>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>
>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> P(P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>
>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>> its caller.
>>>>>>>>
>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>
>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>> won't allow it.
>>>>>>>
>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>
>>>>>> You know that never said anything like that:
>>>>>>
>>>>>> Try and find a date-and-time stamped quote of me
>>>>>> saying anything like that.
>>>>>
>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>
>>>>> 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?
>>>>>
>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>
>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>
>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>> of Hn it is essentially the same as a UTM.
>>>
>>>> A simulating halt decider is always correct to abort the simulation of
>>>> any input that it correctly predicts would never otherwise never stop
>>>> running.
>>>
>>> A simulating halt decider, like any 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
>>>
>> Yet in the case of H and P that would require a software function to
>> return the result of analyzing a non-input which from a software
>> engineering perspective is pure nonsense.
>
> You don't get to change the question.