typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

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

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

Key Fact (1) When H is a simulating halt decider that correctly
simulates its input with an x86 emulator, the simulation will never stop
running until H(P,P) aborts its emulation of its input:

(1) Executed H(P,P) simulates its input with an x86 emulator.
(2) Emulated P calls emulated H(P,P) to do this again.
(3) Emulated H(P,P) simulates its input with an x86 emulator.
(4) Emulated P calls emulated H(P,P) to do this again.
(5) Emulated H(P,P) simulates its input with an x86 emulator...

Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
by H cannot possibly reach its own "ret" instruction whether or not H
aborts its simulation.

All those not agreeing with the above Key Facts are either:
(a) Not interested in an honest dialogue or
(b) Have insufficient software engineering technical competence
Both will be ignored.

--
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 Sun, 31 Jul 2022 12:15:52 -0500
olcott <NoOne@NoWhere.com> wrote:

> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> Key Fact (1) When H is a simulating halt decider that correctly
> simulates its input with an x86 emulator, the simulation will never
> stop running until H(P,P) aborts its emulation of its input:
>
> (1) Executed H(P,P) simulates its input with an x86 emulator.
> (2) Emulated P calls emulated H(P,P) to do this again.
> (3) Emulated H(P,P) simulates its input with an x86 emulator.
> (4) Emulated P calls emulated H(P,P) to do this again.
> (5) Emulated H(P,P) simulates its input with an x86 emulator...
>
> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> simulated by H cannot possibly reach its own "ret" instruction
> whether or not H aborts its simulation.
>
> All those not agreeing with the above Key Facts are either:
> (a) Not interested in an honest dialogue or
> (b) Have insufficient software engineering technical competence
> Both will be ignored.

You keep making the same mistake: [Strachey 1965] and associated HP
proofs are not recursive in nature. A simulating halt decider need not
be recursive in nature and I have indeed designed such a decider:

https://github.com/i42output/halting-problem#readme

/Flibble

On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
>
> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
> by H cannot possibly reach its own "ret" instruction whether or not H
> aborts its simulation.
>
> All those not agreeing with the above Key Facts are either:
> (a) Not interested in an honest dialogue or
> (b) Have insufficient software engineering technical competence
> Both will be ignored.

Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.

By the definition of what a halt decider is required to do:

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

Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.

It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.

Ha(Pa,Pa)

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.

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.

If H aborts its simulation, then a correct and complete simulation of
the input will reach the return instruction.

Yes, a correct BUT PARTIAL simulation might not reach the return
instruction, but a PARTIAL simulation, by itself, never proves
non-halting. (It might provide information that can be used to prove
non-hatling, b

Note, H can't do that, because if H aborts its simulation, it does not
do a COMPLETE and correct simulation.

>
> All those not agreeing with the above Key Facts are either:
> (a) Not interested in an honest dialogue or
> (b) Have insufficient software engineering technical competence
> Both will be ignored.
>

Nope, just shows that YOU don't understand what you are saying and that
YOU have insufficient technical competence.

Note, anyone saying they won't talk to people who disagree with them and
their "facts", even though those people are showing WHY those "facts"
are incorrect, is just showing that they are totally ignorant and want
to stay that way.

You are just sealing your reputation as a totally ignorant person with
no grasp of what is real. You seem to have successfully gaslite yourself
into beleiving your own lies and are unable to see your errors.

On 7/31/2022 12:41 PM, Dennis Bush wrote:
> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
>>
>> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
>> by H cannot possibly reach its own "ret" instruction whether or not H
>> aborts its simulation.
>>
>> All those not agreeing with the above Key Facts are either:
>> (a) Not interested in an honest dialogue or
>> (b) Have insufficient software engineering technical competence
>> Both will be ignored.
>
> Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.
>
> By the definition of what a halt decider is required to do:
>
> 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
>
> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
>
> It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.
>
>
> Ha(Pa,Pa)

So in other words you are asserting that the correctly simulated input
to H(P,P) correctly simulated by H would stop running without H ever
aborting this simulation.

I would say that this would put you in the insufficient software
engineering technical competence category.

--
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/22 1:54 PM, olcott wrote:
> On 7/31/2022 12:41 PM, Dennis Bush wrote:
>> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
>>>
>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
>>> by H cannot possibly reach its own "ret" instruction whether or not H
>>> aborts its simulation.
>>>
>>> All those not agreeing with the above Key Facts are either:
>>> (a) Not interested in an honest dialogue or
>>> (b) Have insufficient software engineering technical competence
>>> Both will be ignored.
>>
>> Since the fixed algorithm of H aborts its simulation, we'll call it
>> Ha.  Since P calls this fixed Ha, we'll call it Pa.
>>
>> By the definition of what a halt decider is required to do:
>>
>> 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
>>
>> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
>>
>> It doesn't matter how Ha gets this wrong answer.  It only matters that
>> Ha(Pa,Pa)==0 is wrong by definition.
>>
>>
>> Ha(Pa,Pa)
>
> So in other words you are asserting that the correctly simulated input
> to H(P,P) correctly simulated by H would stop running without H ever
> aborting this simulation.

If H is defined to NEVER stop until it can CORRECTLY abort its
simulation, then it will never abort its simulation of P(P), and thus
never return the "correct" answer of 0.

So, you are right, that given THAT defininition of H (which doesn't
match the code you have posted) it is true that the correct and complete
simulation of the input to H(P,P) will never reach the return
instruction, because this H is the Hn that has been previously
described. Note, This H will never return an answer for H(P,P) because
there IS NO correct finite pattern for H to detect to stop its
simulation to return 0.

>
> I would say that this would put you in the insufficient software
> engineering technical competence category.
>

Nope, YOU have the insufficient software engineering technical
competence to know that you need to analyize the program before you and
not an idealized version that behaves differently.

On Sunday, July 31, 2022 at 1:54:23 PM UTC-4, olcott wrote:
> On 7/31/2022 12:41 PM, Dennis Bush wrote:
> > On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
> >>
> >> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
> >> by H cannot possibly reach its own "ret" instruction whether or not H
> >> aborts its simulation.
> >>
> >> All those not agreeing with the above Key Facts are either:
> >> (a) Not interested in an honest dialogue or
> >> (b) Have insufficient software engineering technical competence
> >> Both will be ignored.
> >
> > Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.
> >
> > By the definition of what a halt decider is required to do:
> >
> > 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
> >
> > Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
> >
> > It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.
> >
> >
> > Ha(Pa,Pa)
> So in other words you are asserting that the correctly simulated input
> to H(P,P) correctly simulated by H would stop running without H ever
> aborting this simulation.

I am saying that Ha correctly decides that there is no implementation of the function H that can simulate the function P(P) to a final state. And that is not the question that the halting problem is asking.

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

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.

>
> Yes, a correct BUT PARTIAL simulation might not reach the return
> instruction, but a PARTIAL simulation, by itself, never proves
> non-halting. (It might provide information that can be used to prove
> non-hatling, b
>
> Note, H can't do that, because if H aborts its simulation, it does not
> do a COMPLETE and correct simulation.
>
>>
>> All those not agreeing with the above Key Facts are either:
>> (a) Not interested in an honest dialogue or
>> (b) Have insufficient software engineering technical competence
>> Both will be ignored.
>>
>
> Nope, just shows that YOU don't understand what you are saying and that
> YOU have insufficient technical competence.
>
> Note, anyone saying they won't talk to people who disagree with them and
> their "facts", even though those people are showing WHY those "facts"
> are incorrect, is just showing that they are totally ignorant and want
> to stay that way.
>
> You are just sealing your reputation as a totally ignorant person with
> no grasp of what is real. You seem to have successfully gaslite yourself
> into beleiving your own lies and are unable to see your errors.

--
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 1:04 PM, Dennis Bush wrote:
> On Sunday, July 31, 2022 at 1:54:23 PM UTC-4, olcott wrote:
>> On 7/31/2022 12:41 PM, Dennis Bush wrote:
>>> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
>>>>
>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
>>>> by H cannot possibly reach its own "ret" instruction whether or not H
>>>> aborts its simulation.
>>>>
>>>> All those not agreeing with the above Key Facts are either:
>>>> (a) Not interested in an honest dialogue or
>>>> (b) Have insufficient software engineering technical competence
>>>> Both will be ignored.
>>>
>>> Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.
>>>
>>> By the definition of what a halt decider is required to do:
>>>
>>> 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
>>>
>>> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
>>>
>>> It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.
>>>
>>>
>>> Ha(Pa,Pa)
>> So in other words you are asserting that the correctly simulated input
>> to H(P,P) correctly simulated by H would stop running without H ever
>> aborting this simulation.
>
> I am saying that Ha correctly decides that there is no implementation of the function H that can simulate the function P(P) to a final state.

Likewise with every other non-halting input such as Infinite_Loop() and
Infinite_Recursion().

void Infinite_Loop()
{ HERE: goto HERE;
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

void Infinite_Recursion(int N)
{ Infinite_Recursion(N);
}

_Infinite_Recursion()
[000010f2](01) 55 push ebp
[000010f3](02) 8bec mov ebp,esp
[000010f5](03) 8b4508 mov eax,[ebp+08]
[000010f8](01) 50 push eax
[000010f9](05) e8f4ffffff call 000010f2
[000010fe](03) 83c404 add esp,+04
[00001101](01) 5d pop ebp
[00001102](01) c3 ret
Size in bytes:(0017) [00001102]

> And that is not the question that the halting problem is asking.
>
> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.

*THIS IS A YES OR NO QUESTION*
So in other words you are asserting that the correctly simulated input
to H(P,P) correctly simulated by H would stop running without H ever
aborting this simulation.

I no that answering YES makes you look utterly foolish and answering NO
has you agreeing with me and you really really hate to do that.
Continuing to dodge this question reaffirms your dishonesty.

--
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 1:26 PM, olcott wrote:
> On 7/31/2022 1:04 PM, Dennis Bush wrote:
>> On Sunday, July 31, 2022 at 1:54:23 PM UTC-4, olcott wrote:
>>> On 7/31/2022 12:41 PM, Dennis Bush wrote:
>>>> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
>>>>>
>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>> simulated
>>>>> by H cannot possibly reach its own "ret" instruction whether or not H
>>>>> aborts its simulation.
>>>>>
>>>>> All those not agreeing with the above Key Facts are either:
>>>>> (a) Not interested in an honest dialogue or
>>>>> (b) Have insufficient software engineering technical competence
>>>>> Both will be ignored.
>>>>
>>>> Since the fixed algorithm of H aborts its simulation, we'll call it
>>>> Ha. Since P calls this fixed Ha, we'll call it Pa.
>>>>
>>>> By the definition of what a halt decider is required to do:
>>>>
>>>> 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
>>>>
>>>> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
>>>>
>>>> It doesn't matter how Ha gets this wrong answer. It only matters
>>>> that Ha(Pa,Pa)==0 is wrong by definition.
>>>>
>>>>
>>>> Ha(Pa,Pa)
>>> So in other words you are asserting that the correctly simulated input
>>> to H(P,P) correctly simulated by H would stop running without H ever
>>> aborting this simulation.
>>
>> I am saying that Ha correctly decides that there is no implementation
>> of the function H that can simulate the function P(P) to a final state.
>
> Likewise with every other non-halting input such as Infinite_Loop() and
> Infinite_Recursion().
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
> void Infinite_Recursion(int N)
> {
>   Infinite_Recursion(N);
> }
>
> _Infinite_Recursion()
> [000010f2](01)  55         push ebp
> [000010f3](02)  8bec       mov ebp,esp
> [000010f5](03)  8b4508     mov eax,[ebp+08]
> [000010f8](01)  50         push eax
> [000010f9](05)  e8f4ffffff call 000010f2
> [000010fe](03)  83c404     add esp,+04
> [00001101](01)  5d         pop ebp
> [00001102](01)  c3         ret
> Size in bytes:(0017) [00001102]
>
>> And that is not the question that the halting problem is asking.
>>
>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>
> *THIS IS A YES OR NO QUESTION*
> So in other words you are asserting that the correctly simulated input
> to H(P,P) correctly simulated by H would stop running without H ever
> aborting this simulation.
>
typo corrected
> I [no] know that answering YES makes you look utterly foolish and answering NO
> has you agreeing with me and you really really hate to do that.
> Continuing to dodge this question reaffirms your dishonesty.
>

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

You somehow don't seem to understand the difference between a PARTIAL
simulation cause by the simulator aborting its operation, and a COMPLETE
simulation.

Since Halting is defined by the behavior of the ACTUAL MACHINE, (or
equivalently by the correct AND COMPLETE simulation), this is the
behaivior a true Halting Decider must be answering about.

I have agreed that *H* can't get there, but that just proves that H
can't prove the input Halts. Only an IDIOT thinks that hypothetical
machines that aren't part of the problem tell us more about the machine
we are looking at the the actual machine.

H(P,P) is being asked about P(P). (your definition of P proves this).

Halt deciders must ACCEPT (return 0) it the machine being asked about
will halt.

P(P) Halts if H(P,P) returns 0.

Therefore, H(P,P) returning 0 is INCORRECT, as its input represents P(P)
(or you are just being a LIAR) and that halts, so H(P,P) must have
accepted this input to have been correct.

>
>>
>> Yes, a correct BUT PARTIAL simulation might not reach the return
>> instruction, but a PARTIAL simulation, by itself, never proves
>> non-halting. (It might provide information that can be used to prove
>> non-hatling, b
>>
>> Note, H can't do that, because if H aborts its simulation, it does not
>> do a COMPLETE and correct simulation.
>>
>>>
>>> All those not agreeing with the above Key Facts are either:
>>> (a) Not interested in an honest dialogue or
>>> (b) Have insufficient software engineering technical competence
>>> Both will be ignored.
>>>
>>
>> Nope, just shows that YOU don't understand what you are saying and
>> that YOU have insufficient technical competence.
>>
>> Note, anyone saying they won't talk to people who disagree with them
>> and their "facts", even though those people are showing WHY those
>> "facts" are incorrect, is just showing that they are totally ignorant
>> and want to stay that way.
>>
>> You are just sealing your reputation as a totally ignorant person with
>> no grasp of what is real. You seem to have successfully gaslite
>> yourself into beleiving your own lies and are unable to see your errors.
>
>

On Sunday, July 31, 2022 at 2:26:29 PM UTC-4, olcott wrote:
> On 7/31/2022 1:04 PM, Dennis Bush wrote:
> > On Sunday, July 31, 2022 at 1:54:23 PM UTC-4, olcott wrote:
> >> On 7/31/2022 12:41 PM, Dennis Bush wrote:
> >>> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
> >>>>
> >>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
> >>>> by H cannot possibly reach its own "ret" instruction whether or not H
> >>>> aborts its simulation.
> >>>>
> >>>> All those not agreeing with the above Key Facts are either:
> >>>> (a) Not interested in an honest dialogue or
> >>>> (b) Have insufficient software engineering technical competence
> >>>> Both will be ignored.
> >>>
> >>> Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.
> >>>
> >>> By the definition of what a halt decider is required to do:
> >>>
> >>> 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
> >>>
> >>> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
> >>>
> >>> It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.
> >>>
> >>>
> >>> Ha(Pa,Pa)
> >> So in other words you are asserting that the correctly simulated input
> >> to H(P,P) correctly simulated by H would stop running without H ever
> >> aborting this simulation.
> >
> > I am saying that Ha correctly decides that there is no implementation of the function H that can simulate the function P(P) to a final state.
> Likewise with every other non-halting input such as Infinite_Loop() and
> Infinite_Recursion().
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> _Infinite_Loop()
> [00001102](01) 55 push ebp
> [00001103](02) 8bec mov ebp,esp
> [00001105](02) ebfe jmp 00001105
> [00001107](01) 5d pop ebp
> [00001108](01) c3 ret
> Size in bytes:(0007) [00001108]
>
> void Infinite_Recursion(int N)
> {
> Infinite_Recursion(N);
> }
>
> _Infinite_Recursion()
> [000010f2](01) 55 push ebp
> [000010f3](02) 8bec mov ebp,esp
> [000010f5](03) 8b4508 mov eax,[ebp+08]
> [000010f8](01) 50 push eax
> [000010f9](05) e8f4ffffff call 000010f2
> [000010fe](03) 83c404 add esp,+04
> [00001101](01) 5d pop ebp
> [00001102](01) c3 ret
> Size in bytes:(0017) [00001102]
> > And that is not the question that the halting problem is asking.
> >
> > Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> *THIS IS A YES OR NO QUESTION*
> So in other words you are asserting that the correctly simulated input
> to H(P,P) correctly simulated by H would stop running without H ever
> aborting this simulation.

I see you're now talking about an H that doesn't abort, so that means H is now Hn and P is now Pn. So lets restate the above to be clear about what you mean:

> So in other words you are asserting that the correctly simulated input
> to Hn(Pn,Pn) correctly simulated by Hn would stop running without Hn ever
> aborting this simulation.

No, it would not stop running because Hn doesn't abort. And because Hn doesn't abort, it can't answer that Pn(Pn) halts and is wrong by virtue of not answering.

On 7/31/22 2:26 PM, olcott wrote:
> On 7/31/2022 1:04 PM, Dennis Bush wrote:
>> On Sunday, July 31, 2022 at 1:54:23 PM UTC-4, olcott wrote:
>>> On 7/31/2022 12:41 PM, Dennis Bush wrote:
>>>> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
>>>>>
>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>> simulated
>>>>> by H cannot possibly reach its own "ret" instruction whether or not H
>>>>> aborts its simulation.
>>>>>
>>>>> All those not agreeing with the above Key Facts are either:
>>>>> (a) Not interested in an honest dialogue or
>>>>> (b) Have insufficient software engineering technical competence
>>>>> Both will be ignored.
>>>>
>>>> Since the fixed algorithm of H aborts its simulation, we'll call it
>>>> Ha. Since P calls this fixed Ha, we'll call it Pa.
>>>>
>>>> By the definition of what a halt decider is required to do:
>>>>
>>>> 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
>>>>
>>>> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
>>>>
>>>> It doesn't matter how Ha gets this wrong answer. It only matters
>>>> that Ha(Pa,Pa)==0 is wrong by definition.
>>>>
>>>>
>>>> Ha(Pa,Pa)
>>> So in other words you are asserting that the correctly simulated input
>>> to H(P,P) correctly simulated by H would stop running without H ever
>>> aborting this simulation.
>>
>> I am saying that Ha correctly decides that there is no implementation
>> of the function H that can simulate the function P(P) to a final state.
>
> Likewise with every other non-halting input such as Infinite_Loop() and
> Infinite_Recursion().
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
> void Infinite_Recursion(int N)
> {
>   Infinite_Recursion(N);
> }
>
> _Infinite_Recursion()
> [000010f2](01)  55         push ebp
> [000010f3](02)  8bec       mov ebp,esp
> [000010f5](03)  8b4508     mov eax,[ebp+08]
> [000010f8](01)  50         push eax
> [000010f9](05)  e8f4ffffff call 000010f2
> [000010fe](03)  83c404     add esp,+04
> [00001101](01)  5d         pop ebp
> [00001102](01)  c3         ret
> Size in bytes:(0017) [00001102]
>
>> And that is not the question that the halting problem is asking.
>>
>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>
> *THIS IS A YES OR NO QUESTION*
> So in other words you are asserting that the correctly simulated input
> to H(P,P) correctly simulated by H would stop running without H ever
> aborting this simulation.

And, since H is claimed to be a Halt Decider, that question is
irrelevent and a Red Herring and a Strawman

>
> I no that answering YES makes you look utterly foolish and answering NO
> has you agreeing with me and you really really hate to do that.
> Continuing to dodge this question reaffirms your dishonesty.
>

Your insistance on getting answers to irrelevent question just proves
that you arent intereseted in the actual truth.

NO ONE has said that *H* can simulate the input to the return
instruction, and you instance in implying that people are saying that
just shows your lack of Honesty.

People don't disagree that H can't simulate to the return instruction,
just that this implies your conclusion. That you don't get this
distinction shows your (lack of) intelegence.

BTW, simple question, Will you stop lying on Usenet?
Answer Yes or No, or you are just using a dishonest dodge.

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?

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Sunday, July 31, 2022 at 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.

On 7/31/2022 1:35 PM, Dennis Bush wrote:
> On Sunday, July 31, 2022 at 2:26:29 PM UTC-4, olcott wrote:
>> On 7/31/2022 1:04 PM, Dennis Bush wrote:
>>> On Sunday, July 31, 2022 at 1:54:23 PM UTC-4, olcott wrote:
>>>> On 7/31/2022 12:41 PM, Dennis Bush wrote:
>>>>> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
>>>>>>
>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
>>>>>> by H cannot possibly reach its own "ret" instruction whether or not H
>>>>>> aborts its simulation.
>>>>>>
>>>>>> All those not agreeing with the above Key Facts are either:
>>>>>> (a) Not interested in an honest dialogue or
>>>>>> (b) Have insufficient software engineering technical competence
>>>>>> Both will be ignored.
>>>>>
>>>>> Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.
>>>>>
>>>>> By the definition of what a halt decider is required to do:
>>>>>
>>>>> 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
>>>>>
>>>>> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
>>>>>
>>>>> It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.
>>>>>
>>>>>
>>>>> Ha(Pa,Pa)
>>>> So in other words you are asserting that the correctly simulated input
>>>> to H(P,P) correctly simulated by H would stop running without H ever
>>>> aborting this simulation.
>>>
>>> I am saying that Ha correctly decides that there is no implementation of the function H that can simulate the function P(P) to a final state.
>> Likewise with every other non-halting input such as Infinite_Loop() and
>> Infinite_Recursion().
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> _Infinite_Loop()
>> [00001102](01) 55 push ebp
>> [00001103](02) 8bec mov ebp,esp
>> [00001105](02) ebfe jmp 00001105
>> [00001107](01) 5d pop ebp
>> [00001108](01) c3 ret
>> Size in bytes:(0007) [00001108]
>>
>> void Infinite_Recursion(int N)
>> {
>> Infinite_Recursion(N);
>> }
>>
>> _Infinite_Recursion()
>> [000010f2](01) 55 push ebp
>> [000010f3](02) 8bec mov ebp,esp
>> [000010f5](03) 8b4508 mov eax,[ebp+08]
>> [000010f8](01) 50 push eax
>> [000010f9](05) e8f4ffffff call 000010f2
>> [000010fe](03) 83c404 add esp,+04
>> [00001101](01) 5d pop ebp
>> [00001102](01) c3 ret
>> Size in bytes:(0017) [00001102]
>>> And that is not the question that the halting problem is asking.
>>>
>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>> *THIS IS A YES OR NO QUESTION*
>> So in other words you are asserting that the correctly simulated input
>> to H(P,P) correctly simulated by H would stop running without H ever
>> aborting this simulation.
>
> I see you're now talking about an H that doesn't abort, so that means H is now Hn and P is now Pn. So lets restate the above to be clear about what you mean:
>
>> So in other words you are asserting that the correctly simulated input
>> to Hn(Pn,Pn) correctly simulated by Hn would stop running without Hn ever
>> aborting this simulation.
>
> No, it would not stop running because Hn doesn't abort. And because Hn doesn't abort, it can't answer that Pn(Pn) halts and is wrong by virtue of not answering.

OK great we are finally on the same page on one key point.

void Infinite_Loop()
{ HERE: goto HERE;
}

void Infinite_Recursion(int N)
{ Infinite_Recursion(N);
}

Do you understand that every input (*such as the above two examples*) to
a simulating halt decider that would never stop running unless and until
this SHD aborts its simulation is an input that specifies non-halting
behavior?

If NO, then do you understand that it does apply to the above two examples?

--
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/22 2:39 PM, olcott wrote:
> On 7/31/2022 1:30 PM, Richard Damon wrote:
>> On 7/31/22 2:11 PM, olcott wrote:
>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>> typedef void (*ptr)();
>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>> simulates its input with an x86 emulator, the simulation will never
>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>
>>>>> (1) Executed H(P,P)  simulates its   input with an x86 emulator.
>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>> (3) Emulated H(P,P)  simulates its   input with an x86 emulator.
>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>> (5) Emulated H(P,P)  simulates its   input with an x86 emulator...
>>>>
>>>> This is what happens if H doesn't abort its simulation. If H ever
>>>> does abort its simulation, this is NOT what happens.
>>>
>>> Good, I agree.
>>>
>>>>
>>>> Note, an H that simulates until it can CORRECTLY determine that its
>>>> input is non-halting, will match this pattern, because it will NEVER
>>>> in finite time be able to actually correctly prove the input is
>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>> non-halting, if it is seen by H in the simulation, and H stops its
>>>> simulation and returns 0, causes the actual program P(P) to Halt.
>>>>
>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>> actually a Halt Decider, that proves that H is incorrect to return 0
>>>> from H(P,P) to say that P(P) is non-halting, since it is Halting.
>>>>
>>>> If you want to repeat you LIE that the input to H(P,P) generate a
>>>> different sequence of configurations that P(P), please provide the
>>>> FIRST configuration in the sequence that is different, and is
>>>> actually the result of a CORRECT simulation of the input.
>>>>
>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is "proof"
>>>> that its input is non-halting is proved incorrect and invalid, and
>>>> your "proof" of this is based on assuming it, and thus falls into
>>>> the fallacy of the assumption of the conclusion.
>>>>
>>>>>
>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>> whether or not H aborts its simulation.
>>>>
>>>> No, that is only true if H doesn't abort its simuation.
>>>
>>> So you believe that when H aborts its simulation this causes the
>>> simulated P to reach its "ret" instruction even after it has been
>>> aborted before reaching this instruction?
>>>
>>> Unless you reverse your position technically competent reviewers will
>>> understand that you are not a sufficiently technically competent
>>> reviewer.
>>>
>>>>
>>>> If H aborts its simulation, then a correct and complete simulation
>>>> of the input will reach the return instruction.
>>>
>>> If H aborts its simulation of P then the simulated P that is no
>>> longer running will continue several more execution steps and reach
>>> its "ret" instruction even though it has been forced to stop running
>>> before ever reaching the "ret" instruction.
>>
>> No, it causes the ACTUAL P, and the correct and COMPLETE simulation of
>> the input to H(P,P) to reach the return instruction.
> There is only a simulated P in the following:

Right, but that doesn;t mean the PROGRAM P(P) doesn't actually have the
ability to exist.

we just need to change main() to

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

To make it come into existance.

If this isn't allowed, you system isn't Turing complete and you
"universe" you are defining worthless to talk about the Halting Problem.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> So you agree that the input to H(P,P) that is correctly simulated by H
> cannot possibly reach the "ret" instruction of this simulated P whether
> or not H aborts its simulation or not?
>

Yes, "BY H".

But that DOESN'T prove the the input represents a non-halting input,
since P(P) IS the machine represented by the input, and P(P) Halts if
H(P,P) returns 0

If you repeat you claim that the input to H(P,P) does NOT represent P(P)
then you need to explain why you are LYING that P is built by the
requrements of the proof you are claiming to counterdict when it
specifically is calling H(P,P) to ask it about the compuation P(P).

I have NO Problems with you claiming H is a correct POOP decider, if
POOP is based on the simulation as done by H instead of the actual
definiton of Halting which is based on the behavior of the machine the
input represents. That just isn't an interesting claim.

So, will you stop lying on Usenet? (Yes or No)

On Sun, 31 Jul 2022 11:43:49 -0700 (PDT)
Dennis Bush <dbush.mobile@gmail.com> 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.

You are wrong to agree with Olcott on that point as a simulating halt
decider needn't be recursive in nature, as I have shown:

https://github.com/i42output/halting-problem#readme

/Flibble

On Sunday, July 31, 2022 at 2:48:58 PM UTC-4, olcott wrote:
> On 7/31/2022 1:35 PM, Dennis Bush wrote:
> > On Sunday, July 31, 2022 at 2:26:29 PM UTC-4, olcott wrote:
> >> On 7/31/2022 1:04 PM, Dennis Bush wrote:
> >>> On Sunday, July 31, 2022 at 1:54:23 PM UTC-4, olcott wrote:
> >>>> On 7/31/2022 12:41 PM, Dennis Bush wrote:
> >>>>> On Sunday, July 31, 2022 at 1:16:00 PM UTC-4, 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...
> >>>>>>
> >>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly simulated
> >>>>>> by H cannot possibly reach its own "ret" instruction whether or not H
> >>>>>> aborts its simulation.
> >>>>>>
> >>>>>> All those not agreeing with the above Key Facts are either:
> >>>>>> (a) Not interested in an honest dialogue or
> >>>>>> (b) Have insufficient software engineering technical competence
> >>>>>> Both will be ignored.
> >>>>>
> >>>>> Since the fixed algorithm of H aborts its simulation, we'll call it Ha. Since P calls this fixed Ha, we'll call it Pa.
> >>>>>
> >>>>> By the definition of what a halt decider is required to do:
> >>>>>
> >>>>> 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
> >>>>>
> >>>>> Ha(Pa,Pa)==0 in incorrect because Pa(Pa) halts.
> >>>>>
> >>>>> It doesn't matter how Ha gets this wrong answer. It only matters that Ha(Pa,Pa)==0 is wrong by definition.
> >>>>>
> >>>>>
> >>>>> Ha(Pa,Pa)
> >>>> So in other words you are asserting that the correctly simulated input
> >>>> to H(P,P) correctly simulated by H would stop running without H ever
> >>>> aborting this simulation.
> >>>
> >>> I am saying that Ha correctly decides that there is no implementation of the function H that can simulate the function P(P) to a final state.
> >> Likewise with every other non-halting input such as Infinite_Loop() and
> >> Infinite_Recursion().
> >>
> >> void Infinite_Loop()
> >> {
> >> HERE: goto HERE;
> >> }
> >>
> >> _Infinite_Loop()
> >> [00001102](01) 55 push ebp
> >> [00001103](02) 8bec mov ebp,esp
> >> [00001105](02) ebfe jmp 00001105
> >> [00001107](01) 5d pop ebp
> >> [00001108](01) c3 ret
> >> Size in bytes:(0007) [00001108]
> >>
> >> void Infinite_Recursion(int N)
> >> {
> >> Infinite_Recursion(N);
> >> }
> >>
> >> _Infinite_Recursion()
> >> [000010f2](01) 55 push ebp
> >> [000010f3](02) 8bec mov ebp,esp
> >> [000010f5](03) 8b4508 mov eax,[ebp+08]
> >> [000010f8](01) 50 push eax
> >> [000010f9](05) e8f4ffffff call 000010f2
> >> [000010fe](03) 83c404 add esp,+04
> >> [00001101](01) 5d pop ebp
> >> [00001102](01) c3 ret
> >> Size in bytes:(0017) [00001102]
> >>> And that is not the question that the halting problem is asking.
> >>>
> >>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >> *THIS IS A YES OR NO QUESTION*
> >> So in other words you are asserting that the correctly simulated input
> >> to H(P,P) correctly simulated by H would stop running without H ever
> >> aborting this simulation.
> >
> > I see you're now talking about an H that doesn't abort, so that means H is now Hn and P is now Pn. So lets restate the above to be clear about what you mean:
> >
> >> So in other words you are asserting that the correctly simulated input
> >> to Hn(Pn,Pn) correctly simulated by Hn would stop running without Hn ever
> >> aborting this simulation.
> >
> > No, it would not stop running because Hn doesn't abort. And because Hn doesn't abort, it can't answer that Pn(Pn) halts and is wrong by virtue of not answering.
> OK great we are finally on the same page on one key point.

There was never disagreement on this.

> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
> void Infinite_Recursion(int N)
> {
> Infinite_Recursion(N);
> }
>
> Do you understand that every input (*such as the above two examples*) to
> a simulating halt decider that would never stop running unless and until
> this SHD aborts its simulation is an input that specifies non-halting
> behavior?

Whether the function H can simulate a particular function call to a final state is unrelated to whether a computations halts, which is what the halting problem is about.

Ha(Infinite_Loop)==0 is correct because Infinite_Loop() does not halt
Ha(Infinite_Recursion,N)==0 is correct because Infinite_Recursion(N) does not halt
Ha(Pa,Pa)==0 is not correct because Pa(Pa) halts.

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.

--
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/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, and some "partial simulation done
by H + some questionable logic".

I.E. the actual behavior of the input of H(P,P) is determined by P(P),
since that IS what the input is, not by the partial simulation done by H
and it incorrect logic that simulating the input of H(P,P) to a call to
H(P,P) means the input has infinite recursion.

You STILL haven't even attempted to answer the challange to show the
first point where the correct behavior of the simulation of the innput
to H(P,P) differs from the actual execution of P(P).

You point to the call of H(P,P) inside it, but the CORRECT simulation of
that call goes into H, just as the direct execution does (even if your
system doesn't show that as part of the trace). Saying the call does
something other than what the call actually does just shows that H is
INCORRECT about what its input does.

On 7/31/2022 1:59 PM, Richard Damon wrote:
>
> On 7/31/22 2:39 PM, olcott wrote:
>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>> On 7/31/22 2:11 PM, olcott wrote:
>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>> typedef void (*ptr)();
>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    int Halt_Status = H(x, x);
>>>>>>    if (Halt_Status)
>>>>>>      HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>> simulates its input with an x86 emulator, the simulation will
>>>>>> never stop running until H(P,P) aborts its emulation of its input:
>>>>>>
>>>>>> (1) Executed H(P,P)  simulates its   input with an x86 emulator.
>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>> (3) Emulated H(P,P)  simulates its   input with an x86 emulator.
>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>> (5) Emulated H(P,P)  simulates its   input with an x86 emulator...
>>>>>
>>>>> This is what happens if H doesn't abort its simulation. If H ever
>>>>> does abort its simulation, this is NOT what happens.
>>>>
>>>> Good, I agree.
>>>>
>>>>>
>>>>> Note, an H that simulates until it can CORRECTLY determine that its
>>>>> input is non-halting, will match this pattern, because it will
>>>>> NEVER in finite time be able to actually correctly prove the input
>>>>> is non-halting, as ANY pattern that is defined (incorrectly) as
>>>>> non-halting, if it is seen by H in the simulation, and H stops its
>>>>> simulation and returns 0, causes the actual program P(P) to Halt.
>>>>>
>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>> actually a Halt Decider, that proves that H is incorrect to return
>>>>> 0 from H(P,P) to say that P(P) is non-halting, since it is Halting.
>>>>>
>>>>> If you want to repeat you LIE that the input to H(P,P) generate a
>>>>> different sequence of configurations that P(P), please provide the
>>>>> FIRST configuration in the sequence that is different, and is
>>>>> actually the result of a CORRECT simulation of the input.
>>>>>
>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>> "proof" that its input is non-halting is proved incorrect and
>>>>> invalid, and your "proof" of this is based on assuming it, and thus
>>>>> falls into the fallacy of the assumption of the conclusion.
>>>>>
>>>>>>
>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>> whether or not H aborts its simulation.
>>>>>
>>>>> No, that is only true if H doesn't abort its simuation.
>>>>
>>>> So you believe that when H aborts its simulation this causes the
>>>> simulated P to reach its "ret" instruction even after it has been
>>>> aborted before reaching this instruction?
>>>>
>>>> Unless you reverse your position technically competent reviewers
>>>> will understand that you are not a sufficiently technically
>>>> competent reviewer.
>>>>
>>>>>
>>>>> If H aborts its simulation, then a correct and complete simulation
>>>>> of the input will reach the return instruction.
>>>>
>>>> If H aborts its simulation of P then the simulated P that is no
>>>> longer running will continue several more execution steps and reach
>>>> its "ret" instruction even though it has been forced to stop running
>>>> before ever reaching the "ret" instruction.
>>>
>>> No, it causes the ACTUAL P, and the correct and COMPLETE simulation
>>> of the input to H(P,P) to reach the return instruction.
>> There is only a simulated P in the following:
>
> Right, but that doesn;t mean the PROGRAM P(P) doesn't actually have the
> ability to exist.
>
> we just need to change main() to
>
> int main() {
>     Output("Input_Halts = ", H(P,P));
>     P(P);
>     Output("P(P) Halted");
> }
>
> To make it come into existance.
>
> If this isn't allowed, you system isn't Turing complete and you
> "universe" you are defining worthless to talk about the Halting Problem.
>
>>
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>> So you agree that the input to H(P,P) that is correctly simulated by H
>> cannot possibly reach the "ret" instruction of this simulated P
>> whether or not H aborts its simulation or not?
>>
>
> Yes, "BY H".
>
> But that DOESN'T prove the the input represents a non-halting input,
Within these halt deciding principles it does:

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

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

--
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/22 9:13 PM, olcott wrote:
> On 7/31/2022 1:59 PM, Richard Damon wrote:
>>
>> On 7/31/22 2:39 PM, olcott wrote:
>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>> typedef void (*ptr)();
>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>> simulates its input with an x86 emulator, the simulation will
>>>>>>> never stop running until H(P,P) aborts its emulation of its input:
>>>>>>>
>>>>>>> (1) Executed H(P,P)  simulates its   input with an x86 emulator.
>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>> (3) Emulated H(P,P)  simulates its   input with an x86 emulator.
>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>> (5) Emulated H(P,P)  simulates its   input with an x86 emulator...
>>>>>>
>>>>>> This is what happens if H doesn't abort its simulation. If H ever
>>>>>> does abort its simulation, this is NOT what happens.
>>>>>
>>>>> Good, I agree.
>>>>>
>>>>>>
>>>>>> Note, an H that simulates until it can CORRECTLY determine that
>>>>>> its input is non-halting, will match this pattern, because it will
>>>>>> NEVER in finite time be able to actually correctly prove the input
>>>>>> is non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>> non-halting, if it is seen by H in the simulation, and H stops its
>>>>>> simulation and returns 0, causes the actual program P(P) to Halt.
>>>>>>
>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>> actually a Halt Decider, that proves that H is incorrect to return
>>>>>> 0 from H(P,P) to say that P(P) is non-halting, since it is Halting.
>>>>>>
>>>>>> If you want to repeat you LIE that the input to H(P,P) generate a
>>>>>> different sequence of configurations that P(P), please provide the
>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>
>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>> "proof" that its input is non-halting is proved incorrect and
>>>>>> invalid, and your "proof" of this is based on assuming it, and
>>>>>> thus falls into the fallacy of the assumption of the conclusion.
>>>>>>
>>>>>>>
>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>> whether or not H aborts its simulation.
>>>>>>
>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>
>>>>> So you believe that when H aborts its simulation this causes the
>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>> aborted before reaching this instruction?
>>>>>
>>>>> Unless you reverse your position technically competent reviewers
>>>>> will understand that you are not a sufficiently technically
>>>>> competent reviewer.
>>>>>
>>>>>>
>>>>>> If H aborts its simulation, then a correct and complete simulation
>>>>>> of the input will reach the return instruction.
>>>>>
>>>>> If H aborts its simulation of P then the simulated P that is no
>>>>> longer running will continue several more execution steps and reach
>>>>> its "ret" instruction even though it has been forced to stop
>>>>> running before ever reaching the "ret" instruction.
>>>>
>>>> No, it causes the ACTUAL P, and the correct and COMPLETE simulation
>>>> of the input to H(P,P) to reach the return instruction.
>>> There is only a simulated P in the following:
>>
>> Right, but that doesn;t mean the PROGRAM P(P) doesn't actually have
>> the ability to exist.
>>
>> we just need to change main() to
>>
>> int main() {
>>      Output("Input_Halts = ", H(P,P));
>>      P(P);
>>      Output("P(P) Halted");
>> }
>>
>> To make it come into existance.
>>
>> If this isn't allowed, you system isn't Turing complete and you
>> "universe" you are defining worthless to talk about the Halting Problem.
>>
>>>
>>> typedef void (*ptr)();
>>> int H(ptr p, ptr i); // simulating halt decider
>>>
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> So you agree that the input to H(P,P) that is correctly simulated by
>>> H cannot possibly reach the "ret" instruction of this simulated P
>>> whether or not H aborts its simulation or not?
>>>
>>
>> Yes, "BY H".
>>
>> But that DOESN'T prove the the input represents a non-halting input,
> Within these halt deciding principles it does:
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
>

And the ACTUAL BEHAVIOR of the input to H(M,x) is the behavior of M(x).
DEFINITION.

If you disagree, you are admitting that H isn't a Halt Decider, because
you criteria doesn't match the one DEFINED for a Halt Decider.

You STILL Haven't show where you thing the first point of divergance
between the ACTUAL excution of P(P) and the simulation of H(P,P) occurs
and that H is CORRECTLY SIMULATING.

So, that claim is still just one of your blantant lies.

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

Right, The Turing Machine, that is the M(x) or P(P) not the simulation
of the input done by the decider.

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

So, all you have done is admit that don't understand what a Halt Decider
does, because you claim it needs to follow a different criteria than
what it must follow.

Note, you "proof" that the input to H(P,P) has a different behavior than
P(P) really is just proving that a Halt Decider can't correctly answer
that problem, not that you get to change the problem, as that just isn't
allowed.

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.

You H doesn't do a COMPLETE and correct simulation (at least when it
answers non-hatling) so the behavior of the simulation doesn't show the
behavior of the input.

Note, YOU reject that a definition of what H needs to do is:

H(M,x) accept if UTM(M,x) Halts, and reject if UTM(Mx) will never halt.

since BY DEFINITION the behavior of UTM(M,x) matches M(x), so UTM(P,P)
matches P(P), so the behavior of the input to H(P,P) would be the
behavior of P(P) which you reject as it shows you to be wrong.

Note, one key part is even with a UTM, the actual behavior of the
Program is the defining operation, and the UTM's behavior only a usable
substitute if it matches.