This exact same analysis always applies to the input to H(P,P) no matter
how it is called including this example:

int main()
{ P((u32)P);
}

the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program
and an input, whether the program will finish running, or continue
to run forever. https://en.wikipedia.org/wiki/Halting_problem

Because the halting problem only requires that the (at least partial)
halt decider decide its input correctly the fact that the direct
invocation of P(P) is not an input to H, means that it is not relevant
to the halting problem.

The P(P) of main() only halts because H(P,P) correctly decides that its
input never halts. This cause-and-effect relationship between the
simulated P and the executed P proves that the simulated P and the
executed P are distinctly different computations.

Because they are different computations the fact that the executed P
halts does not contradict the fact that the simulated P never halts.

While H remains in pure simulation mode simulating the input to H(P,P)
this simulated input never halts thus conclusively proving that H
decides this input correctly.

Because H only acts as a pure simulator of its input until after its
halt status decision has been made it has no behavior that can possibly
effect the behavior of its input. Because of this H screens out its own
address range in every execution trace that it examines. This is why we
never see any instructions of H in any execution trace after an input
calls H.

*Halting computation* is any computation that eventually reaches its own
final state. This criteria divides computations that halt from those
that merely stop running because their simulation was aborted.

A Turing machine is said to halt whenever it reaches a configuration
for which δ is not defined; this is possible because δ is a partial
function. In fact, we will assume that no transitions are defined for
any final state, so the Turing machine will halt whenever it enters a
final state. (Linz:1990:234)

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36 // push P
[00000c5e](05) 68360c0000 push 00000c36 // push P
[00000c63](05) e8fefcffff call 00000966 // call H(P,P)
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

We can see that the first seven lines of P repeat. P calls H(P,P) that
simulates P(P) that calls H(P,P) in a cycle the never stops unless H
stops simulating its input. When H does stop simulating its input P
never reaches its final state of [00000c50] therefore never halts even
though it stops running.

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[00000c68][0010172a][00000000] 83c408 add esp,+08
[00000c6b][00101726][00000000] 50 push eax
[00000c6c][00101722][00000357] 6857030000 push 00000357
[00000c71][00101722][00000357] e810f7ffff call 00000386
Input_Halts = 0
[00000c76][0010172a][00000000] 83c408 add esp,+08
[00000c79][0010172a][00000000] 33c0 xor eax,eax
[00000c7b][0010172e][00100000] 5d pop ebp
[00000c7c][00101732][00000068] c3 ret
Number_of_User_Instructions(27)
Number of Instructions Executed(23721)

*Strachey, C 1965* An impossible program The Computer Journal, Volume
7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

*Linz, Peter 1990* An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/14/2021 10:17 AM, olcott wrote:
> This exact same analysis always applies to the input to H(P,P) no matter
> how it is called including this example:
>
> int main()
> {
>   P((u32)P);
> }
>
>    the Turing machine halting problem. Simply stated, the problem
>    is: given the description of a Turing machine M and an input w,
>    does M, when started in the initial configuration q0w, perform a
>    computation that eventually halts? (Linz:1990:317).
>
>    In computability theory, the halting problem is the problem of
>    determining, from a description of an arbitrary computer program
>    and an input, whether the program will finish running, or continue
>    to run forever. https://en.wikipedia.org/wiki/Halting_problem
>
> Because the halting problem only requires that the (at least partial)
> halt decider decide its input correctly the fact that the direct
> invocation of P(P) is not an input to H, means that it is not relevant
> to the halting problem.
>
> The P(P) of main() only halts because H(P,P) correctly decides that its
> input never halts. This cause-and-effect relationship between the
> simulated P and the executed P proves that the simulated P and the
> executed P are distinctly different computations.
>
> Because they are different computations the fact that the executed P
> halts does not contradict the fact that the simulated P never halts.
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never halts thus conclusively proving that H
> decides this input correctly.
>
> Because H only acts as a pure simulator of its input until after its
> halt status decision has been made it has no behavior that can possibly
> effect the behavior of its input. Because of this H screens out its own
> address range in every execution trace that it examines. This is why we
> never see any instructions of H in any execution trace after an input
> calls H.
>
> *Halting computation* is any computation that eventually reaches its own
> final state. This criteria divides computations that halt from those
> that merely stop running because their simulation was aborted.
>
>   A Turing machine is said to halt whenever it reaches a configuration
>   for which δ is not defined; this is possible because δ is a partial
>   function. In fact, we will assume that no transitions are defined for
>   any final state, so the Turing machine will halt whenever it enters a
>   final state. (Linz:1990:234)
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> _main()
> [00000c56](01)  55          push ebp
> [00000c57](02)  8bec        mov ebp,esp
> [00000c59](05)  68360c0000  push 00000c36    // push P
> [00000c5e](05)  68360c0000  push 00000c36    // push P
> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
> [00000c68](03)  83c408      add esp,+08
> [00000c6b](01)  50          push eax
> [00000c6c](05)  6857030000  push 00000357
> [00000c71](05)  e810f7ffff  call 00000386
> [00000c76](03)  83c408      add esp,+08
> [00000c79](02)  33c0        xor eax,eax
> [00000c7b](01)  5d          pop ebp
> [00000c7c](01)  c3          ret
> Size in bytes:(0039) [00000c7c]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c56][0010172a][00000000] 55          push ebp
> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> We can see that the first seven lines of P repeat. P calls H(P,P) that
> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
> stops simulating its input. When H does stop simulating its input P
> never reaches its final state of [00000c50] therefore never halts even
> though it stops running.
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [00000c68][0010172a][00000000] 83c408      add esp,+08
> [00000c6b][00101726][00000000] 50          push eax
> [00000c6c][00101722][00000357] 6857030000  push 00000357
> [00000c71][00101722][00000357] e810f7ffff  call 00000386
> Input_Halts = 0
> [00000c76][0010172a][00000000] 83c408      add esp,+08
> [00000c79][0010172a][00000000] 33c0        xor eax,eax
> [00000c7b][0010172e][00100000] 5d          pop ebp
> [00000c7c][00101732][00000068] c3          ret
> Number_of_User_Instructions(27)
> Number of Instructions Executed(23721)
>
> *Strachey, C 1965*  An impossible program The Computer Journal, Volume
> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>
> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>

**test bolding**

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
> This exact same analysis always applies to the input to H(P,P) no matter
> how it is called including this example:
>
> int main()
> {
> P((u32)P);
> }
>
> the Turing machine halting problem. Simply stated, the problem
> is: given the description of a Turing machine M and an input w,
> does M, when started in the initial configuration q0w, perform a
> computation that eventually halts? (Linz:1990:317).
>
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program
> and an input, whether the program will finish running, or continue
> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>
> Because the halting problem only requires that the (at least partial)
> halt decider decide its input correctly the fact that the direct
> invocation of P(P) is not an input to H, means that it is not relevant
> to the halting problem.
I do not know English well, but I (almost every programmer) am sure the halting
problem means a program H decides whether P(input) will halt or not.
If the quoted texts is read to you differently, it is the problem of that texts.
Submit message to the authors.

If the direct invocation of P(P) is not relevant to the halting problem, then
H can do whatever you like, therefore, meaningless if not garbage.

> The P(P) of main() only halts because H(P,P) correctly decides that its
> input never halts. This cause-and-effect relationship between the
> simulated P and the executed P proves that the simulated P and the
> executed P are distinctly different computations.
>
> Because they are different computations the fact that the executed P
> halts does not contradict the fact that the simulated P never halts.
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never halts thus conclusively proving that H
> decides this input correctly.
>
> Because H only acts as a pure simulator of its input until after its
> halt status decision has been made it has no behavior that can possibly
> effect the behavior of its input. Because of this H screens out its own
> address range in every execution trace that it examines. This is why we
> never see any instructions of H in any execution trace after an input
> calls H.
>
> *Halting computation* is any computation that eventually reaches its own
> final state. This criteria divides computations that halt from those
> that merely stop running because their simulation was aborted.
>
> A Turing machine is said to halt whenever it reaches a configuration
> for which δ is not defined; this is possible because δ is a partial
> function. In fact, we will assume that no transitions are defined for
> any final state, so the Turing machine will halt whenever it enters a
> final state. (Linz:1990:234)
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00000c36](01) 55 push ebp
> [00000c37](02) 8bec mov ebp,esp
> [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
> [00000c3c](01) 50 push eax
> [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
> [00000c40](01) 51 push ecx
> [00000c41](05) e820fdffff call 00000966 // call H
> [00000c46](03) 83c408 add esp,+08
> [00000c49](02) 85c0 test eax,eax
> [00000c4b](02) 7402 jz 00000c4f
> [00000c4d](02) ebfe jmp 00000c4d
> [00000c4f](01) 5d pop ebp
> [00000c50](01) c3 ret
> Size in bytes:(0027) [00000c50]
>
> _main()
> [00000c56](01) 55 push ebp
> [00000c57](02) 8bec mov ebp,esp
> [00000c59](05) 68360c0000 push 00000c36 // push P
> [00000c5e](05) 68360c0000 push 00000c36 // push P
> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
> [00000c68](03) 83c408 add esp,+08
> [00000c6b](01) 50 push eax
> [00000c6c](05) 6857030000 push 00000357
> [00000c71](05) e810f7ffff call 00000386
> [00000c76](03) 83c408 add esp,+08
> [00000c79](02) 33c0 xor eax,eax
> [00000c7b](01) 5d pop ebp
> [00000c7c](01) c3 ret
> Size in bytes:(0039) [00000c7c]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00000c56][0010172a][00000000] 55 push ebp
> [00000c57][0010172a][00000000] 8bec mov ebp,esp
> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
> [00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55 push ebp
> [00000c37][002117ca][002117ce] 8bec mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50 push eax // push P
> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51 push ecx // push P
> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
>
> We can see that the first seven lines of P repeat. P calls H(P,P) that
> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
> stops simulating its input. When H does stop simulating its input P
> never reaches its final state of [00000c50] therefore never halts even
> though it stops running.
>
> [00000c36][0025c1f2][0025c1f6] 55 push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50 push eax // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51 push ecx // push P
> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [00000c68][0010172a][00000000] 83c408 add esp,+08
> [00000c6b][00101726][00000000] 50 push eax
> [00000c6c][00101722][00000357] 6857030000 push 00000357
> [00000c71][00101722][00000357] e810f7ffff call 00000386
> Input_Halts = 0
> [00000c76][0010172a][00000000] 83c408 add esp,+08
> [00000c79][0010172a][00000000] 33c0 xor eax,eax
> [00000c7b][0010172e][00100000] 5d pop ebp
> [00000c7c][00101732][00000068] c3 ret
> Number_of_User_Instructions(27)
> Number of Instructions Executed(23721)
>
> *Strachey, C 1965* An impossible program The Computer Journal, Volume
> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>
> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

On 8/14/2021 11:05 AM, wij wrote:
> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>> This exact same analysis always applies to the input to H(P,P) no matter
>> how it is called including this example:
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> the Turing machine halting problem. Simply stated, the problem
>> is: given the description of a Turing machine M and an input w,
>> does M, when started in the initial configuration q0w, perform a
>> computation that eventually halts? (Linz:1990:317).
>>
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program
>> and an input, whether the program will finish running, or continue
>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>
>> Because the halting problem only requires that the (at least partial)
>> halt decider decide its input correctly the fact that the direct
>> invocation of P(P) is not an input to H, means that it is not relevant
>> to the halting problem.
>
> I do not know English well, but I (almost every programmer) am sure the halting
> problem means a program H decides whether P(input) will halt or not.
> If the quoted texts is read to you differently, it is the problem of that texts.
> Submit message to the authors.
>

The quoted texts are accurate. The (at least partial) halt decider must
only correctly decide the halt status of its input. Computations that
are not inputs to the halt decider do not pertain to the halting problem.

> If the direct invocation of P(P) is not relevant to the halting problem, then
> H can do whatever you like, therefore, meaningless if not garbage.
>

The halting problem is only concerned with an at least partial halt
decider correctly deciding whether or not its input halts, thus it can
do whatever its wants as long as it does decide the correct halt status
of its input.

In every configuration H does correctly decide that its input (P,P)
never halts. This can be verified beyond all possible doubt by the x86
execution trace of the simulation of P(P) shown below.

>> The P(P) of main() only halts because H(P,P) correctly decides that its
>> input never halts. This cause-and-effect relationship between the
>> simulated P and the executed P proves that the simulated P and the
>> executed P are distinctly different computations.
>>
>> Because they are different computations the fact that the executed P
>> halts does not contradict the fact that the simulated P never halts.
>>
>> While H remains in pure simulation mode simulating the input to H(P,P)
>> this simulated input never halts thus conclusively proving that H
>> decides this input correctly.
>>
>> Because H only acts as a pure simulator of its input until after its
>> halt status decision has been made it has no behavior that can possibly
>> effect the behavior of its input. Because of this H screens out its own
>> address range in every execution trace that it examines. This is why we
>> never see any instructions of H in any execution trace after an input
>> calls H.
>>
>> *Halting computation* is any computation that eventually reaches its own
>> final state. This criteria divides computations that halt from those
>> that merely stop running because their simulation was aborted.
>>
>> A Turing machine is said to halt whenever it reaches a configuration
>> for which δ is not defined; this is possible because δ is a partial
>> function. In fact, we will assume that no transitions are defined for
>> any final state, so the Turing machine will halt whenever it enters a
>> final state. (Linz:1990:234)
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> // Strachey(1965) CPL translated to C
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00000c36](01) 55 push ebp
>> [00000c37](02) 8bec mov ebp,esp
>> [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
>> [00000c3c](01) 50 push eax
>> [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
>> [00000c40](01) 51 push ecx
>> [00000c41](05) e820fdffff call 00000966 // call H
>> [00000c46](03) 83c408 add esp,+08
>> [00000c49](02) 85c0 test eax,eax
>> [00000c4b](02) 7402 jz 00000c4f
>> [00000c4d](02) ebfe jmp 00000c4d
>> [00000c4f](01) 5d pop ebp
>> [00000c50](01) c3 ret
>> Size in bytes:(0027) [00000c50]
>>
>> _main()
>> [00000c56](01) 55 push ebp
>> [00000c57](02) 8bec mov ebp,esp
>> [00000c59](05) 68360c0000 push 00000c36 // push P
>> [00000c5e](05) 68360c0000 push 00000c36 // push P
>> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
>> [00000c68](03) 83c408 add esp,+08
>> [00000c6b](01) 50 push eax
>> [00000c6c](05) 6857030000 push 00000357
>> [00000c71](05) e810f7ffff call 00000386
>> [00000c76](03) 83c408 add esp,+08
>> [00000c79](02) 33c0 xor eax,eax
>> [00000c7b](01) 5d pop ebp
>> [00000c7c](01) c3 ret
>> Size in bytes:(0039) [00000c7c]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [00000c56][0010172a][00000000] 55 push ebp
>> [00000c57][0010172a][00000000] 8bec mov ebp,esp
>> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
>> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
>> [00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
>>
>> Begin Local Halt Decider Simulation at Machine Address:c36
>> [00000c36][002117ca][002117ce] 55 push ebp
>> [00000c37][002117ca][002117ce] 8bec mov ebp,esp
>> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
>> [00000c3c][002117c6][00000c36] 50 push eax // push P
>> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
>> [00000c40][002117c2][00000c36] 51 push ecx // push P
>> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
>>
>> We can see that the first seven lines of P repeat. P calls H(P,P) that
>> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
>> stops simulating its input. When H does stop simulating its input P
>> never reaches its final state of [00000c50] therefore never halts even
>> though it stops running.
>>
>> [00000c36][0025c1f2][0025c1f6] 55 push ebp
>> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
>> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
>> [00000c3c][0025c1ee][00000c36] 50 push eax // push P
>> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
>> [00000c40][0025c1ea][00000c36] 51 push ecx // push P
>> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> [00000c68][0010172a][00000000] 83c408 add esp,+08
>> [00000c6b][00101726][00000000] 50 push eax
>> [00000c6c][00101722][00000357] 6857030000 push 00000357
>> [00000c71][00101722][00000357] e810f7ffff call 00000386
>> Input_Halts = 0
>> [00000c76][0010172a][00000000] 83c408 add esp,+08
>> [00000c79][0010172a][00000000] 33c0 xor eax,eax
>> [00000c7b][0010172e][00100000] 5d pop ebp
>> [00000c7c][00101732][00000068] c3 ret
>> Number_of_User_Instructions(27)
>> Number of Instructions Executed(23721)
>>
>> *Strachey, C 1965* An impossible program The Computer Journal, Volume
>> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>>
>> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company.
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
> On 8/14/2021 11:05 AM, wij wrote:
> > On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
> >> This exact same analysis always applies to the input to H(P,P) no matter
> >> how it is called including this example:
> >>
> >> int main()
> >> {
> >> P((u32)P);
> >> }
> >>
> >> the Turing machine halting problem. Simply stated, the problem
> >> is: given the description of a Turing machine M and an input w,
> >> does M, when started in the initial configuration q0w, perform a
> >> computation that eventually halts? (Linz:1990:317).
> >>
> >> In computability theory, the halting problem is the problem of
> >> determining, from a description of an arbitrary computer program
> >> and an input, whether the program will finish running, or continue
> >> to run forever. https://en.wikipedia.org/wiki/Halting_problem
> >>
> >> Because the halting problem only requires that the (at least partial)
> >> halt decider decide its input correctly the fact that the direct
> >> invocation of P(P) is not an input to H, means that it is not relevant
> >> to the halting problem.
> >
> > I do not know English well, but I (almost every programmer) am sure the halting
> > problem means a program H decides whether P(input) will halt or not.
> > If the quoted texts is read to you differently, it is the problem of that texts.
> > Submit message to the authors.
> >
> The quoted texts are accurate. The (at least partial) halt decider must
> only correctly decide the halt status of its input. Computations that
> are not inputs to the halt decider do not pertain to the halting problem.

Obviously the quoted text means differently to you and almost all programmers in
the world. You are addressing your own interpretation. This is OK, but the
interpretation is meaningless.

> > If the direct invocation of P(P) is not relevant to the halting problem, then
> > H can do whatever you like, therefore, meaningless if not garbage.
> >
> The halting problem is only concerned with an at least partial halt
> decider correctly deciding whether or not its input halts, thus it can
> do whatever its wants as long as it does decide the correct halt status
> of its input.
>

int H2(Prog P) {
return 0;
} What is the difference of your H with H2?
H2 can also correctly (at least partial) answer the halting problem, and can
be verified.

> In every configuration H does correctly decide that its input (P,P)
> never halts. This can be verified beyond all possible doubt by the x86
> execution trace of the simulation of P(P) shown below.
> >> The P(P) of main() only halts because H(P,P) correctly decides that its
> >> input never halts. This cause-and-effect relationship between the
> >> simulated P and the executed P proves that the simulated P and the
> >> executed P are distinctly different computations.
> >>
> >> Because they are different computations the fact that the executed P
> >> halts does not contradict the fact that the simulated P never halts.
> >>
> >> While H remains in pure simulation mode simulating the input to H(P,P)
> >> this simulated input never halts thus conclusively proving that H
> >> decides this input correctly.
> >>
> >> Because H only acts as a pure simulator of its input until after its
> >> halt status decision has been made it has no behavior that can possibly
> >> effect the behavior of its input. Because of this H screens out its own
> >> address range in every execution trace that it examines. This is why we
> >> never see any instructions of H in any execution trace after an input
> >> calls H.
> >>
> >> *Halting computation* is any computation that eventually reaches its own
> >> final state. This criteria divides computations that halt from those
> >> that merely stop running because their simulation was aborted.
> >>
> >> A Turing machine is said to halt whenever it reaches a configuration
> >> for which δ is not defined; this is possible because δ is a partial
> >> function. In fact, we will assume that no transitions are defined for
> >> any final state, so the Turing machine will halt whenever it enters a
> >> final state. (Linz:1990:234)
> >>
> >> // Simplified Linz Ĥ (Linz:1990:319)
> >> // Strachey(1965) CPL translated to C
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)P, (u32)P));
> >> }
> >>
> >> _P()
> >> [00000c36](01) 55 push ebp
> >> [00000c37](02) 8bec mov ebp,esp
> >> [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
> >> [00000c3c](01) 50 push eax
> >> [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
> >> [00000c40](01) 51 push ecx
> >> [00000c41](05) e820fdffff call 00000966 // call H
> >> [00000c46](03) 83c408 add esp,+08
> >> [00000c49](02) 85c0 test eax,eax
> >> [00000c4b](02) 7402 jz 00000c4f
> >> [00000c4d](02) ebfe jmp 00000c4d
> >> [00000c4f](01) 5d pop ebp
> >> [00000c50](01) c3 ret
> >> Size in bytes:(0027) [00000c50]
> >>
> >> _main()
> >> [00000c56](01) 55 push ebp
> >> [00000c57](02) 8bec mov ebp,esp
> >> [00000c59](05) 68360c0000 push 00000c36 // push P
> >> [00000c5e](05) 68360c0000 push 00000c36 // push P
> >> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
> >> [00000c68](03) 83c408 add esp,+08
> >> [00000c6b](01) 50 push eax
> >> [00000c6c](05) 6857030000 push 00000357
> >> [00000c71](05) e810f7ffff call 00000386
> >> [00000c76](03) 83c408 add esp,+08
> >> [00000c79](02) 33c0 xor eax,eax
> >> [00000c7b](01) 5d pop ebp
> >> [00000c7c](01) c3 ret
> >> Size in bytes:(0039) [00000c7c]
> >>
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= =============
> >> [00000c56][0010172a][00000000] 55 push ebp
> >> [00000c57][0010172a][00000000] 8bec mov ebp,esp
> >> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
> >> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
> >> [00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
> >>
> >> Begin Local Halt Decider Simulation at Machine Address:c36
> >> [00000c36][002117ca][002117ce] 55 push ebp
> >> [00000c37][002117ca][002117ce] 8bec mov ebp,esp
> >> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
> >> [00000c3c][002117c6][00000c36] 50 push eax // push P
> >> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
> >> [00000c40][002117c2][00000c36] 51 push ecx // push P
> >> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
> >>
> >> We can see that the first seven lines of P repeat. P calls H(P,P) that
> >> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
> >> stops simulating its input. When H does stop simulating its input P
> >> never reaches its final state of [00000c50] therefore never halts even
> >> though it stops running.
> >>
> >> [00000c36][0025c1f2][0025c1f6] 55 push ebp
> >> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
> >> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
> >> [00000c3c][0025c1ee][00000c36] 50 push eax // push P
> >> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
> >> [00000c40][0025c1ea][00000c36] 51 push ecx // push P
> >> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
> >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >>
> >> [00000c68][0010172a][00000000] 83c408 add esp,+08
> >> [00000c6b][00101726][00000000] 50 push eax
> >> [00000c6c][00101722][00000357] 6857030000 push 00000357
> >> [00000c71][00101722][00000357] e810f7ffff call 00000386
> >> Input_Halts = 0
> >> [00000c76][0010172a][00000000] 83c408 add esp,+08
> >> [00000c79][0010172a][00000000] 33c0 xor eax,eax
> >> [00000c7b][0010172e][00100000] 5d pop ebp
> >> [00000c7c][00101732][00000068] c3 ret
> >> Number_of_User_Instructions(27)
> >> Number of Instructions Executed(23721)
> >>
> >> *Strachey, C 1965* An impossible program The Computer Journal, Volume
> >> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4..313
> >>
> >> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
> >> Lexington/Toronto: D. C. Heath and Company.
> >>
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> "Great spirits have always encountered violent opposition from mediocre
> >> minds." Einstein
>
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

On 8/14/21 11:17 AM, olcott wrote:
> This exact same analysis always applies to the input to H(P,P) no matter
> how it is called including this example:
>
> int main()
> {
>   P((u32)P);
> }
>
>    the Turing machine halting problem. Simply stated, the problem
>    is: given the description of a Turing machine M and an input w,
>    does M, when started in the initial configuration q0w, perform a
>    computation that eventually halts? (Linz:1990:317).
>
>    In computability theory, the halting problem is the problem of
>    determining, from a description of an arbitrary computer program
>    and an input, whether the program will finish running, or continue
>    to run forever. https://en.wikipedia.org/wiki/Halting_problem
>
> Because the halting problem only requires that the (at least partial)
> halt decider decide its input correctly the fact that the direct
> invocation of P(P) is not an input to H, means that it is not relevant
> to the halting problem.
>
> The P(P) of main() only halts because H(P,P) correctly decides that its
> input never halts. This cause-and-effect relationship between the
> simulated P and the executed P proves that the simulated P and the
> executed P are distinctly different computations.
>
> Because they are different computations the fact that the executed P
> halts does not contradict the fact that the simulated P never halts.

If P(P) is a different computation than the compuation given to H then
you have failed to meet the requirements of the proof.

If you mean they are different instances of the same algorithm/input
then they MUST generate the same results or it isn't a computation,
which just proves that H isn't a computation and thus fail to meet the
requirements.

UNSOUND LOGIC
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never halts thus conclusively proving that H
> decides this input correctly.

UNSOUND, DISPROVEN
>
> Because H only acts as a pure simulator of its input until after its
> halt status decision has been made it has no behavior that can possibly
> effect the behavior of its input. Because of this H screens out its own
> address range in every execution trace that it examines. This is why we
> never see any instructions of H in any execution trace after an input
> calls H.

UNSOUND, DISPROVEN.

>
> *Halting computation* is any computation that eventually reaches its own
> final state. This criteria divides computations that halt from those
> that merely stop running because their simulation was aborted.
>
>   A Turing machine is said to halt whenever it reaches a configuration
>   for which δ is not defined; this is possible because δ is a partial
>   function. In fact, we will assume that no transitions are defined for
>   any final state, so the Turing machine will halt whenever it enters a
>   final state. (Linz:1990:234)
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> _main()
> [00000c56](01)  55          push ebp
> [00000c57](02)  8bec        mov ebp,esp
> [00000c59](05)  68360c0000  push 00000c36    // push P
> [00000c5e](05)  68360c0000  push 00000c36    // push P
> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
> [00000c68](03)  83c408      add esp,+08
> [00000c6b](01)  50          push eax
> [00000c6c](05)  6857030000  push 00000357
> [00000c71](05)  e810f7ffff  call 00000386
> [00000c76](03)  83c408      add esp,+08
> [00000c79](02)  33c0        xor eax,eax
> [00000c7b](01)  5d          pop ebp
> [00000c7c](01)  c3          ret
> Size in bytes:(0039) [00000c7c]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c56][0010172a][00000000] 55          push ebp
> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> We can see that the first seven lines of P repeat. P calls H(P,P) that
> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
> stops simulating its input. When H does stop simulating its input P
> never reaches its final state of [00000c50] therefore never halts even
> though it stops running.
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [00000c68][0010172a][00000000] 83c408      add esp,+08
> [00000c6b][00101726][00000000] 50          push eax
> [00000c6c][00101722][00000357] 6857030000  push 00000357
> [00000c71][00101722][00000357] e810f7ffff  call 00000386
> Input_Halts = 0
> [00000c76][0010172a][00000000] 83c408      add esp,+08
> [00000c79][0010172a][00000000] 33c0        xor eax,eax
> [00000c7b][0010172e][00100000] 5d          pop ebp
> [00000c7c][00101732][00000068] c3          ret
> Number_of_User_Instructions(27)
> Number of Instructions Executed(23721)
>
> *Strachey, C 1965*  An impossible program The Computer Journal, Volume
> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>
> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>

On 8/14/21 12:16 PM, olcott wrote:
> On 8/14/2021 11:05 AM, wij wrote:
>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>> This exact same analysis always applies to the input to H(P,P) no matter
>>> how it is called including this example:
>>>
>>> int main()
>>> {
>>> P((u32)P);
>>> }
>>>
>>> the Turing machine halting problem. Simply stated, the problem
>>> is: given the description of a Turing machine M and an input w,
>>> does M, when started in the initial configuration q0w, perform a
>>> computation that eventually halts? (Linz:1990:317).
>>>
>>> In computability theory, the halting problem is the problem of
>>> determining, from a description of an arbitrary computer program
>>> and an input, whether the program will finish running, or continue
>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> Because the halting problem only requires that the (at least partial)
>>> halt decider decide its input correctly the fact that the direct
>>> invocation of P(P) is not an input to H, means that it is not relevant
>>> to the halting problem.
>>   I do not know English well, but I (almost every programmer) am sure
>> the halting
>> problem means a program H decides whether P(input) will halt or not.
>> If the quoted texts is read to you differently, it is the problem of
>> that texts.
>> Submit message to the authors.
>>
>
> The quoted texts are accurate. The (at least partial) halt decider must
> only correctly decide the halt status of its input. Computations that
> are not inputs to the halt decider do not pertain to the halting problem.
>

This is the point where you use of English is incorrect, and you need to
restudy English so you understand what you are saying.

*Inputs* are NEVER *Computations* in and of themselves, but are merely
the string representations of the ACTUAL Computations.

As such, 'inputs' don't halt or be non-halting, only the machines they
represent.

>> If the direct invocation of P(P) is not relevant to the halting
>> problem, then
>> H can do whatever you like, therefore, meaningless if not garbage.
>>
>
> The halting problem is only concerned with an at least partial halt
> decider correctly deciding whether or not its input halts, thus it can
> do whatever its wants as long as it does decide the correct halt status
> of its input.

WRONG. It is concerned if the machine the input REPRESENTS halts or not.

That machine IS the P(P) you say is not relevant, but is actually the
only thing that IS relevant.

Read the statement you quoted.

>
> In every configuration H does correctly decide that its input (P,P)
> never halts. This can be verified beyond all possible doubt by the x86
> execution trace of the simulation of P(P) shown below.

WRONG, DISPROVEN.

On 8/14/2021 11:35 AM, wij wrote:
> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>> On 8/14/2021 11:05 AM, wij wrote:
>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>> how it is called including this example:
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> the Turing machine halting problem. Simply stated, the problem
>>>> is: given the description of a Turing machine M and an input w,
>>>> does M, when started in the initial configuration q0w, perform a
>>>> computation that eventually halts? (Linz:1990:317).
>>>>
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program
>>>> and an input, whether the program will finish running, or continue
>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> Because the halting problem only requires that the (at least partial)
>>>> halt decider decide its input correctly the fact that the direct
>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>> to the halting problem.
>>>
>>> I do not know English well, but I (almost every programmer) am sure the halting
>>> problem means a program H decides whether P(input) will halt or not.
>>> If the quoted texts is read to you differently, it is the problem of that texts.
>>> Submit message to the authors.
>>>
>> The quoted texts are accurate. The (at least partial) halt decider must
>> only correctly decide the halt status of its input. Computations that
>> are not inputs to the halt decider do not pertain to the halting problem.
>
> Obviously the quoted text means differently to you and almost all programmers in
> the world. You are addressing your own interpretation. This is OK, but the
> interpretation is meaningless.

"the description of a Turing machine M" does not mean Turing machine M.
If people interpret this to mean Turing machine M they are wrong.

>>> If the direct invocation of P(P) is not relevant to the halting problem, then
>>> H can do whatever you like, therefore, meaningless if not garbage.
>>>
>> The halting problem is only concerned with an at least partial halt
>> decider correctly deciding whether or not its input halts, thus it can
>> do whatever its wants as long as it does decide the correct halt status
>> of its input.
>>
>
> int H2(Prog P) {
> return 0;
> }
> What is the difference of your H with H2?
> H2 can also correctly (at least partial) answer the halting problem, and can
> be verified.
>

My H has intelligence and can be verified to derive a halt status that
corresponds to every halting computation and can be verified to derive a
halt status that corresponds to that halt status of every input that it
determines never halts.

H is always correct for all:
(a) halting computations.
(b) computations that it decides never halt.

>> In every configuration H does correctly decide that its input (P,P)
>> never halts. This can be verified beyond all possible doubt by the x86
>> execution trace of the simulation of P(P) shown below.
>>>> The P(P) of main() only halts because H(P,P) correctly decides that its
>>>> input never halts. This cause-and-effect relationship between the
>>>> simulated P and the executed P proves that the simulated P and the
>>>> executed P are distinctly different computations.
>>>>
>>>> Because they are different computations the fact that the executed P
>>>> halts does not contradict the fact that the simulated P never halts.
>>>>
>>>> While H remains in pure simulation mode simulating the input to H(P,P)
>>>> this simulated input never halts thus conclusively proving that H
>>>> decides this input correctly.
>>>>
>>>> Because H only acts as a pure simulator of its input until after its
>>>> halt status decision has been made it has no behavior that can possibly
>>>> effect the behavior of its input. Because of this H screens out its own
>>>> address range in every execution trace that it examines. This is why we
>>>> never see any instructions of H in any execution trace after an input
>>>> calls H.
>>>>
>>>> *Halting computation* is any computation that eventually reaches its own
>>>> final state. This criteria divides computations that halt from those
>>>> that merely stop running because their simulation was aborted.
>>>>
>>>> A Turing machine is said to halt whenever it reaches a configuration
>>>> for which δ is not defined; this is possible because δ is a partial
>>>> function. In fact, we will assume that no transitions are defined for
>>>> any final state, so the Turing machine will halt whenever it enters a
>>>> final state. (Linz:1990:234)
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> // Strachey(1965) CPL translated to C
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00000c36](01) 55 push ebp
>>>> [00000c37](02) 8bec mov ebp,esp
>>>> [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
>>>> [00000c3c](01) 50 push eax
>>>> [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
>>>> [00000c40](01) 51 push ecx
>>>> [00000c41](05) e820fdffff call 00000966 // call H
>>>> [00000c46](03) 83c408 add esp,+08
>>>> [00000c49](02) 85c0 test eax,eax
>>>> [00000c4b](02) 7402 jz 00000c4f
>>>> [00000c4d](02) ebfe jmp 00000c4d
>>>> [00000c4f](01) 5d pop ebp
>>>> [00000c50](01) c3 ret
>>>> Size in bytes:(0027) [00000c50]
>>>>
>>>> _main()
>>>> [00000c56](01) 55 push ebp
>>>> [00000c57](02) 8bec mov ebp,esp
>>>> [00000c59](05) 68360c0000 push 00000c36 // push P
>>>> [00000c5e](05) 68360c0000 push 00000c36 // push P
>>>> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
>>>> [00000c68](03) 83c408 add esp,+08
>>>> [00000c6b](01) 50 push eax
>>>> [00000c6c](05) 6857030000 push 00000357
>>>> [00000c71](05) e810f7ffff call 00000386
>>>> [00000c76](03) 83c408 add esp,+08
>>>> [00000c79](02) 33c0 xor eax,eax
>>>> [00000c7b](01) 5d pop ebp
>>>> [00000c7c](01) c3 ret
>>>> Size in bytes:(0039) [00000c7c]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [00000c56][0010172a][00000000] 55 push ebp
>>>> [00000c57][0010172a][00000000] 8bec mov ebp,esp
>>>> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
>>>> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
>>>> [00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
>>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>> [00000c36][002117ca][002117ce] 55 push ebp
>>>> [00000c37][002117ca][002117ce] 8bec mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50 push eax // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51 push ecx // push P
>>>> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
>>>>
>>>> We can see that the first seven lines of P repeat. P calls H(P,P) that
>>>> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
>>>> stops simulating its input. When H does stop simulating its input P
>>>> never reaches its final state of [00000c50] therefore never halts even
>>>> though it stops running.
>>>>
>>>> [00000c36][0025c1f2][0025c1f6] 55 push ebp
>>>> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
>>>> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
>>>> [00000c3c][0025c1ee][00000c36] 50 push eax // push P
>>>> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
>>>> [00000c40][0025c1ea][00000c36] 51 push ecx // push P
>>>> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> [00000c68][0010172a][00000000] 83c408 add esp,+08
>>>> [00000c6b][00101726][00000000] 50 push eax
>>>> [00000c6c][00101722][00000357] 6857030000 push 00000357
>>>> [00000c71][00101722][00000357] e810f7ffff call 00000386
>>>> Input_Halts = 0
>>>> [00000c76][0010172a][00000000] 83c408 add esp,+08
>>>> [00000c79][0010172a][00000000] 33c0 xor eax,eax
>>>> [00000c7b][0010172e][00100000] 5d pop ebp
>>>> [00000c7c][00101732][00000068] c3 ret
>>>> Number_of_User_Instructions(27)
>>>> Number of Instructions Executed(23721)
>>>>
>>>> *Strachey, C 1965* An impossible program The Computer Journal, Volume
>>>> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>>>>
>>>> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>>
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
> On 8/14/2021 11:35 AM, wij wrote:
> > On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
> >> On 8/14/2021 11:05 AM, wij wrote:
> >>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
> >>>> This exact same analysis always applies to the input to H(P,P) no matter
> >>>> how it is called including this example:
> >>>>
> >>>> int main()
> >>>> {
> >>>> P((u32)P);
> >>>> }
> >>>>
> >>>> the Turing machine halting problem. Simply stated, the problem
> >>>> is: given the description of a Turing machine M and an input w,
> >>>> does M, when started in the initial configuration q0w, perform a
> >>>> computation that eventually halts? (Linz:1990:317).
> >>>>
> >>>> In computability theory, the halting problem is the problem of
> >>>> determining, from a description of an arbitrary computer program
> >>>> and an input, whether the program will finish running, or continue
> >>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
> >>>>
> >>>> Because the halting problem only requires that the (at least partial)
> >>>> halt decider decide its input correctly the fact that the direct
> >>>> invocation of P(P) is not an input to H, means that it is not relevant
> >>>> to the halting problem.
> >>>
> >>> I do not know English well, but I (almost every programmer) am sure the halting
> >>> problem means a program H decides whether P(input) will halt or not.
> >>> If the quoted texts is read to you differently, it is the problem of that texts.
> >>> Submit message to the authors.
> >>>
> >> The quoted texts are accurate. The (at least partial) halt decider must
> >> only correctly decide the halt status of its input. Computations that
> >> are not inputs to the halt decider do not pertain to the halting problem.
> >
> > Obviously the quoted text means differently to you and almost all programmers in
> > the world. You are addressing your own interpretation. This is OK, but the
> > interpretation is meaningless.
> "the description of a Turing machine M" does not mean Turing machine M.
> If people interpret this to mean Turing machine M they are wrong.

Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
are also wrong, I and almost all programmers in the world can guarantee you this.

If both authors are also wrong, replying the rest message is meaningless.
You need to submit your interpretation to Linz and the author of the wiki.

> >>> If the direct invocation of P(P) is not relevant to the halting problem, then
> >>> H can do whatever you like, therefore, meaningless if not garbage.
> >>>
> >> The halting problem is only concerned with an at least partial halt
> >> decider correctly deciding whether or not its input halts, thus it can
> >> do whatever its wants as long as it does decide the correct halt status
> >> of its input.
> >>
> >
> > int H2(Prog P) {
> > return 0;
> > }
> > What is the difference of your H with H2?
> > H2 can also correctly (at least partial) answer the halting problem, and can
> > be verified.
> >
> My H has intelligence and can be verified to derive a halt status that
> corresponds to every halting computation and can be verified to derive a
> halt status that corresponds to that halt status of every input that it
> determines never halts.
>
> H is always correct for all:
> (a) halting computations.
> (b) computations that it decides never halt.
> >> In every configuration H does correctly decide that its input (P,P)
> >> never halts. This can be verified beyond all possible doubt by the x86
> >> execution trace of the simulation of P(P) shown below.
> >>>> The P(P) of main() only halts because H(P,P) correctly decides that its
> >>>> input never halts. This cause-and-effect relationship between the
> >>>> simulated P and the executed P proves that the simulated P and the
> >>>> executed P are distinctly different computations.
> >>>>
> >>>> Because they are different computations the fact that the executed P
> >>>> halts does not contradict the fact that the simulated P never halts.
> >>>>
> >>>> While H remains in pure simulation mode simulating the input to H(P,P)
> >>>> this simulated input never halts thus conclusively proving that H
> >>>> decides this input correctly.
> >>>>
> >>>> Because H only acts as a pure simulator of its input until after its
> >>>> halt status decision has been made it has no behavior that can possibly
> >>>> effect the behavior of its input. Because of this H screens out its own
> >>>> address range in every execution trace that it examines. This is why we
> >>>> never see any instructions of H in any execution trace after an input
> >>>> calls H.
> >>>>
> >>>> *Halting computation* is any computation that eventually reaches its own
> >>>> final state. This criteria divides computations that halt from those
> >>>> that merely stop running because their simulation was aborted.
> >>>>
> >>>> A Turing machine is said to halt whenever it reaches a configuration
> >>>> for which δ is not defined; this is possible because δ is a partial
> >>>> function. In fact, we will assume that no transitions are defined for
> >>>> any final state, so the Turing machine will halt whenever it enters a
> >>>> final state. (Linz:1990:234)
> >>>>
> >>>> // Simplified Linz Ĥ (Linz:1990:319)
> >>>> // Strachey(1965) CPL translated to C
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>> }
> >>>>
> >>>> _P()
> >>>> [00000c36](01) 55 push ebp
> >>>> [00000c37](02) 8bec mov ebp,esp
> >>>> [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
> >>>> [00000c3c](01) 50 push eax
> >>>> [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
> >>>> [00000c40](01) 51 push ecx
> >>>> [00000c41](05) e820fdffff call 00000966 // call H
> >>>> [00000c46](03) 83c408 add esp,+08
> >>>> [00000c49](02) 85c0 test eax,eax
> >>>> [00000c4b](02) 7402 jz 00000c4f
> >>>> [00000c4d](02) ebfe jmp 00000c4d
> >>>> [00000c4f](01) 5d pop ebp
> >>>> [00000c50](01) c3 ret
> >>>> Size in bytes:(0027) [00000c50]
> >>>>
> >>>> _main()
> >>>> [00000c56](01) 55 push ebp
> >>>> [00000c57](02) 8bec mov ebp,esp
> >>>> [00000c59](05) 68360c0000 push 00000c36 // push P
> >>>> [00000c5e](05) 68360c0000 push 00000c36 // push P
> >>>> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
> >>>> [00000c68](03) 83c408 add esp,+08
> >>>> [00000c6b](01) 50 push eax
> >>>> [00000c6c](05) 6857030000 push 00000357
> >>>> [00000c71](05) e810f7ffff call 00000386
> >>>> [00000c76](03) 83c408 add esp,+08
> >>>> [00000c79](02) 33c0 xor eax,eax
> >>>> [00000c7b](01) 5d pop ebp
> >>>> [00000c7c](01) c3 ret
> >>>> Size in bytes:(0039) [00000c7c]
> >>>>
> >>>> machine stack stack machine assembly
> >>>> address address data code language
> >>>> ======== ======== ======== ========= =============
> >>>> [00000c56][0010172a][00000000] 55 push ebp
> >>>> [00000c57][0010172a][00000000] 8bec mov ebp,esp
> >>>> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
> >>>> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
> >>>> [00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
> >>>>
> >>>> Begin Local Halt Decider Simulation at Machine Address:c36
> >>>> [00000c36][002117ca][002117ce] 55 push ebp
> >>>> [00000c37][002117ca][002117ce] 8bec mov ebp,esp
> >>>> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
> >>>> [00000c3c][002117c6][00000c36] 50 push eax // push P
> >>>> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
> >>>> [00000c40][002117c2][00000c36] 51 push ecx // push P
> >>>> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
> >>>>
> >>>> We can see that the first seven lines of P repeat. P calls H(P,P) that
> >>>> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
> >>>> stops simulating its input. When H does stop simulating its input P
> >>>> never reaches its final state of [00000c50] therefore never halts even
> >>>> though it stops running.
> >>>>
> >>>> [00000c36][0025c1f2][0025c1f6] 55 push ebp
> >>>> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
> >>>> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
> >>>> [00000c3c][0025c1ee][00000c36] 50 push eax // push P
> >>>> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
> >>>> [00000c40][0025c1ea][00000c36] 51 push ecx // push P
> >>>> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
> >>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >>>>
> >>>> [00000c68][0010172a][00000000] 83c408 add esp,+08
> >>>> [00000c6b][00101726][00000000] 50 push eax
> >>>> [00000c6c][00101722][00000357] 6857030000 push 00000357
> >>>> [00000c71][00101722][00000357] e810f7ffff call 00000386
> >>>> Input_Halts = 0
> >>>> [00000c76][0010172a][00000000] 83c408 add esp,+08
> >>>> [00000c79][0010172a][00000000] 33c0 xor eax,eax
> >>>> [00000c7b][0010172e][00100000] 5d pop ebp
> >>>> [00000c7c][00101732][00000068] c3 ret
> >>>> Number_of_User_Instructions(27)
> >>>> Number of Instructions Executed(23721)
> >>>>
> >>>> *Strachey, C 1965* An impossible program The Computer Journal, Volume
> >>>> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7..4.313
> >>>>
> >>>> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
> >>>> Lexington/Toronto: D. C. Heath and Company.
> >>>>
> >>>> --
> >>>> Copyright 2021 Pete Olcott
> >>>>
> >>>> "Great spirits have always encountered violent opposition from mediocre
> >>>> minds." Einstein
> >>
> >>
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> "Great spirits have always encountered violent opposition from mediocre
> >> minds." Einstein
>
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

On 8/14/2021 1:09 PM, wij wrote:
> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
>> On 8/14/2021 11:35 AM, wij wrote:
>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>>>> how it is called including this example:
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> P((u32)P);
>>>>>> }
>>>>>>
>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>
>>>>>> In computability theory, the halting problem is the problem of
>>>>>> determining, from a description of an arbitrary computer program
>>>>>> and an input, whether the program will finish running, or continue
>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>> to the halting problem.
>>>>>
>>>>> I do not know English well, but I (almost every programmer) am sure the halting
>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
>>>>> Submit message to the authors.
>>>>>
>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>> only correctly decide the halt status of its input. Computations that
>>>> are not inputs to the halt decider do not pertain to the halting problem.
>>>
>>> Obviously the quoted text means differently to you and almost all programmers in
>>> the world. You are addressing your own interpretation. This is OK, but the
>>> interpretation is meaningless.
>> "the description of a Turing machine M" does not mean Turing machine M.
>> If people interpret this to mean Turing machine M they are wrong.
>
> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
> are also wrong, I and almost all programmers in the world can guarantee you this.
>
> If both authors are also wrong, replying the rest message is meaningless.
> You need to submit your interpretation to Linz and the author of the wiki.
>

I think that the problem is that your English is not so good.
The Linz text and the Wiki text are correct.
Linz retired many years ago.

>>>>> If the direct invocation of P(P) is not relevant to the halting problem, then
>>>>> H can do whatever you like, therefore, meaningless if not garbage.
>>>>>
>>>> The halting problem is only concerned with an at least partial halt
>>>> decider correctly deciding whether or not its input halts, thus it can
>>>> do whatever its wants as long as it does decide the correct halt status
>>>> of its input.
>>>>
>>>
>>> int H2(Prog P) {
>>> return 0;
>>> }
>>> What is the difference of your H with H2?
>>> H2 can also correctly (at least partial) answer the halting problem, and can
>>> be verified.
>>>
>> My H has intelligence and can be verified to derive a halt status that
>> corresponds to every halting computation and can be verified to derive a
>> halt status that corresponds to that halt status of every input that it
>> determines never halts.
>>
>> H is always correct for all:
>> (a) halting computations.
>> (b) computations that it decides never halt.
>>>> In every configuration H does correctly decide that its input (P,P)
>>>> never halts. This can be verified beyond all possible doubt by the x86
>>>> execution trace of the simulation of P(P) shown below.
>>>>>> The P(P) of main() only halts because H(P,P) correctly decides that its
>>>>>> input never halts. This cause-and-effect relationship between the
>>>>>> simulated P and the executed P proves that the simulated P and the
>>>>>> executed P are distinctly different computations.
>>>>>>
>>>>>> Because they are different computations the fact that the executed P
>>>>>> halts does not contradict the fact that the simulated P never halts.
>>>>>>
>>>>>> While H remains in pure simulation mode simulating the input to H(P,P)
>>>>>> this simulated input never halts thus conclusively proving that H
>>>>>> decides this input correctly.
>>>>>>
>>>>>> Because H only acts as a pure simulator of its input until after its
>>>>>> halt status decision has been made it has no behavior that can possibly
>>>>>> effect the behavior of its input. Because of this H screens out its own
>>>>>> address range in every execution trace that it examines. This is why we
>>>>>> never see any instructions of H in any execution trace after an input
>>>>>> calls H.
>>>>>>
>>>>>> *Halting computation* is any computation that eventually reaches its own
>>>>>> final state. This criteria divides computations that halt from those
>>>>>> that merely stop running because their simulation was aborted.
>>>>>>
>>>>>> A Turing machine is said to halt whenever it reaches a configuration
>>>>>> for which δ is not defined; this is possible because δ is a partial
>>>>>> function. In fact, we will assume that no transitions are defined for
>>>>>> any final state, so the Turing machine will halt whenever it enters a
>>>>>> final state. (Linz:1990:234)
>>>>>>
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> // Strachey(1965) CPL translated to C
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [00000c36](01) 55 push ebp
>>>>>> [00000c37](02) 8bec mov ebp,esp
>>>>>> [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
>>>>>> [00000c3c](01) 50 push eax
>>>>>> [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
>>>>>> [00000c40](01) 51 push ecx
>>>>>> [00000c41](05) e820fdffff call 00000966 // call H
>>>>>> [00000c46](03) 83c408 add esp,+08
>>>>>> [00000c49](02) 85c0 test eax,eax
>>>>>> [00000c4b](02) 7402 jz 00000c4f
>>>>>> [00000c4d](02) ebfe jmp 00000c4d
>>>>>> [00000c4f](01) 5d pop ebp
>>>>>> [00000c50](01) c3 ret
>>>>>> Size in bytes:(0027) [00000c50]
>>>>>>
>>>>>> _main()
>>>>>> [00000c56](01) 55 push ebp
>>>>>> [00000c57](02) 8bec mov ebp,esp
>>>>>> [00000c59](05) 68360c0000 push 00000c36 // push P
>>>>>> [00000c5e](05) 68360c0000 push 00000c36 // push P
>>>>>> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
>>>>>> [00000c68](03) 83c408 add esp,+08
>>>>>> [00000c6b](01) 50 push eax
>>>>>> [00000c6c](05) 6857030000 push 00000357
>>>>>> [00000c71](05) e810f7ffff call 00000386
>>>>>> [00000c76](03) 83c408 add esp,+08
>>>>>> [00000c79](02) 33c0 xor eax,eax
>>>>>> [00000c7b](01) 5d pop ebp
>>>>>> [00000c7c](01) c3 ret
>>>>>> Size in bytes:(0039) [00000c7c]
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> [00000c56][0010172a][00000000] 55 push ebp
>>>>>> [00000c57][0010172a][00000000] 8bec mov ebp,esp
>>>>>> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
>>>>>> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
>>>>>> [00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
>>>>>>
>>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>>> [00000c36][002117ca][002117ce] 55 push ebp
>>>>>> [00000c37][002117ca][002117ce] 8bec mov ebp,esp
>>>>>> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
>>>>>> [00000c3c][002117c6][00000c36] 50 push eax // push P
>>>>>> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
>>>>>> [00000c40][002117c2][00000c36] 51 push ecx // push P
>>>>>> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
>>>>>>
>>>>>> We can see that the first seven lines of P repeat. P calls H(P,P) that
>>>>>> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
>>>>>> stops simulating its input. When H does stop simulating its input P
>>>>>> never reaches its final state of [00000c50] therefore never halts even
>>>>>> though it stops running.
>>>>>>
>>>>>> [00000c36][0025c1f2][0025c1f6] 55 push ebp
>>>>>> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
>>>>>> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
>>>>>> [00000c3c][0025c1ee][00000c36] 50 push eax // push P
>>>>>> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
>>>>>> [00000c40][0025c1ea][00000c36] 51 push ecx // push P
>>>>>> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>
>>>>>> [00000c68][0010172a][00000000] 83c408 add esp,+08
>>>>>> [00000c6b][00101726][00000000] 50 push eax
>>>>>> [00000c6c][00101722][00000357] 6857030000 push 00000357
>>>>>> [00000c71][00101722][00000357] e810f7ffff call 00000386
>>>>>> Input_Halts = 0
>>>>>> [00000c76][0010172a][00000000] 83c408 add esp,+08
>>>>>> [00000c79][0010172a][00000000] 33c0 xor eax,eax
>>>>>> [00000c7b][0010172e][00100000] 5d pop ebp
>>>>>> [00000c7c][00101732][00000068] c3 ret
>>>>>> Number_of_User_Instructions(27)
>>>>>> Number of Instructions Executed(23721)
>>>>>>
>>>>>> *Strachey, C 1965* An impossible program The Computer Journal, Volume
>>>>>> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>>>>>>
>>>>>> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>>
>>>>>> --
>>>>>> Copyright 2021 Pete Olcott
>>>>>>
>>>>>> "Great spirits have always encountered violent opposition from mediocre
>>>>>> minds." Einstein
>>>>
>>>>
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>>
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

On 8/14/21 1:22 PM, olcott wrote:
> On 8/14/2021 11:35 AM, wij wrote:
>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>> On 8/14/2021 11:05 AM, wij wrote:
>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>> matter
>>>>> how it is called including this example:
>>>>>
>>>>> int main()
>>>>> {
>>>>> P((u32)P);
>>>>> }
>>>>>
>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>> is: given the description of a Turing machine M and an input w,
>>>>> does M, when started in the initial configuration q0w, perform a
>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>
>>>>> In computability theory, the halting problem is the problem of
>>>>> determining, from a description of an arbitrary computer program
>>>>> and an input, whether the program will finish running, or continue
>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> Because the halting problem only requires that the (at least partial)
>>>>> halt decider decide its input correctly the fact that the direct
>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>> to the halting problem.
>>>>
>>>> I do not know English well, but I (almost every programmer) am sure
>>>> the halting
>>>> problem means a program H decides whether P(input) will halt or not.
>>>> If the quoted texts is read to you differently, it is the problem of
>>>> that texts.
>>>> Submit message to the authors.
>>>>
>>> The quoted texts are accurate. The (at least partial) halt decider must
>>> only correctly decide the halt status of its input. Computations that
>>> are not inputs to the halt decider do not pertain to the halting
>>> problem.
>>
>> Obviously the quoted text means differently to you and almost all
>> programmers in
>> the world. You are addressing your own interpretation. This is OK, but
>> the
>> interpretation is meaningless.
>
> "the description of a Turing machine M" does not mean Turing machine M.
> If people interpret this to mean Turing machine M they are wrong.

The INPUT is the description of Turing Machine M.

The answer is about the behavior of Turing Machine M, which, as pointed
out, is NOT the input.

H needs to give the correct answer on the behavior of the ACTUAL Turing
Machine, based on its analysis of H's input, which is the representation.

>
>>>> If the direct invocation of P(P) is not relevant to the halting
>>>> problem, then
>>>> H can do whatever you like, therefore, meaningless if not garbage.
>>>>
>>> The halting problem is only concerned with an at least partial halt
>>> decider correctly deciding whether or not its input halts, thus it can
>>> do whatever its wants as long as it does decide the correct halt status
>>> of its input.
>>>
>>
>> int H2(Prog P) {
>>   return 0;
>> }
>> What is the difference of your H with H2?
>> H2 can also correctly (at least partial) answer the halting problem,
>> and can
>> be verified.
>>
>
> My H has intelligence and can be verified to derive a halt status that
> corresponds to every halting computation and can be verified to derive a
> halt status that corresponds to that halt status of every input that it
> determines never halts.>

> H is always correct for all:
> (a) halting computations.
> (b) computations that it decides never halt.

But it isn't, as it claims that when given the representation of the H^
built on it, that this machine H^ is non-halting when given the input of
the representation of this same H^, while even YOU admit that when you
actually run this H^ machine and give it that input it Halts.

Thus, it is clear that the input to H is the representation of a Halting
Computation, but it decides that it is non-halting, thus it is wrong.

On 8/14/2021 12:10 PM, Richard Damon wrote:
> On 8/14/21 12:16 PM, olcott wrote:
>> On 8/14/2021 11:05 AM, wij wrote:
>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>> how it is called including this example:
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> the Turing machine halting problem. Simply stated, the problem
>>>> is: given the description of a Turing machine M and an input w,
>>>> does M, when started in the initial configuration q0w, perform a
>>>> computation that eventually halts? (Linz:1990:317).
>>>>
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program
>>>> and an input, whether the program will finish running, or continue
>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> Because the halting problem only requires that the (at least partial)
>>>> halt decider decide its input correctly the fact that the direct
>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>> to the halting problem.
>>>   I do not know English well, but I (almost every programmer) am sure
>>> the halting
>>> problem means a program H decides whether P(input) will halt or not.
>>> If the quoted texts is read to you differently, it is the problem of
>>> that texts.
>>> Submit message to the authors.
>>>
>>
>> The quoted texts are accurate. The (at least partial) halt decider must
>> only correctly decide the halt status of its input. Computations that
>> are not inputs to the halt decider do not pertain to the halting problem.
>>
>
> This is the point where you use of English is incorrect, and you need to
> restudy English so you understand what you are saying.
>
> *Inputs* are NEVER *Computations* in and of themselves, but are merely
> the string representations of the ACTUAL Computations.
>
> As such, 'inputs' don't halt or be non-halting, only the machines they
> represent.
The input "description of an arbitrary computer program" is the basis
for the halt status decision.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/14/2021 1:32 PM, Richard Damon wrote:
> On 8/14/21 1:22 PM, olcott wrote:
>> On 8/14/2021 11:35 AM, wij wrote:
>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>>> matter
>>>>>> how it is called including this example:
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> P((u32)P);
>>>>>> }
>>>>>>
>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>
>>>>>> In computability theory, the halting problem is the problem of
>>>>>> determining, from a description of an arbitrary computer program
>>>>>> and an input, whether the program will finish running, or continue
>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>> to the halting problem.
>>>>>
>>>>> I do not know English well, but I (almost every programmer) am sure
>>>>> the halting
>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>> If the quoted texts is read to you differently, it is the problem of
>>>>> that texts.
>>>>> Submit message to the authors.
>>>>>
>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>> only correctly decide the halt status of its input. Computations that
>>>> are not inputs to the halt decider do not pertain to the halting
>>>> problem.
>>>
>>> Obviously the quoted text means differently to you and almost all
>>> programmers in
>>> the world. You are addressing your own interpretation. This is OK, but
>>> the
>>> interpretation is meaningless.
>>
>> "the description of a Turing machine M" does not mean Turing machine M.
>> If people interpret this to mean Turing machine M they are wrong.
>
> The INPUT is the description of Turing Machine M.
>
> The answer is about the behavior of Turing Machine M, which, as pointed
> out, is NOT the input.
>

The answer is about the behavior of Turing Machine M corresponding to
the input. The answer is not about some other Turing machine M that is
in some other different point in the execution trace.

Another way to say this is that answer is about the behavior of the pure
simulation of the input on its input.

It is easily verified that

While H remains in pure simulation mode simulating the input to H(P,P)
this simulated input never stops running halts thus conclusively proving
that H decides this input correctly.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/14/21 2:44 PM, olcott wrote:
> On 8/14/2021 1:32 PM, Richard Damon wrote:
>> On 8/14/21 1:22 PM, olcott wrote:
>>> On 8/14/2021 11:35 AM, wij wrote:
>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>>>> matter
>>>>>>> how it is called including this example:
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> P((u32)P);
>>>>>>> }
>>>>>>>
>>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>>
>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>> and an input, whether the program will finish running, or continue
>>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> Because the halting problem only requires that the (at least
>>>>>>> partial)
>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>> invocation of P(P) is not an input to H, means that it is not
>>>>>>> relevant
>>>>>>> to the halting problem.
>>>>>>
>>>>>> I do not know English well, but I (almost every programmer) am sure
>>>>>> the halting
>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>> If the quoted texts is read to you differently, it is the problem of
>>>>>> that texts.
>>>>>> Submit message to the authors.
>>>>>>
>>>>> The quoted texts are accurate. The (at least partial) halt decider
>>>>> must
>>>>> only correctly decide the halt status of its input. Computations that
>>>>> are not inputs to the halt decider do not pertain to the halting
>>>>> problem.
>>>>
>>>> Obviously the quoted text means differently to you and almost all
>>>> programmers in
>>>> the world. You are addressing your own interpretation. This is OK, but
>>>> the
>>>> interpretation is meaningless.
>>>
>>> "the description of a Turing machine M" does not mean Turing machine M.
>>> If people interpret this to mean Turing machine M they are wrong.
>>
>> The INPUT is the description of Turing Machine M.
>>
>> The answer is about the behavior of Turing Machine M, which, as pointed
>> out, is NOT the input.
>>
>
> The answer is about the behavior of Turing Machine M corresponding to
> the input. The answer is not about some other Turing machine M that is
> in some other different point in the execution trace.
>
> Another way to say this is that answer is about the behavior of the pure
> simulation of the input on its input.

Right, so what H^ (to use its real name) when given as an input the
description of H^ and run as the actual machine or by a pure simulator
that NEVER halts its simulation

It has been shown that H^(<H^>) is a Halting computation. You even agree
to it, but keep on trying to say it doesn't matter because that H^ isn't
the input to H, only its representation.

THAT is the machine that is being given to H as a representation, so
THAT is the machine whose behavior it is supposed to predict.

H^(<H^>) is Halting

UTM(<H^>, <H^>) is Halting.

>
> It is easily verified that
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never stops running halts thus conclusively proving
> that H decides this input correctly.
>

But since H ISN'T a pure simulator, only a 'pure simulator until', the
fact that before it stopped simulating it didn't the end proves
absolutely nothing.

UNSOUND logic, disproven.

All you have shown from your trace of H(<H^>,<H^>) is that H^(<H^>)
doesn't stop in 27 or 23721 steps (depending on what number you want to
use) while from your published trace of H^(<H^>) that shows it halting,
it did so in 39 or 26567 steps, so the issue is that H just didn't
simulate long enough.

Just remember, if you change the H that H^ is built on to simulate
longer, then those numbers will change.

All you have 'proved' is that 27 < 39, which doesn't mean a lot.

On 8/14/21 2:33 PM, olcott wrote:
> On 8/14/2021 12:10 PM, Richard Damon wrote:
>> On 8/14/21 12:16 PM, olcott wrote:
>>> On 8/14/2021 11:05 AM, wij wrote:
>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>> matter
>>>>> how it is called including this example:
>>>>>
>>>>> int main()
>>>>> {
>>>>> P((u32)P);
>>>>> }
>>>>>
>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>> is: given the description of a Turing machine M and an input w,
>>>>> does M, when started in the initial configuration q0w, perform a
>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>
>>>>> In computability theory, the halting problem is the problem of
>>>>> determining, from a description of an arbitrary computer program
>>>>> and an input, whether the program will finish running, or continue
>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> Because the halting problem only requires that the (at least partial)
>>>>> halt decider decide its input correctly the fact that the direct
>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>> to the halting problem.
>>>>    I do not know English well, but I (almost every programmer) am sure
>>>> the halting
>>>> problem means a program H decides whether P(input) will halt or not.
>>>> If the quoted texts is read to you differently, it is the problem of
>>>> that texts.
>>>> Submit message to the authors.
>>>>
>>>
>>> The quoted texts are accurate. The (at least partial) halt decider must
>>> only correctly decide the halt status of its input. Computations that
>>> are not inputs to the halt decider do not pertain to the halting
>>> problem.
>>>
>>
>> This is the point where you use of English is incorrect, and you need to
>> restudy English so you understand what you are saying.
>>
>> *Inputs* are NEVER *Computations* in and of themselves, but are merely
>> the string representations of the ACTUAL Computations.
>>
>> As such, 'inputs' don't halt or be non-halting, only the machines they
>> represent.
> The input "description of an arbitrary computer program" is the basis
> for the halt status decision.
>
>

The input is what the program uses to make its decision, the right
answer is what the actual machine does.

You don't seem to understand the difference.

The program uses unsound logic in its analysis and thus gets a wrong
answer. (It assumes that H will NEVER abort, when it just is a won't
abort until type of program). Until is not Never, so it get the answer
wrong.

olcott <NoOne@NoWhere.com> writes:

> The P(P) of main() only halts because...

As you say, P(P) halts.

> *Halting computation* is any computation that eventually reaches its
> own final state. This criteria divides computations that halt from
> those that merely stop running because their simulation was aborted.

No. There is no "special kind of halting". The computation M(I) either
halts or it does not. H(M, I) should be false if, and only if, M(I)
does not halt.

> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }

P(P) halts, yet H(P, P) is false. That's the wrong answer.

Why are you still hiding H? Is it because you have still not figured
out how to nest a call to the simulator you are using? Fortunately "we"
(i.e. everyone but you) can see that H is wrong without even seeing the
code. Who is included in the "we" of the subject line? Have you found
someone else who thinks that false is the correct return from a partial
halt decider called with arguments that represent a halting computation?

--
Ben.

On 8/14/2021 3:39 PM, Richard Damon wrote:
> On 8/14/21 2:33 PM, olcott wrote:
>> On 8/14/2021 12:10 PM, Richard Damon wrote:
>>> On 8/14/21 12:16 PM, olcott wrote:
>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>>> matter
>>>>>> how it is called including this example:
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> P((u32)P);
>>>>>> }
>>>>>>
>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>
>>>>>> In computability theory, the halting problem is the problem of
>>>>>> determining, from a description of an arbitrary computer program
>>>>>> and an input, whether the program will finish running, or continue
>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>> to the halting problem.
>>>>>    I do not know English well, but I (almost every programmer) am sure
>>>>> the halting
>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>> If the quoted texts is read to you differently, it is the problem of
>>>>> that texts.
>>>>> Submit message to the authors.
>>>>>
>>>>
>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>> only correctly decide the halt status of its input. Computations that
>>>> are not inputs to the halt decider do not pertain to the halting
>>>> problem.
>>>>
>>>
>>> This is the point where you use of English is incorrect, and you need to
>>> restudy English so you understand what you are saying.
>>>
>>> *Inputs* are NEVER *Computations* in and of themselves, but are merely
>>> the string representations of the ACTUAL Computations.
>>>
>>> As such, 'inputs' don't halt or be non-halting, only the machines they
>>> represent.
>> The input "description of an arbitrary computer program" is the basis
>> for the halt status decision.
>>
>>
>
> The input is what the program uses to make its decision, the right
> answer is what the actual machine does.
>

Because the input to H(P,P) is at a different point int the execution
trace than the P of int main(){ P(P); } it is a different computation
having different behavior than the input to H(P,P).

If we are not damn liars and know the x86 language sufficiently well
enough then we can see that the simulation of the input to H precisely
matches the x86 source-code of P on input P therefore the pure
simulation of P on input P is perfectly correct.

Damn liars that know the x86 language well enough can see this too.

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H(P,P)
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

> You don't seem to understand the difference.
>
> The program uses unsound logic in its analysis and thus gets a wrong
> answer. (It assumes that H will NEVER abort, when it just is a won't
> abort until type of program). Until is not Never, so it get the answer
> wrong.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/14/21 4:52 PM, olcott wrote:
> On 8/14/2021 3:39 PM, Richard Damon wrote:
>> On 8/14/21 2:33 PM, olcott wrote:
>>> On 8/14/2021 12:10 PM, Richard Damon wrote:
>>>> On 8/14/21 12:16 PM, olcott wrote:
>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>>>> matter
>>>>>>> how it is called including this example:
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> P((u32)P);
>>>>>>> }
>>>>>>>
>>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>>
>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>> and an input, whether the program will finish running, or continue
>>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> Because the halting problem only requires that the (at least
>>>>>>> partial)
>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>> invocation of P(P) is not an input to H, means that it is not
>>>>>>> relevant
>>>>>>> to the halting problem.
>>>>>>     I do not know English well, but I (almost every programmer) am
>>>>>> sure
>>>>>> the halting
>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>> If the quoted texts is read to you differently, it is the problem of
>>>>>> that texts.
>>>>>> Submit message to the authors.
>>>>>>
>>>>>
>>>>> The quoted texts are accurate. The (at least partial) halt decider
>>>>> must
>>>>> only correctly decide the halt status of its input. Computations that
>>>>> are not inputs to the halt decider do not pertain to the halting
>>>>> problem.
>>>>>
>>>>
>>>> This is the point where you use of English is incorrect, and you
>>>> need to
>>>> restudy English so you understand what you are saying.
>>>>
>>>> *Inputs* are NEVER *Computations* in and of themselves, but are merely
>>>> the string representations of the ACTUAL Computations.
>>>>
>>>> As such, 'inputs' don't halt or be non-halting, only the machines they
>>>> represent.
>>> The input "description of an arbitrary computer program" is the basis
>>> for the halt status decision.
>>>
>>>
>>
>> The input is what the program uses to make its decision, the right
>> answer is what the actual machine does.
>>
>
> Because the input to H(P,P) is at a different point int the execution
> trace than the P of int main(){ P(P); } it is a different computation
> having different behavior than the input to H(P,P).

What 'point'. The question is will the computation finish or not.

The fact that the simulation of H^(<H^>) that H is doing hasn't reached
the final halting state, that it would if continued, does not mean it is
non-halting.

>
> If we are not damn liars and know the x86 language sufficiently well
> enough then we can see that the simulation of the input to H precisely
> matches the x86 source-code of P on input P therefore the pure
> simulation of P on input P is perfectly correct.

YOU show you don't understand x86 assembly.

call 00000966 should be followed by the instruction at location 00000966
being executed, but the trace does not do that. Thus the trace is WRONG.

FAIL. LIAR.

You will then say that it is the equivalent trace, but that
transformation only appies to simulator that NEVER abort, not don't
abort until they decide. UNSOUND LOGIC, FAIL.

Please look at basic first year class materials in these subjects to see
the right answers.

Heck, I suspect most High School Students could understand it with just
a bit of study.

>
> Damn liars that know the x86 language well enough can see this too.
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H(P,P)
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>
>> You don't seem to understand the difference.
>>
>> The program uses unsound logic in its analysis and thus gets a wrong
>> answer. (It assumes that H will NEVER abort, when it just is a won't
>> abort until type of program). Until is not Never, so it get the answer
>> wrong.
>>
>
>

On 8/14/2021 3:43 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The P(P) of main() only halts because...
>
> As you say, P(P) halts.
>
>> *Halting computation* is any computation that eventually reaches its
>> own final state. This criteria divides computations that halt from
>> those that merely stop running because their simulation was aborted.
>
> No. There is no "special kind of halting". The computation M(I) either
> halts or it does not. H(M, I) should be false if, and only if, M(I)
> does not halt.
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>
> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>

Because the input to H(P,P) is at a different point in the execution
trace than the P of int main(){ P(P); } it is a different computation
having different behavior than the input to H(P,P).

> Why are you still hiding H? Is it because you have still not figured
> out how to nest a call to the simulator you are using?

That part alone took me three months after all the rest of the x86utm
operating system was complete.

If people can't begin to understand that seven lines of x86 code of P
are stuck in infinitely nested simulation while H remains in pure
simulator mode after many months of discussion then adding the much more
complexity of the details of how simulation works is not going to help
their understanding.

All they really need to know is that infinitely nested simulation has
computationally equivalent halting behavior to infinite recursion.

Also I want to keep this in reserve as totally unpublished work so that
a publisher will have some key material that has never been previously
disclosed.

> Fortunately "we"
> (i.e. everyone but you) can see that H is wrong without even seeing the
> code. Who is included in the "we" of the subject line? Have you found
> someone else who thinks that false is the correct return from a partial
> halt decider called with arguments that represent a halting computation?
>

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

If you can "see" how P is able to break out of its infinitely nested
simulation while H remains in pure simulator mode please feel free to
share.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/14/2021 4:06 PM, Richard Damon wrote:
> On 8/14/21 4:52 PM, olcott wrote:
>> On 8/14/2021 3:39 PM, Richard Damon wrote:
>>> On 8/14/21 2:33 PM, olcott wrote:
>>>> On 8/14/2021 12:10 PM, Richard Damon wrote:
>>>>> On 8/14/21 12:16 PM, olcott wrote:
>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>>>>> matter
>>>>>>>> how it is called including this example:
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> P((u32)P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>>>
>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>>> and an input, whether the program will finish running, or continue
>>>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>> Because the halting problem only requires that the (at least
>>>>>>>> partial)
>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>> invocation of P(P) is not an input to H, means that it is not
>>>>>>>> relevant
>>>>>>>> to the halting problem.
>>>>>>>     I do not know English well, but I (almost every programmer) am
>>>>>>> sure
>>>>>>> the halting
>>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>>> If the quoted texts is read to you differently, it is the problem of
>>>>>>> that texts.
>>>>>>> Submit message to the authors.
>>>>>>>
>>>>>>
>>>>>> The quoted texts are accurate. The (at least partial) halt decider
>>>>>> must
>>>>>> only correctly decide the halt status of its input. Computations that
>>>>>> are not inputs to the halt decider do not pertain to the halting
>>>>>> problem.
>>>>>>
>>>>>
>>>>> This is the point where you use of English is incorrect, and you
>>>>> need to
>>>>> restudy English so you understand what you are saying.
>>>>>
>>>>> *Inputs* are NEVER *Computations* in and of themselves, but are merely
>>>>> the string representations of the ACTUAL Computations.
>>>>>
>>>>> As such, 'inputs' don't halt or be non-halting, only the machines they
>>>>> represent.
>>>> The input "description of an arbitrary computer program" is the basis
>>>> for the halt status decision.
>>>>
>>>>
>>>
>>> The input is what the program uses to make its decision, the right
>>> answer is what the actual machine does.
>>>
>>
>> Because the input to H(P,P) is at a different point int the execution
>> trace than the P of int main(){ P(P); } it is a different computation
>> having different behavior than the input to H(P,P).
>
> What 'point'. The question is will the computation finish or not.
>
When trying to prove that I do not own a white cat, proof that I do not
own a black dog does not count.

The two distinctly different computations have different halting behavior.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The P(P) of main() only halts because...
>
> As you say, P(P) halts.
>
>> *Halting computation* is any computation that eventually reaches its
>> own final state. This criteria divides computations that halt from
>> those that merely stop running because their simulation was aborted.
>
> No. There is no "special kind of halting". The computation M(I) either
> halts or it does not. H(M, I) should be false if, and only if, M(I)
> does not halt.
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>
> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>
> Why are you still hiding H? Is it because you have still not figured
> out how to nest a call to the simulator you are using? Fortunately "we"
> (i.e. everyone but you) can see that H is wrong without even seeing the
> code. Who is included in the "we" of the subject line? Have you found
> someone else who thinks that false is the correct return from a partial
> halt decider called with arguments that represent a halting computation?

I have questions about the PO simulator I hope someone can answer. It
perhaps concerns memory mapping: First - is every instance of a use at
different levels in its own address space? Second - if not, is there any
way to know when an address is reported, which simulator instance is
being reported on? When the dumb bunny (PO expression) notes that the
same address is reached a second time without a conditional branch being
executed, is there any assurance that the addresses are noted from the
same instance of the simulation? And finally, how can one determine if
it's the same address twice without doing some sort of compare and
branch? Thanks in advance for any sort of enlightenment.
--
Jeff Barnett

On 8/14/2021 4:20 PM, Jeff Barnett wrote:
> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The P(P) of main() only halts because...
>>
>> As you say, P(P) halts.
>>
>>> *Halting computation* is any computation that eventually reaches its
>>> own final state. This criteria divides computations that halt from
>>> those that merely stop running because their simulation was aborted.
>>
>> No.  There is no "special kind of halting".  The computation M(I) either
>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>> does not halt.
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>
>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>
>> Why are you still hiding H?  Is it because you have still not figured
>> out how to nest a call to the simulator you are using?  Fortunately "we"
>> (i.e. everyone but you) can see that H is wrong without even seeing the
>> code.  Who is included in the "we" of the subject line?  Have you found
>> someone else who thinks that false is the correct return from a partial
>> halt decider called with arguments that represent a halting computation?
>
> I have questions about the PO simulator I hope someone can answer. It
> perhaps concerns memory mapping: First - is every instance of a use at
> different levels in its own address space? Second - if not, is there any
> way to know when an address is reported, which simulator instance is
> being reported on? When the dumb bunny (PO expression) notes that the
> same address is reached a second time without a conditional branch being
> executed, is there any assurance that the addresses are noted from the
> same instance of the simulation? And finally, how can one determine if
> it's the same address twice without doing some sort of compare and
> branch? Thanks in advance for any sort of enlightenment.

Infinitely nested simulation is merely a more complex case of infinite
recursion in both cases the exact same machine code is executed.

I don't want to get into the details of the differences until after most
everyone here totally understands that these seven lines of P will
continue to repeat while H remains in pure simulation mode.

That no one here has been able to understand seven simple lines of x86
code after many months of dialogue sufficiently proves that additional
details would be utterly overwhelming for them.

[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/14/21 5:09 PM, olcott wrote:
> On 8/14/2021 4:06 PM, Richard Damon wrote:
>> On 8/14/21 4:52 PM, olcott wrote:
>>> On 8/14/2021 3:39 PM, Richard Damon wrote:
>>>> On 8/14/21 2:33 PM, olcott wrote:
>>>>> On 8/14/2021 12:10 PM, Richard Damon wrote:
>>>>>> On 8/14/21 12:16 PM, olcott wrote:
>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no
>>>>>>>>> matter
>>>>>>>>> how it is called including this example:
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> P((u32)P);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>>>>
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>>>> and an input, whether the program will finish running, or continue
>>>>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>
>>>>>>>>> Because the halting problem only requires that the (at least
>>>>>>>>> partial)
>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>> invocation of P(P) is not an input to H, means that it is not
>>>>>>>>> relevant
>>>>>>>>> to the halting problem.
>>>>>>>>      I do not know English well, but I (almost every programmer) am
>>>>>>>> sure
>>>>>>>> the halting
>>>>>>>> problem means a program H decides whether P(input) will halt or
>>>>>>>> not.
>>>>>>>> If the quoted texts is read to you differently, it is the
>>>>>>>> problem of
>>>>>>>> that texts.
>>>>>>>> Submit message to the authors.
>>>>>>>>
>>>>>>>
>>>>>>> The quoted texts are accurate. The (at least partial) halt decider
>>>>>>> must
>>>>>>> only correctly decide the halt status of its input. Computations
>>>>>>> that
>>>>>>> are not inputs to the halt decider do not pertain to the halting
>>>>>>> problem.
>>>>>>>
>>>>>>
>>>>>> This is the point where you use of English is incorrect, and you
>>>>>> need to
>>>>>> restudy English so you understand what you are saying.
>>>>>>
>>>>>> *Inputs* are NEVER *Computations* in and of themselves, but are
>>>>>> merely
>>>>>> the string representations of the ACTUAL Computations.
>>>>>>
>>>>>> As such, 'inputs' don't halt or be non-halting, only the machines
>>>>>> they
>>>>>> represent.
>>>>> The input "description of an arbitrary computer program" is the basis
>>>>> for the halt status decision.
>>>>>
>>>>>
>>>>
>>>> The input is what the program uses to make its decision, the right
>>>> answer is what the actual machine does.
>>>>
>>>
>>> Because the input to H(P,P) is at a different point int the execution
>>> trace than the P of int main(){ P(P); } it is a different computation
>>> having different behavior than the input to H(P,P).
>>
>> What 'point'. The question is will the computation finish or not.
>>
> When trying to prove that I do not own a white cat, proof that I do not
> own a black dog does not count.
>
> The two distinctly different computations have different halting behavior.
>

Right, so we want to know what the Turing Machine that the input is a
representation of does, i.e., what does the ACTUAL machine H^(<H^>)
does, which is Halt.

It doesn't matter that the partial simulation that H did of the machine
never reached its final halting state because H stop simulating it
before it gets there.

YOU are the one looking at the black dog when the question is about the
white cat.

The decider H is asked what will the machine H^(<H^>) will do, as
specified by its input <H^> <H^>.

We know that the actual machine H^(<H^>) Halts, so the right answer is Halt.

We know that H will reply non-halting

Thus we know that it is wrong.

We know it is wrong because it is based on unsound logic presuming that
H is a pure simulator, when it is a simulator that will decide to abort,
and thus its logic has a false premise as an input.

The fact that H only partially simulates its simulation of <H^> <H^>
doesn't actually prove anything, except that it didn't simulate to the
point of actually proving anything, and thus it had to just guess, and
it guesses wrong.

On 8/14/21 5:06 PM, olcott wrote:
> On 8/14/2021 3:43 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The P(P) of main() only halts because...
>>
>> As you say, P(P) halts.
>>
>>> *Halting computation* is any computation that eventually reaches its
>>> own final state. This criteria divides computations that halt from
>>> those that merely stop running because their simulation was aborted.
>>
>> No.  There is no "special kind of halting".  The computation M(I) either
>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>> does not halt.
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>
>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>
>
> Because the input to H(P,P) is at a different point in the execution
> trace than the P of int main(){ P(P); } it is a different computation
> having different behavior than the input to H(P,P).

THAT IS UTTER NONSENSE.

The question is where does it end up, not where is it as some point in
'time'

H^ (aks P) WILL Halt when run to completion. The fact that H doesn't get
there just means it didn't finish the job.

>
>> Why are you still hiding H?  Is it because you have still not figured
>> out how to nest a call to the simulator you are using? 
>
> That part alone took me three months after all the rest of the x86utm
> operating system was complete.
>
> If people can't begin to understand that seven lines of x86 code of P
> are stuck in infinitely nested simulation while H remains in pure
> simulator mode after many months of discussion then adding the much more
> complexity of the details of how simulation works is not going to help
> their understanding.

But H will stop being a pure simulator, and all the logic based on it
being a pure simulator needs to be thrown out. H is NOT a pure
simulator. PERIOD. NEVER means NEVER, and any H that answers H(P,P) will
abort its simulation and thus fail to be a simulator that NEVER aborts
its simulation.

>
> All they really need to know is that infinitely nested simulation has
> computationally equivalent halting behavior to infinite recursion.

And you fail to see that a simulation that WILL be aborted in finite
time is not infinitely nested.

>
> Also I want to keep this in reserve as totally unpublished work so that
> a publisher will have some key material that has never been previously
> disclosed.

YOU WILL NEVER GET THERE.

>
>> Fortunately "we"
>> (i.e. everyone but you) can see that H is wrong without even seeing the
>> code.  Who is included in the "we" of the subject line?  Have you found
>> someone else who thinks that false is the correct return from a partial
>> halt decider called with arguments that represent a halting computation?
>>
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> If you can "see" how P is able to break out of its infinitely nested
> simulation while H remains in pure simulator mode please feel free to
> share.
>

On 8/14/21 5:40 PM, olcott wrote:
> On 8/14/2021 4:20 PM, Jeff Barnett wrote:
>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The P(P) of main() only halts because...
>>>
>>> As you say, P(P) halts.
>>>
>>>> *Halting computation* is any computation that eventually reaches its
>>>> own final state. This criteria divides computations that halt from
>>>> those that merely stop running because their simulation was aborted.
>>>
>>> No.  There is no "special kind of halting".  The computation M(I) either
>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>> does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>
>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>
>>> Why are you still hiding H?  Is it because you have still not figured
>>> out how to nest a call to the simulator you are using?  Fortunately "we"
>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>> code.  Who is included in the "we" of the subject line?  Have you found
>>> someone else who thinks that false is the correct return from a partial
>>> halt decider called with arguments that represent a halting computation?
>>
>> I have questions about the PO simulator I hope someone can answer. It
>> perhaps concerns memory mapping: First - is every instance of a use at
>> different levels in its own address space? Second - if not, is there
>> any way to know when an address is reported, which simulator instance
>> is being reported on? When the dumb bunny (PO expression) notes that
>> the same address is reached a second time without a conditional branch
>> being executed, is there any assurance that the addresses are noted
>> from the same instance of the simulation? And finally, how can one
>> determine if it's the same address twice without doing some sort of
>> compare and branch? Thanks in advance for any sort of enlightenment.
>
> Infinitely nested simulation is merely a more complex case of infinite
> recursion in both cases the exact same machine code is executed.
>
> I don't want to get into the details of the differences until after most
> everyone here totally understands that these seven lines of P will
> continue to repeat while H remains in pure simulation mode.

And will stop when H leaves that mode, so if we look at a simulation
with P (or H^) as the top level machine, we see that P will halt.

>
> That no one here has been able to understand seven simple lines of x86
> code after many months of dialogue sufficiently proves that additional
> details would be utterly overwhelming for them.

YOU don't seem to understand that calls to routines need to be traced
and evalutated, and that eventually aborting simulations are not pure
simulations.

>
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>