Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Error in operator: add beer


computers / comp.ai.philosophy / Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

SubjectAuthor
* How do we know H(P,P)==0 is the correct halt status for the input toolcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
|+* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||`- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
|`* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
| `* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|  `- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|+- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (posolcott
|+* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||`* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|| +- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ doolcott
|| `* Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||  +- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||  `* Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||   `* Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||    `* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||     `- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ coolcott
`- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott

Pages:12
How do we know H(P,P)==0 is the correct halt status for the input to H?

<3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7247&group=comp.ai.philosophy#7247

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 10:17:56 -0500
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
X-Mozilla-News-Host: news://news.giganews.com:119
From: NoO...@NoWhere.com (olcott)
Subject: How do we know H(P,P)==0 is the correct halt status for the input to
H?
Date: Sat, 14 Aug 2021 10:17:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
Lines: 153
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FK1Pzg2Mz0VrPtX/0qVtMpQlcD22DSftM9gLXzCInquEaWgZL5srkbTbFaLQe7kDT460ZiukhZHITUU!EQxyOtYVgf6Pgnb2t5eNilw/rP7pPucpSBuukuyie2C1AfpZaLxiqyXPy7gr0W6Tda6cTvWusw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7827
 by: olcott - Sat, 14 Aug 2021 15:17 UTC

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<fsCdnXYYguTAe4r8nZ2dnUU7-QHNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7248&group=comp.ai.philosophy#7248

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 10:50:53 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 10:50:52 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <fsCdnXYYguTAe4r8nZ2dnUU7-QHNnZ2d@giganews.com>
Lines: 157
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FGcVK01s2+tp83VtZoXCn68HQ6tR850E1YCwwBnJ+u9oJ1/NF7MRj7kEoX073ip3hL39W3gW+D9v+ym!G7Kw+thuOtEv+q2xv662gLd+pUN1R16i5ZMppdHb8w9KFPQC2WzGpIU4hHhx8Tl/GOYQ9n/Tag==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8695
 by: olcott - Sat, 14 Aug 2021 15:50 UTC

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7249&group=comp.ai.philosophy#7249

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 11:16:12 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 11:16:11 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
Lines: 185
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-PzyRd17aUCv0wdpVqK+CyHO00uiyUPhHdBmRKfkUe+fCwZE4+ZzE3STFmuA4anGq27YnQqeRQvf+QkS!lt0/2QN1D9KCWqTcSyXeiGlRlnm2u2w1Da1o6tn1td2nc6iYbURhJdVHMfC+y+r/YsXymzILhQ==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 9236
 by: olcott - Sat, 14 Aug 2021 16:16 UTC

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7250&group=comp.ai.philosophy#7250

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 12:22:03 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 12:22:02 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
Lines: 216
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rNeRxYzOT+CaHdG+UOQYU2SNazFUPQSzcxdYXcPHmSWN4RpsbvoRmItqMzf/vHIhYpYtUxT+drWWl1P!E0ilgTsksM6717+50dAyMbrdYz0gGQZ2i7+fARdvVf0zQWAwwKcZB1/kb2ZCuAgbAdmpuGsOHg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 10818
 by: olcott - Sat, 14 Aug 2021 17:22 UTC

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


Click here to read the complete article
Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<YJCdnQKMFYdlk4X8nZ2dnUU7-UmdnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7252&group=comp.ai.philosophy#7252

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 13:44:08 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com> <p%TRI.22185$6p.354@fx36.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 13:44:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <p%TRI.22185$6p.354@fx36.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <YJCdnQKMFYdlk4X8nZ2dnUU7-UmdnZ2d@giganews.com>
Lines: 76
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-k2ZGvsdjI3Ttv3GPNOsgmPew2AIlYgLtiDejhQ8EYvJ3BdUXV9RHpJn8QeEo14CDAVbF1z7rRCX+FyC!TI1bToNdcYct8EFsUQcyTwcatxVJp4f+zThvPVElgKtfEWMxWS7HO4n2Zt2uvkKM973XO+RpWg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4626
 by: olcott - Sat, 14 Aug 2021 18:44 UTC

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<mOmdnayK5blhsYX8nZ2dnUU7-cHNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7254&group=comp.ai.philosophy#7254

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 15:52:12 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com> <vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com> <sf8te8$dek$1@dont-email.me> <j6adne7DWZT5kYX8nZ2dnUU7-QPNnZ2d@giganews.com> <CSVRI.10013$cd2.558@fx02.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 15:52:11 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CSVRI.10013$cd2.558@fx02.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <mOmdnayK5blhsYX8nZ2dnUU7-cHNnZ2d@giganews.com>
Lines: 125
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Ha6ZuRpm+Nv76hpQiX5y7nV2gY13PgR67nDebTtPVDwkoUli6nnAlWCFiD+8kL1htjFVF0VKLPNkqFb!P4T+3GI72pa6WAJhtpqN65w7d1FWuc5srodzAqYZ1ZCNxY1ikmpFDIoY+gVzsyIeE02sv4MObw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6834
 by: olcott - Sat, 14 Aug 2021 20:52 UTC

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<qomdnZRgV6jDrYX8nZ2dnUU7-afNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7255&group=comp.ai.philosophy#7255

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 16:06:38 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87eeavycxg.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 16:06:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87eeavycxg.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <qomdnZRgV6jDrYX8nZ2dnUU7-afNnZ2d@giganews.com>
Lines: 99
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CMVQiS8w6lvHrugHKk2L+mPoomKSW8tT50grRHIFB+J+a+O1cMONDDzE5mbA7xB7FXUvJodf8zBxkys!hTt5RetVVHadfqqMbKwNvZYp4x9GD2+hrQz3ewQEDxZ4xKDEcbYt1hUsFX/Hcy3qaZOjW8Vs/g==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5367
 by: olcott - Sat, 14 Aug 2021 21:06 UTC

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<5-SdnZxO38vdhYT8nZ2dnUU7-cXNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7256&group=comp.ai.philosophy#7256

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 08:36:00 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <878s13y6s1.fsf@bsb.me.uk> <X7CdnT1zg-76B4X8nZ2dnUU7-KvNnZ2d@giganews.com> <8a5e61e9-cea5-4447-8da6-688e30795ee2n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 08:36:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <8a5e61e9-cea5-4447-8da6-688e30795ee2n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <5-SdnZxO38vdhYT8nZ2dnUU7-cXNnZ2d@giganews.com>
Lines: 130
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-VTkvo1xv76Kk225ZX0nPVtJwKSMfphb5ddmZYIywfijfgKKghKf28vLl3O1vOgGSwxITKnXuEHjnhe+!324VjX9ju6X0XfH5otEH+SJ70vkJcGsAEn1F4C//SbxUaXjOlVslMmpIihviGlO8xDZX2aOsqmig!tE0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7725
X-Received-Bytes: 7946
 by: olcott - Sun, 15 Aug 2021 13:36 UTC

On 8/15/2021 4:39 AM, Malcolm McLean wrote:
> On Sunday, 15 August 2021 at 05:39:10 UTC+1, olcott wrote:
>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>> Jeff Barnett <j...@notatt.com> writes:
>>>
>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@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.
>>>
>>> You won't get a straight answer from PO, but I don't think there is any
>>> nested simulation happening at all. PO "knows" it's that same a
>>> recursion, so he just has recursive calls traced from "outside". I may
>> No this is not possible. There is no possible way to use ordinary
>> recursion to implement nested x86 emulation without memory corruption of
>> the stack. I explained all of the technical details of context
>> switching: Here is a link that does a better job:
>>
>> https://en.wikipedia.org/wiki/Context_switch
>>
>> Each virtual machine has its own registers, stack and RAM. Once the
>> virtual machine environment is set up, allocating the stack and RAM and
>> other house keeping functions a context switch only requires saving and
>> restoring all the machine registers.
>>
> We can write a ZX81 emulator on a modern machine. A ZX81 has 4K ROM
> and 1K RAM. So our first line can be a "virualmem = malloc(1024 * 5). We then
> set up everything else in that memory space.
> However the ZX81 emulator cannot emulate another ZX81, since it has only
> 1K RAM to play with, and the virtual machine needs 5K.
> You'll get this problem whenever you try to allow nested emulation on a
> random-access memory model machine.
>
> Turing machines don't have this problem. Write a UTM, and a "Hello world"
> program, and
> UTM<Hello> with output "Hello world" on the tape.
> UTM<UTM><Hello> will also output "Hello world" on the tape. You can stack up
> as many UTMs as you like without any reprogramming. It might get very slow,
> but it will eventually finish.
>
> What you can do is treat memory allocation as a special function. Then you
> can nest simulations.
>

Yes I do that.
It does not require knowing any of those details to see how totally
blatantly obvious it is that:

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

_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]

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

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7257&group=comp.ai.philosophy#7257

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 11:44:35 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 11:44:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
Lines: 413
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-UwbHOWQGUCYOE/uKoi1fIYV80xTbIO59EJNG6yJe5fOWdHyPsQQaDpspVqlWhM/4guFdlsWGvqOfnoG!tY5mPGaxbBgz5ZJD0E1+MtvKZL4USuyODm3qhdL33U07kDEcglDtvXHLHEO/h4pm5KjzVqV6aCiE!jAE=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 20939
X-Received-Bytes: 21121
 by: olcott - Sun, 15 Aug 2021 16:44 UTC

On 8/15/2021 9:45 AM, wij wrote:
> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
>> On 8/15/2021 2:50 AM, wij wrote:
>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
>>>> 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.
>>>
>>> In your recent post somewhere, you said:
>>> "I made my refutation of Linz a little more clear by changing all of the
>>> subscripts to be numeric. My refutation of Linz cannot be properly
>>> understood until after my refutation of simplified Linz / Strachey is
>>> first understood..."
>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
>>>
>> This text right here is correct:
>> 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
>> All of the rest of the text that "proves" the halting problem cannot be
>> solved it incorrect.
>
> Which one did you mean:
> 1. All of the rest of the text that "proves" the halting problem cannot be
> solved incorrect. (still ambiguous)
> 2. All of the rest of the text that "proves" the halting problem cannot
> solve incorrect. (ambiguous)
> 3. All of the rest of the text that "proves" the halting problem cannot be
> solved, it is incorrect.
>

All of the rest of the text that "proves" the halting problem cannot be
solved <IS> incorrect.

>>> There are much more inconsistent statements in your posts, like "H is a total
>>> function",...,etc. (I do not have time to re-find them).
>>>
>> H is a pure function of its inputs in that all of the nested simulations
>> are simply data derived entirely on the basis of this inputs.
>
> From your description:
> "The x86utm operating system uses a single contiguous block of RAM to
> most precisely map to the concept of a single contiguous Turing machine
> tape. All of the code and data of the virtual machines that it executes
> are contained in this single contiguous block. There is no virtual
> memory paging in the x86utm operating system."
>
> I believe your H is a 'pure function', you are actually dealing with two "C"
> function calls. H is not really a simulator as you keeps calling it so.
> Show me how H(P,P) takes its input P as 'simple data'.
>

The x86utm operating system is build from an x86 emulator capable of
emulating all of the 80386 instructions using 4 GB of RAM.

The following x86utm operating system function calls the x86 emulator to
emulate exactly one instruction of the slave process and then return to
the calling process. It also decodes the slave instruction that was
emulated so that it can be stored in the execution trace.

u32 DebugStep(Registers* master_state,
Registers* slave_state,
Decoded_Line_Of_Code* decoded) {}

> I hate to say that your programming level is very low because this has noting
> to do with the HP proof. I think many others know x86 and C languages and
> programming skills better than you do. No need to repeat posting the compiled
> assembly code fragment and pretend you know better and others cannot see it.
>

It is ridiculously foolish to claim that P on input P has nothing to do
with the halting problem proofs:

Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)

It remains ridiculously foolish for people claiming to fully understand
the x86 language to disagree with the following statement:

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

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


Click here to read the complete article
Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7258&group=comp.ai.philosophy#7258

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 12:16:56 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 12:16:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@giganews.com>
Lines: 319
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Aftzpk3LNVlEKzn0clllSNs764lolm7WwtlVycOQCEl78QOHv1FvTfM5xwcsLnnDM8DBGEN/c+SR4z8!82zTthl+9QuYZXsxp8tPvrllUA7NDC5ieOcQknn94C5anYhSmtZpdshl/4YfRqr+9ehc7eKNsgk0!F/A=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 15643
X-Received-Bytes: 15869
 by: olcott - Sun, 15 Aug 2021 17:16 UTC

On 8/15/2021 9:46 AM, Mike Terry wrote:
> On 14/08/2021 22:20, 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?
>
> I've tried to get PO to clarify that, and it always /seems/ that he is
> suggesting yes [while avoiding any direct answer] but I have no
> confidence whatsoever that he understands what everybody else would
> understand by "its own address space".
>

There is a single contiguous block of RAM that is used by all of the
virtual machine and the halt decider. Whenever H is called it creates a
separate context having its own Registers, RAM and stack space. It
performs its x86 emulation on its input virtual machine in the separate
process context. Just like recursion the executable code of every
instance of P and H are at the same fixed machine address.

> He has definitely said that each simulation has its own stack and
> registers, but my bet would be that they are more like your typical OS
> threads, running in the same address space.  (We could probably find out
> by quizzing him on sharing of globals etc. and giving him concrete
> examples which he could understand.  But it might take a lot of work,
> and for what at the end?  Or more reasonably, if he published all his
> source code as he maintained he would for around two years, we could
> answer these sorts of questions for ourselves...)
>

Until people quit refuting this very obvious truth they consistently
prove that they are far too disingenuous to deserve any additional
details that would only give them an excuse to make sure that they
always go off on tangents and dodge the key relevant points:

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

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

[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

>> Second - if not, is there any way to know when an address is reported,
>> which simulator instance is being reported on?
>
> I suggested he needed to provide that last year.  And at one point he
> DID change his trace to show the emulation level, so it's not like
> there's any coding difficulty!  But then it was perfectly clear that he
> was correlating trace entries together from completely separate
> emulation levels, so the illusion that it was a "loop" in the normal
> (single) processor-trace sense was lessened.  He subsequently removed
> the column, claiming as excuse that it confused people.
>
> I'd say this is PO misunderstanding the difference between
> call-recursion and emulation-recursion.  The former can /only/ be broken
> by code at the deepest recursion level which then percolates up to the
> top level, like when we calculate n factorial recursively.
> Emulation-recursion /can/ also break out this way, but with emulation
> there is a second possibility - the break can be from the /top/ level
> which simply decides not to emulate any more.  The fact that the deepest
> inner emulations appear to be repeating doesn't mean that they will go
> on forever, because an outer level can always just give up emulating and
> get on with whatever is next.
>

If I did not understand this then I would have not explained it this
same way many dozens of times.

> I suppose without an emulation-id column we can probably work stuff out
> based on the overall flow of the trace together with knowledge about the
> program and what H is doing and so on.  (But why should this be required
> when it's an essential part of the meaning of a trace entry?)
>
>> 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?
>
> I can give you an assurance of exactly the opposite - they are
> definitely from /different/ emulation levels!  (I think you know that,
> right?) PO tries to present them to look as much as possible like a
> pattern of behaviour for a /single/ processor, because then he would
> have "call recursion" which can only break inner-to-outer, and his
> "processor trace" could provide some level of evidence that that won't
> happen. (Also I'm remebering his recent remarks about the processor
> "[..having no way to escape from the recursion..]" which might be
> explained as PO not understanding the call/recursion distinction...)
>


Click here to read the complete article
Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<trGdnbVVHclt0IT8nZ2dnUU7-QXNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7259&group=comp.ai.philosophy#7259

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 12:25:04 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<878s13y6s1.fsf@bsb.me.uk> <zjYRI.13727$fI7.7888@fx33.iad>
<QZydnaAum4OdrYT8nZ2dnUU78K3NnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 12:25:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <QZydnaAum4OdrYT8nZ2dnUU78K3NnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <trGdnbVVHclt0IT8nZ2dnUU7-QXNnZ2d@giganews.com>
Lines: 150
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jDC6qfLFsxuRMBEPXgy2L55R4fhRlWbzjk8XbYq2DWUd8nxvznqSTHkGJn4nZH66tkIWxRlWngcPW97!di7wSZs/KPZvWtvJjNVSie2uH9DKq16NdZibLZCnXlN/3k1WKTFwms5rWsWvEpHZjjB2HzW3F1Sp!eOc=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8323
 by: olcott - Sun, 15 Aug 2021 17:25 UTC

On 8/15/2021 10:17 AM, Mike Terry wrote:
> On 15/08/2021 00:27, Richard Damon wrote:
>> On 8/14/21 6:56 PM, Ben Bacarisse wrote:
>>> Jeff Barnett <jbb@notatt.com> writes:
>>>
>>>> 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.
>>>
>>> You won't get a straight answer from PO, but I don't think there is any
>>> nested simulation happening at all.  PO "knows" it's that same a
>>> recursion, so he just has recursive calls traced from "outside".  I may
>>> be wrong, of course, but this is one reason I think H is being kept
>>> hidden -- it does not do what says.
>>>
>>
>> He actually has leaked a fair amount about how the system works. H isn't
>> actually a simulator, but an 'API Entry' into the x86utm system that has
>> the real simulator, and calls into H as supposed to setup a new 'nested'
>> level of simulation.
>
> My impression is that H is part of the application code rather than an
> OS call, but within H there are calls to PO's simulation primitives
> which are trapped by x86utm.exe and implemented within x86utm.  H would
> still have the task of inspecting the (nested) emulation trace entries
> to detect what it decides to be non-halting behaviour.  (But then PO has
> talked about a "global decider" which is part of the OS, so maybe my
> impression is completely wrong!  To be relevent to Linz, the deciding
> logic at least must be in the application rather than in x86utm.)
>

Now that I created

int Simulate(u32 P, u32 I)
{ ((int(*)(int))P)(I);
return 1;
}

The global halt decider is fully obsolete.

I am (of course) aware that the above function directly executes rather
that emulates its input, none-the-less it provides a very simple way
that is very easy to understand to provide the computational equivalent
of simulation.

>>
>> It sounds like these nested simulations are given their own stacks and
>> 'user' code isn't supposed to be able to store data anywhere but on the
>> stack, so that is supposed to be enough for a new environment, since he
>> erroneously puts everything inside one code segment. (This means that H
>> isn't a 'Universal' Halt Decider, as its input isn't an arbitrary
>> machine.
>>
>> This would be one reason you can't 'copy' H, is that H isn't really the
>> code but just an API (and if he allowed copying, his nesting detection
>> breaks).
>>
>> One side effect of this is that I am not sure if his system can actually
>> really handle finitely but multi-level simulations as at least some of
>> the leaked implementations made H not really a computation as it used
>> static memory to communicate between H and the OS.
>>
>>
>> I also wonder if a computation built on P1 using H to decide on P2 which
>> used H to decide on P3 could return the answer from P3 to P2.
>>
>> This structure could be used to solve the twins prime conjecture if the
>> Halt decider actually worked. P1 would ask P2 to find the highest twin
>> prime. If it is non-halting there is no highest twin prime.
>>
>> P2 would iterate through the twin primes starting at say 3,5 and ask P3
>> to find the next one. If it find one, then it updates to that point and
>> uses it again to find the next highest. If P2 is at the highest, then P3
>> would be non-halting, and P2 would get the non-halting answer and could
>> tell P1 what is the highest twin prime.
>>
>> P3 just takes its input and searches to find the next highest twin prime
>> from there. If there isn't one it will just be non-halting.
>>
>> The problem is that just because P3 becomes non-halting isn't grounds to
>> call P1 or P2 non-halting, as P3 becoming non-halting is the halting
>> condition of P2. It is only if for every problem that P2 gives P3 that
>> it always finds an answer that P2 becomes non-halting, and P1 then knows
>> that the answer to the question is that there is no highest twin prime.
>> (P1 halts in all cases).
>>
>> The slight problem is that his current definition of H doesn't seem to
>> allow the caller of H to get the 'answer' from the machine it is
>> running, so you have to do everything twice, first determine that it
>> WOULD halt, then just call it to get the answer.
>>
>
> Maybe, but the emulating user code has access to the trace of the
> emulated program, so in principle it should be able to work out what
> that program returned. E.g. it can track that it finished by loading RAX
> with (say) 1 then returned (terminated), meaning that it returned 1.
>
> Mike.
>

The executed (rather than simulated) instance of H has every relevant
detail of all of its nested emulations as its own data that is derived
as a pure function of its inputs.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7260&group=comp.ai.philosophy#7260

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 16 Aug 2021 17:49:33 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87im06wiup.fsf@bsb.me.uk>
<DJGdncQOXNbfHYT8nZ2dnUU7-dPNnZ2d@giganews.com> <874kbqw62q.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 16 Aug 2021 17:49:32 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <874kbqw62q.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com>
Lines: 51
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-KWbvYqrI/qtF/LkSxH5IDupNQuAkxWzr86UkZjZ1Ta8tBoZSAcLF6Fe9OepLN+vIWj+T+WakLvK+thh!+LaHDA0BGu8TPD3KAMj5KJkPYhthBUiclJb+aKH5YhzrcQYF4+zVOGBFs/VxdW6yBQW6yqKv3HKH!OV0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3369
 by: olcott - Mon, 16 Aug 2021 22:49 UTC

On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>
>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>
>> In other words your knowledge of infinite recursive invocation is on
>> par with your knowledge of operating system context switching?
>
> P(P) halts.
>
>>> Imagine if you'd been honest about this two and half years ago? "I have
>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>> one would care.
>>
>> I finally have this one untangled:
>> int main() { P(P); } is computationally equivalent to
>> int main() { Simulate(P,P); }
>>
>> Because they are computationally equivalent they have the same halting
>> behavior, however:
>>
>> Neither of them is computationally equivalent to the H(P,P) called
>> from P because the different placement in the execution trace changes
>> the halting behavior of P(P).
>
> H(M, I) is supposed to report the halting or otherwise of M(I). You
> don't claim that your H can do this in all cases, but you boasted (you
> like boasting) that it did for the "hat" version of H, AKA P above. It
> does not. P(P) halts but H(P, P) == 0. Boring.
>

That you don't bother to pay attention to the details or are unable to
understand the x86 language well enough to understand the details in no
way negates the fact that H(P,P) does correctly decide that its input
never halts. No one can possibly provide a rebuttal to this simply
because it is true.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7262&group=comp.ai.philosophy#7262

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 09:14:04 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <ToMSI.25497$Thb4.14112@fx35.iad> <2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@giganews.com> <LtXSI.32$tv2.30@fx45.iad> <HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com> <ZMYSI.11$Oz2.8@fx47.iad> <TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com> <EcZSI.233$kr4.37@fx48.iad> <XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad> <B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com> <8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com> <1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com> <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 09:14:03 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com>
Lines: 60
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ctbA/RppmTs/JsUunB/9I7t93Q1DKe0glVfuFu0xUQ7ucAFDh4hF24jXSHwPvOPsnP3VtfEzUI1pNu/!fIM4YoWRWo2iURS7XBd2niijDF6bdOkcbHZ1F0lEKIZpzPDLsjNso+4E4UZ/smUR/rq1E6V0ljRo!X/g=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4828
 by: olcott - Thu, 19 Aug 2021 14:14 UTC

On 8/19/2021 5:26 AM, Malcolm McLean wrote:
> On Wednesday, 18 August 2021 at 16:44:44 UTC+1, olcott wrote:
>> On 8/18/2021 10:28 AM, Malcolm McLean wrote:
>>> On Wednesday, 18 August 2021 at 14:57:10 UTC+1, olcott wrote:
>>>>
>>>> H has no effect on the machine that it simulates until after its halt
>>>> status decision has been made. This conclusively proves that H can
>>>> ignore its in execution trace during its halt status analysis.
>>>>
>>>> Anyone disagreeing with this is either not intelligent or knowledgeable
>>>> enough to understand it, or a liar.
>>>>
>>>> That H does effect the behavior or its input at some other point is
>>>> utterly irrelevant to this analysis. We are only answering the single
>>>> question: Is it correct for H to ignore its own execution trace during
>>>> its halt status analysis?
>>>>
>>> If H is analysing H, it can't ignore the behaviour of H. That's why your results
>>> are wrong despite the execution trace seeming to show a non-halting
>>> behaviour.
>>>
>> 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.
>>
>> The above proves itself true entirely on the basis of the meaning
>> of its words. There is no possible correct rebuttal there is only
>> a failure to comprehend. If you believe that there is a correct
>> rebuttal please provide it and I will point out your error.
>>
> You're wrong here. When H is being called on a program which includes
> a call to H, the nested call to H needs to be analysed like any other
> call. It can and in fact does affect the halting behaviour of the input.

You are doing as bad of a job analyzing this as Robert. You are making
sure to simply ignore key words that I have said.

WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
ITS INPUT.

WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY EFFECT
ON THE BEHAVIOR OF ITS INPUT.

WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.

Try and find a specific flaw in that, there are one.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7263&group=comp.ai.philosophy#7263

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer03.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 10:14:10 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87im06wiup.fsf@bsb.me.uk> <DJGdncQOXNbfHYT8nZ2dnUU7-dPNnZ2d@giganews.com>
<874kbqw62q.fsf@bsb.me.uk> <W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com>
<87h7fpuf5v.fsf@bsb.me.uk> <AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk> <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 10:14:09 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87r1eppoe5.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>
Lines: 278
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-j7n6qSCQ+KjERO56FtgClylSvFV12xbkC4IM4+FeDJ7KMr8ydj1MF+DL+ptxnCi96DGfS7Ygg/EuW3M!YSLhTL00aw7pYv+esOHfQOaji76ujeqXdljjFxNm2PGpi0uA1D7XW/2Ee3hAUaz4FdxqG3vL9JKq!6qI=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 13751
X-Received-Bytes: 13964
 by: olcott - Thu, 19 Aug 2021 15:14 UTC

On 8/19/2021 8:14 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/18/2021 8:42 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/18/2021 8:16 PM, Ben Bacarisse wrote:
>
>>>>> Yes. I cut them because they are not the specification of the function
>>>>> that I will challenge you to write.
>>>>
>>>> That is out-of-scope and you know it.
>>>
>>> Not in my opinion, no. A function that that shows there are undecidable
>>> sets should worry you, but for some reason you prefer to stick with
>>> talking about your H that does something entirely unsurprising and
>>> uninteresting.
>>
>> So when I correctly refute the halting problem proofs you say no I did
>> not refute every proof in the universe and the halting problem proof
>> is one of these proofs therefore I did not refute the halting problem
>> proof.
>
> No, I'm not saying that.
>
> Anyway, in case you are interested, here is the specification of the
> function you can't write:
>
> The computational model is C code with no memory restrictions. Of
> course, if you don't actually hit the memory limits of a C
> implementation it's just actual C code. I'd be happy to say more about
> this model of computation if you think the details will matter to your
> solution.
>
> The problem is that of deciding if a function would return if called
> from main. A "return decider" (in this model) is a C function returning
> _Bool that always returns a value to the expression in which it was
> called. A return decider always returns the same value for any
> arguments that represnet the same function call expression.
>
> Your mission, should you chose to accept it, is to write a return
> decider B with this prototype
>
> typedef uintptr_t data;
> typedef void (*function)(data);
>
> extern _Bool B(function, data);
>
> such that B(f, d) returns true if and only if a call of f from main with
> argument d returns to main. The two arguments, f and d, are said to
> represenet the call expression f(d).
>
> If, rather than just thinking you can do this, you have actual C code,
> you should provide either source or a compiled translation unit that can
> be linked with this one:
>
> #include <stdint.h>
> #include <stdio.h>
>
> typedef uintptr_t data;
> typedef void (*function)(data);
>
> extern _Bool B(function, data);
>
> void B_hat(data x) { if (B((function)x, x)) while (1); }
>
> int main(void)
> {
> printf("%d\n", B(B_hat, (data)B_hat));
> fflush(stdout);
> B_hat((data)B_hat);
> puts("returned");
> }
>
> The output should be either
>
> 1
> returned
>
> or
>
> 0
>
> with no further output. Of course you could always just agree that no
> such function B can be written.
>

The x86utm operating system cannot call any C functions.
Good job on the use of C. My own use of unsigned integers as function
pointers is unconventional and not as portable. I did this on purpose so
that x86utm would have a single standard tape element type.

#include <stdint.h>
#include <stdio.h>

typedef uintptr_t data;
typedef void (*function)(data);

extern _Bool B(function, data);

void B_hat(data x) { if (H((u32)x, (u32)x)) while (1); }

int main2()
{ OutputHex(H((u32)B_hat, (u32)B_hat));
B_hat((u32)B_hat);
OutputString("returned");
}

_B_hat()
[00000efc](01) 55 push ebp
[00000efd](02) 8bec mov ebp,esp
[00000eff](03) 8b4508 mov eax,[ebp+08]
[00000f02](01) 50 push eax
[00000f03](03) 8b4d08 mov ecx,[ebp+08]
[00000f06](01) 51 push ecx
[00000f07](05) e850feffff call 00000d5c
[00000f0c](03) 83c408 add esp,+08
[00000f0f](02) 85c0 test eax,eax
[00000f11](02) 740b jz 00000f1e
[00000f13](05) ba01000000 mov edx,00000001
[00000f18](02) 85d2 test edx,edx
[00000f1a](02) 7402 jz 00000f1e
[00000f1c](02) ebf5 jmp 00000f13
[00000f1e](01) 5d pop ebp
[00000f1f](01) c3 ret
Size in bytes:(0036) [00000f1f]

_main2()
[00000f2c](01) 55 push ebp
[00000f2d](02) 8bec mov ebp,esp
[00000f2f](05) 68fc0e0000 push 00000efc
[00000f34](05) 68fc0e0000 push 00000efc
[00000f39](05) e81efeffff call 00000d5c
[00000f3e](03) 83c408 add esp,+08
[00000f41](01) 50 push eax
[00000f42](05) e8e5f3ffff call 0000032c
[00000f47](03) 83c404 add esp,+04
[00000f4a](05) 68fc0e0000 push 00000efc
[00000f4f](05) e8a8ffffff call 00000efc
[00000f54](03) 83c404 add esp,+04
[00000f57](05) 6823030000 push 00000323
[00000f5c](05) e8dbf3ffff call 0000033c
[00000f61](03) 83c404 add esp,+04
[00000f64](01) 5d pop ebp
[00000f65](01) c3 ret
Size in bytes:(0058) [00000f65]

_main()
[00000f6c](01) 55 push ebp
[00000f6d](02) 8bec mov ebp,esp
[00000f6f](05) e8b8ffffff call 00000f2c
[00000f74](02) 33c0 xor eax,eax
[00000f76](01) 5d pop ebp
[00000f77](01) c3 ret
Size in bytes:(0012) [00000f77]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000f6c][00101c0a][00000000] 55 push ebp
....[00000f6d][00101c0a][00000000] 8bec mov ebp,esp
....[00000f6f][00101c06][00000f74] e8b8ffffff call 00000f2c
....[00000f2c][00101c02][00101c0a] 55 push ebp
....[00000f2d][00101c02][00101c0a] 8bec mov ebp,esp
....[00000f2f][00101bfe][00000efc] 68fc0e0000 push 00000efc
....[00000f34][00101bfa][00000efc] 68fc0e0000 push 00000efc
....[00000f39][00101bf6][00000f3e] e81efeffff call 00000d5c

Begin Local Halt Decider Simulation at Machine Address:efc
....[00000efc][00211caa][00211cae] 55 push ebp
....[00000efd][00211caa][00211cae] 8bec mov ebp,esp
....[00000eff][00211caa][00211cae] 8b4508 mov eax,[ebp+08]
....[00000f02][00211ca6][00000efc] 50 push eax
....[00000f03][00211ca6][00000efc] 8b4d08 mov ecx,[ebp+08]
....[00000f06][00211ca2][00000efc] 51 push ecx
....[00000f07][00211c9e][00000f0c] e850feffff call 00000d5c
....[00000efc][0025c6d2][0025c6d6] 55 push ebp
....[00000efd][0025c6d2][0025c6d6] 8bec mov ebp,esp
....[00000eff][0025c6d2][0025c6d6] 8b4508 mov eax,[ebp+08]
....[00000f02][0025c6ce][00000efc] 50 push eax
....[00000f03][0025c6ce][00000efc] 8b4d08 mov ecx,[ebp+08]
....[00000f06][0025c6ca][00000efc] 51 push ecx
....[00000f07][0025c6c6][00000f0c] e850feffff call 00000d5c
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
....[00000f3e][00101c02][00101c0a] 83c408 add esp,+08
....[00000f41][00101bfe][00000000] 50 push eax
---[00000f42][00101bfe][00000000] e8e5f3ffff call 0000032c
0 ....[00000f47][00101c02][00101c0a] 83c404 add esp,+04
....[00000f4a][00101bfe][00000efc] 68fc0e0000 push 00000efc
....[00000f4f][00101bfa][00000f54] e8a8ffffff call 00000efc
....[00000efc][00101bf6][00101c02] 55 push ebp
....[00000efd][00101bf6][00101c02] 8bec mov ebp,esp
....[00000eff][00101bf6][00101c02] 8b4508 mov eax,[ebp+08]
....[00000f02][00101bf2][00000efc] 50 push eax
....[00000f03][00101bf2][00000efc] 8b4d08 mov ecx,[ebp+08]
....[00000f06][00101bee][00000efc] 51 push ecx
....[00000f07][00101bea][00000f0c] e850feffff call 00000d5c

Begin Local Halt Decider Simulation at Machine Address:efc
....[00000efc][0026c772][0026c776] 55 push ebp
....[00000efd][0026c772][0026c776] 8bec mov ebp,esp
....[00000eff][0026c772][0026c776] 8b4508 mov eax,[ebp+08]
....[00000f02][0026c76e][00000efc] 50 push eax
....[00000f03][0026c76e][00000efc] 8b4d08 mov ecx,[ebp+08]
....[00000f06][0026c76a][00000efc] 51 push ecx
....[00000f07][0026c766][00000f0c] e850feffff call 00000d5c
....[00000efc][002b719a][002b719e] 55 push ebp
....[00000efd][002b719a][002b719e] 8bec mov ebp,esp
....[00000eff][002b719a][002b719e] 8b4508 mov eax,[ebp+08]
....[00000f02][002b7196][00000efc] 50 push eax
....[00000f03][002b7196][00000efc] 8b4d08 mov ecx,[ebp+08]
....[00000f06][002b7192][00000efc] 51 push ecx
....[00000f07][002b718e][00000f0c] e850feffff call 00000d5c
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
....[00000f0c][00101bf6][00101c02] 83c408 add esp,+08
....[00000f0f][00101bf6][00101c02] 85c0 test eax,eax
....[00000f11][00101bf6][00101c02] 740b jz 00000f1e
....[00000f1e][00101bfa][00000f54] 5d pop ebp
....[00000f1f][00101bfe][00000efc] c3 ret
....[00000f54][00101c02][00101c0a] 83c404 add esp,+04
....[00000f57][00101bfe][00000323] 6823030000 push 00000323
---[00000f5c][00101bfe][00000323] e8dbf3ffff call 0000033c
returned
....[00000f61][00101c02][00101c0a] 83c404 add esp,+04
....[00000f64][00101c06][00000f74] 5d pop ebp
....[00000f65][00101c0a][00000000] c3 ret
....[00000f74][00101c0a][00000000] 33c0 xor eax,eax
....[00000f76][00101c0e][00100000] 5d pop ebp
....[00000f77][00101c12][00000008] c3 ret
Number_of_User_Instructions(2)
Number of Instructions Executed(47451)


Click here to read the complete article
Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<X8ednQJLG4oW6oP8nZ2dnUU7-X3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7264&group=comp.ai.philosophy#7264

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 10:23:55 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com> <ZMYSI.11$Oz2.8@fx47.iad> <TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com> <EcZSI.233$kr4.37@fx48.iad> <XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad> <B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com> <8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com> <1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com> <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com> <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <ed49e1ee-ea07-4227-9eaa-d0e22449cb3an@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 10:23:54 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <ed49e1ee-ea07-4227-9eaa-d0e22449cb3an@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <X8ednQJLG4oW6oP8nZ2dnUU7-X3NnZ2d@giganews.com>
Lines: 146
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-KdThdfK1UhvnFusfsjpGqSNwdoWrMZUT9JMIAEvoIjL+S9LtuvdbMwWN4EmCsRg+Zq+jzs6XOx1Oh/X!H0uxkuA3HuSqNlGE+tuxXlpqNrCpr47XPgRf9I8P27Yj5ZGh4STRIdYtqk6MC6pxquRzPitQJHQq!yYc=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7702
 by: olcott - Thu, 19 Aug 2021 15:23 UTC

On 8/19/2021 9:39 AM, Malcolm McLean wrote:
> On Thursday, 19 August 2021 at 15:14:11 UTC+1, olcott wrote:
>> On 8/19/2021 5:26 AM, Malcolm McLean wrote:
>>> On Wednesday, 18 August 2021 at 16:44:44 UTC+1, olcott wrote:
>>>> On 8/18/2021 10:28 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 18 August 2021 at 14:57:10 UTC+1, olcott wrote:
>>>>>>
>>>>>> H has no effect on the machine that it simulates until after its halt
>>>>>> status decision has been made. This conclusively proves that H can
>>>>>> ignore its in execution trace during its halt status analysis.
>>>>>>
>>>>>> Anyone disagreeing with this is either not intelligent or knowledgeable
>>>>>> enough to understand it, or a liar.
>>>>>>
>>>>>> That H does effect the behavior or its input at some other point is
>>>>>> utterly irrelevant to this analysis. We are only answering the single
>>>>>> question: Is it correct for H to ignore its own execution trace during
>>>>>> its halt status analysis?
>>>>>>
>>>>> If H is analysing H, it can't ignore the behaviour of H. That's why your results
>>>>> are wrong despite the execution trace seeming to show a non-halting
>>>>> behaviour.
>>>>>
>>>> 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.
>>>>
>>>> The above proves itself true entirely on the basis of the meaning
>>>> of its words. There is no possible correct rebuttal there is only
>>>> a failure to comprehend. If you believe that there is a correct
>>>> rebuttal please provide it and I will point out your error.
>>>>
>>> You're wrong here. When H is being called on a program which includes
>>> a call to H, the nested call to H needs to be analysed like any other
>>> call. It can and in fact does affect the halting behaviour of the input.
>> You are doing as bad of a job analyzing this as Robert. You are making
>> sure to simply ignore key words that I have said.
>>
>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
>> ITS INPUT.
>>
>> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY EFFECT
>> ON THE BEHAVIOR OF ITS INPUT.
>>
>> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
>> NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>>
>> Try and find a specific flaw in that, there are one.
>>
> Let's forget LInz and take this simple function
>
> void loopforever(U32 dummy)
> {
> while(1);
> }
>
> Now loopforever(dummy) doesn't halt, agreed?
> this function
>
> int H1(U32 dummy)
> {
> return H(loopforever, dummy);
> }
>
> halts and returns 0 (non-halting). Agreed?
>
> Now consider this function
>
> int H2(u32 dummy)
> {
> return H(H1, dummy);
> }
>
> What does that do?
>

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00000ea2](01) 55 push ebp
[00000ea3](02) 8bec mov ebp,esp
[00000ea5](02) ebfe jmp 00000ea5
[00000ea7](01) 5d pop ebp
[00000ea8](01) c3 ret
Size in bytes:(0007) [00000ea8]

_main()
[00000f02](01) 55 push ebp
[00000f03](02) 8bec mov ebp,esp
[00000f05](05) 68a20e0000 push 00000ea2
[00000f0a](05) e8e3fcffff call 00000bf2
[00000f0f](03) 83c404 add esp,+04
[00000f12](01) 50 push eax
[00000f13](05) 6823030000 push 00000323
[00000f18](05) e835f4ffff call 00000352
[00000f1d](03) 83c408 add esp,+08
[00000f20](02) 33c0 xor eax,eax
[00000f22](01) 5d pop ebp
[00000f23](01) c3 ret
Size in bytes:(0034) [00000f23]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000f02][00101b56][00000000] 55 push ebp
....[00000f03][00101b56][00000000] 8bec mov ebp,esp
....[00000f05][00101b52][00000ea2] 68a20e0000 push 00000ea2
....[00000f0a][00101b4e][00000f0f] e8e3fcffff call 00000bf2

Begin Local Halt Decider Simulation at Machine Address:ea2
....[00000ea2][00211bfa][00211bfe] 55 push ebp
....[00000ea3][00211bfa][00211bfe] 8bec mov ebp,esp
....[00000ea5][00211bfa][00211bfe] ebfe jmp 00000ea5
....[00000ea5][00211bfa][00211bfe] ebfe jmp 00000ea5
Local Halt Decider: Infinite Loop Detected Simulation Stopped

....[00000f0f][00101b56][00000000] 83c404 add esp,+04
....[00000f12][00101b52][00000000] 50 push eax
....[00000f13][00101b4e][00000323] 6823030000 push 00000323
---[00000f18][00101b4e][00000323] e835f4ffff call 00000352
Input_Halts = 0
....[00000f1d][00101b56][00000000] 83c408 add esp,+08
....[00000f20][00101b56][00000000] 33c0 xor eax,eax
....[00000f22][00101b5a][00100000] 5d pop ebp
....[00000f23][00101b5e][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(627)

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7265&group=comp.ai.philosophy#7265

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!tncsrv06.tnetconsulting.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 18:50:32 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 18:50:31 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87bl5tni1t.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
Lines: 55
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FwNfvHrbK/IBUiGprsyrxO/2+1hzempkn96TLZnvnLULhhBl5IHavestaJOLZCNUO4L9xFybasa1WvQ!ZxtjlSlsFGwA0hEFCk/QhaOTyzd/P59hHP7HPpEPedcNmOoL+sf59regDUF1hv3CJcgpUkEV/PBi!ZU0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4207
 by: olcott - Thu, 19 Aug 2021 23:50 UTC

On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Ĥ applied to ⟨Ĥ⟩ halts.
>
> Yes.
>
> And on the 12th Aug you said, and I quote
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> This is incorrect. You need to correct that statement so you can go on
> to investigate the consequences. It's not a trivial error. It's
> absolutely central to the case under investigation.
>
>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>
> We are both saying that -- you said it above and of course I agree. The
> point of disagreement is that you said
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
> computation.
>
>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>
> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
> string that encodes a halting computation" (I think its does mean the
> same, just poorly worded), but obviously I want to correct the clear and
> unambiguously wrong version from Aug 12th. So long as you refuse to
> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
> discussion is pointless.
>

You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
halts yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
never halts.

Because of the pathological self-reference that Flibble objected to
exists whether or not ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation depends on
its placement in the execution trace.

If Ĥ is applied to ⟨Ĥ⟩ at the beginning of the execution trace then this
Ĥ halts because of its dependency on the other instances at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩.

The inputs to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ have no such dependency thus specify an
entirely different computation.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<lOKdnZaF4e78RoL8nZ2dnUU7-e3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7267&group=comp.ai.philosophy#7267

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 11:42:09 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 11:42:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <lOKdnZaF4e78RoL8nZ2dnUU7-e3NnZ2d@giganews.com>
Lines: 85
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-We7GLWbC/dgeD+EVUYWta36SRs8QzJA5AelY7vG1jWtO7ZGTFwrOwhtADsA/GGIFV1BL/awN8qndL23!kbjdRiQM/T8y4OUV3Hu5JblnswGwc9s55pHI90sAYUsw/4L4OI5kCdtGHTbql1uT16beYwt8taeB!W+I=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6073
 by: olcott - Fri, 20 Aug 2021 16:42 UTC

On 8/20/2021 10:45 AM, Malcolm McLean wrote:
> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>
>>> You are not going to stay focused on the most serious error you have yet
>>> posted?
>> You have to go though the following reasoning and point out the specific
>> error. Making a blanket assertion that there is an error somewhere does
>> not count as any rebuttal at all.
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>> that do not have a dependency on the first Ĥ, this makes their position
>> in the execution trace have an effect on their behavior.
>>
>> Perhaps this is simply beyond your capacity to understand?
>>
>> From this we can conclude that while the simulating halt decider at
>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>
>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>> halting computation.
>> You have to find the specific error in my rebuttal of this. Making a
>> blanket assertion that there is an error somewhere does not count as any
>> rebuttal at all.
>>
> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>
> H gets H_Hat wrong, as Linz says it must do. No surprise there.
> 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 order to show that the above definition has been satisfied we only
have to show that halt decider Ĥ.qx does correctly decide whether or not
its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
⟨Ĥ2⟩.

// ⟨Ĥ1⟩ Input to Ĥ
// ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and Ĥ

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.

Key halt deciding theorem that applies to every simulating halt decider
(SHD):
(a) Every input to a SHD that never stops running unless its simulation
is aborted, or
(b) Every input that never stops running while the SHD is in pure
simulation mode.
Is an input that is correctly decided as never halting.

> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
> non halting as well. So did H_Hat(H_Hat) not halt all along, and we are too
> sinful to see it? Or is there something wrong with the execution trace?
>
> Obviously the only sane conclusion anyone can draw is that there is something
> wrong with the execution trace. So exactly what? If a function's position in the
> execution trace has an effect on its behaviour, this suggests what might be wrong.
> But whilst people can and have made sensible, informed guesses as to what is
> wrong, you're either unwilling or unable to answer some pretty basic questions
> about H. So it remains a conjecture.
>

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<lOKdnZGF4e6ZQYL8nZ2dnUU7-e2dnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7268&group=comp.ai.philosophy#7268

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 11:44:52 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com> <87a6lcxecd.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 11:44:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87a6lcxecd.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <lOKdnZGF4e6ZQYL8nZ2dnUU7-e2dnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WiuNI7lOekRh7SGLhTS8KWOTPUlWDTSSVPt0Qcd5Rrloe+HlrdPis9UepXRhWN3+aXe7AI7siKPnK3J!lCwlp4N/Iwkk/7ODyexg16S9uNGpoxdWFHvDWEa0JjoT6VkodZSBza3tplJoRvKibpotRt8DfK3A!VD0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5740
 by: olcott - Fri, 20 Aug 2021 16:44 UTC

On 8/20/2021 11:36 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>>
>>>> You are not going to stay focused on the most serious error you have yet
>>>> posted?
>>> You have to go though the following reasoning and point out the specific
>>> error. Making a blanket assertion that there is an error somewhere does
>>> not count as any rebuttal at all.
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>>> that do not have a dependency on the first Ĥ, this makes their position
>>> in the execution trace have an effect on their behavior.
>>>
>>> Perhaps this is simply beyond your capacity to understand?
>>>
>>> From this we can conclude that while the simulating halt decider at
>>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>>
>>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>>> halting computation.
>>> You have to find the specific error in my rebuttal of this. Making a
>>> blanket assertion that there is an error somewhere does not count as any
>>> rebuttal at all.
>>>
>> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>>
>> H gets H_Hat wrong, as Linz says it must do. No surprise there.
>>
>> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
>> non halting as well.
>
> At least one trace, explicitly of H_Hat(H_Hat), shows it halting. And
> when PO pretended that his H might meet the specification I gave for B
> (a "function return decider") it showed B_hat(B_hat) returning after a
> separate top-level call to B(B_hat, B_hat) returned 0.
>

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 order to show that the above definition has been satisfied we only
have to show that halt decider Ĥ.qx does correctly decide whether or not
its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
⟨Ĥ2⟩.

// ⟨Ĥ1⟩ Input to Ĥ
// ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.
Key halt deciding theorem that applies to every simulating halt decider
(SHD):
(a) Every input to a SHD that never stops running unless its simulation
is aborted, or
(b) Every input that never stops running while the SHD is in pure
simulation mode.
Is an input that is correctly decided as never halting.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]

<_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7270&group=comp.ai.philosophy#7270

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 16:09:33 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? [ computational dependence ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<87y28vx32t.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 16:09:31 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87y28vx32t.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
Lines: 46
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1sTeO4xoD+v6UHYzuy4ZjamlkbQnl2KCDcdg6nGvIKHe5YwsEiyuiPZC73HfDKkmkS7ppxgVyIfljwT!dvM9zFTmXheSskJILNfLBGU/8O3IlKAgH3ac5deRhrIjWwlg6IsOM7JLjKQXhxFwh3IM0VC1/3Ek!ks0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3765
 by: olcott - Fri, 20 Aug 2021 21:09 UTC

On 8/20/2021 3:40 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> I am not going to bother to answer all of this so that you can stay
>>>> focused on one key point:
>
>>> You are not going to stay focused on the most serious error you have yet
>>> posted?
>>
>> You have to go though the following reasoning and point out the
>> specific error.
>
> The specific error is that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of
> Ĥ applied to ⟨Ĥ⟩ which, everyone agrees, is a halting computation. Your
> statement of Aug 12th that
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> is simply wrong in the simplest factual way. I don't have to look
> anywhere else to point out the specific error.
>

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The executed Ĥ in the above expression only halts because of its
computational dependence on the halt status decision of the simulating
halt decider on its input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩.

The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational dependence
on the executed Ĥ.

That the computational dependence of one computation on other
conclusively proves that the dependent computation is not
computationally equivalent to the independent computation may be beyond
your capacity to understand.

None-the-less the paradox is finally resolved.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]

<gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7271&group=comp.ai.philosophy#7271

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 16:20:46 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com> <87a6lcxecd.fsf@bsb.me.uk> <39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com> <Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com> <874kbjyi0s.fsf@bsb.me.uk> <ue2dnRdyvJH8ib38nZ2dnUU7-LfNnZ2d@giganews.com> <87sfz3x284.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 16:20:44 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87sfz3x284.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com>
Lines: 157
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5t3tahwWMrPybi3D5eCb3ZxQPXJ7v77zdRv6vMkpNzzGJtsaEDHMwU7bR8IPrFZz/VH8mO6vmRwkQXj!ReXek508mi1vqns/vzcp5ld5LasqnmVH+DDHgdW99jVqBZo56ZRVaFCKqF4v11i4pRN2dn7mCi4U!0T4=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 9061
 by: olcott - Fri, 20 Aug 2021 21:20 UTC

On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 3:32 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> // ⟨Ĥ1⟩ Input to Ĥ
>>>> // ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>
>>> Pure poetry. What does it mean to apply a string to a string? And all
>>> the ⟨Ĥi⟩ are identical to each other (and to ⟨Ĥ⟩) so I can write this as
>>>
>>>> Ĥ.q0 ⟨Ĥ2⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ1⟩ ⊢* Ĥ.qn
>>>> if ⟨Ĥ2⟩ applied to ⟨Ĥ1⟩ does not halt
>>>
>>> and it must mean exactly the same thing. You really have no idea how to
>>> use any mathematical notation.
>>
>> The point is that you are simply ignoring the dependency that the
>> executed Ĥ has on the status decision of the simulated inputs to Ĥ.qx
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>
> I am pointing out that your notation above is silly and meaningless. Of
> course you will be wrong about other things as well, but wouldn't it be
> useful to correct things one step at a time? The six supposedly clear
> symbolic lines above contain numerous errors.
>

My notion seems to be silly and meaningless in the same way that
calculus would seem silly and meaningless to a two year old. There was a
very smart four year old that could perform calculus quite well.

void P2(u32 x)
{ if (H1(x, x))
HERE: goto HERE;
}

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

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

Because H1 has identical machine code to H and the input to both of
these instances is the same the fact that they derive different results
conclusively proves that an identical function with the same input can
derive a different results when one function has computational
dependence on the other identical function.

_P2()
[00000e52](01) 55 push ebp
[00000e53](02) 8bec mov ebp,esp
[00000e55](03) 8b4508 mov eax,[ebp+08]
[00000e58](01) 50 push eax
[00000e59](03) 8b4d08 mov ecx,[ebp+08]
[00000e5c](01) 51 push ecx
[00000e5d](05) e8b0fcffff call 00000b12 // call H1
[00000e62](03) 83c408 add esp,+08
[00000e65](02) 85c0 test eax,eax
[00000e67](02) 7402 jz 00000e6b
[00000e69](02) ebfe jmp 00000e69
[00000e6b](01) 5d pop ebp
[00000e6c](01) c3 ret
Size in bytes:(0027) [00000e6c]

_main()
[00000e72](01) 55 push ebp
[00000e73](02) 8bec mov ebp,esp
[00000e75](05) 68520e0000 push 00000e52 // push P2
[00000e7a](05) 68520e0000 push 00000e52 // push P2
[00000e7f](05) e84efeffff call 00000cd2 // call H
[00000e84](03) 83c408 add esp,+08
[00000e87](01) 50 push eax
[00000e88](05) 6823030000 push 00000323
[00000e8d](05) e8c0f4ffff call 00000352
[00000e92](03) 83c408 add esp,+08
[00000e95](02) 33c0 xor eax,eax
[00000e97](01) 5d pop ebp
[00000e98](01) c3 ret
Size in bytes:(0039) [00000e98]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000e72][00101a94][00000000] 55 push ebp
....[00000e73][00101a94][00000000] 8bec mov ebp,esp
....[00000e75][00101a90][00000e52] 68520e0000 push 00000e52 // push P2
....[00000e7a][00101a8c][00000e52] 68520e0000 push 00000e52 // push P2
....[00000e7f][00101a88][00000e84] e84efeffff call 00000cd2 // call H

Begin Local Halt Decider Simulation at Machine Address:e52
....[00000e52][00211b34][00211b38] 55 push ebp
....[00000e53][00211b34][00211b38] 8bec mov ebp,esp
....[00000e55][00211b34][00211b38] 8b4508 mov eax,[ebp+08]
....[00000e58][00211b30][00000e52] 50 push eax // push P2
....[00000e59][00211b30][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][00211b2c][00000e52] 51 push ecx // push P2
....[00000e5d][00211b28][00000e62] e8b0fcffff call 00000b12 // call H1

Begin Local Halt Decider Simulation at Machine Address:e52
....[00000e52][0025c55c][0025c560] 55 push ebp
....[00000e53][0025c55c][0025c560] 8bec mov ebp,esp
....[00000e55][0025c55c][0025c560] 8b4508 mov eax,[ebp+08]
....[00000e58][0025c558][00000e52] 50 push eax // push P2
....[00000e59][0025c558][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][0025c554][00000e52] 51 push ecx // push P2
....[00000e5d][0025c550][00000e62] e8b0fcffff call 00000b12 // call H1
....[00000e52][002a6f84][002a6f88] 55 push ebp
....[00000e53][002a6f84][002a6f88] 8bec mov ebp,esp
....[00000e55][002a6f84][002a6f88] 8b4508 mov eax,[ebp+08]
....[00000e58][002a6f80][00000e52] 50 push eax // push P2
....[00000e59][002a6f80][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][002a6f7c][00000e52] 51 push ecx // push P2
....[00000e5d][002a6f78][00000e62] e8b0fcffff call 00000b12 // call H1
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

....[00000e62][00211b34][00211b38] 83c408 add esp,+08
....[00000e65][00211b34][00211b38] 85c0 test eax,eax
....[00000e67][00211b34][00211b38] 7402 jz 00000e6b
....[00000e6b][00211b38][00000d8f] 5d pop ebp
....[00000e6c][00211b3c][00000e52] c3 ret
....[00000e84][00101a94][00000000] 83c408 add esp,+08
....[00000e87][00101a90][00000001] 50 push eax
....[00000e88][00101a8c][00000323] 6823030000 push 00000323
---[00000e8d][00101a8c][00000323] e8c0f4ffff call 00000352
Input_Halts = 1
....[00000e92][00101a94][00000000] 83c408 add esp,+08
....[00000e95][00101a94][00000000] 33c0 xor eax,eax
....[00000e97][00101a98][00100000] 5d pop ebp
....[00000e98][00101a9c][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(617658)

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]

<y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7273&group=comp.ai.philosophy#7273

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 21 Aug 2021 23:01:45 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? [ computational dependence ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
<87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>
<87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com>
<87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com>
<87eeamjmkl.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 21 Aug 2021 23:01:42 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87eeamjmkl.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com>
Lines: 52
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-qZvdkBG4Q2BrfkSjB86zH5SecyJ2YoQ2NGNTF5tZFU4+el63LFLDT9qi8H+TnNZDy5f/q+lxVfnsVOT!kWQCPE1bdJO1VNO9Ujk+1A4lwbrp1UhqMlWaZFQsLFBoyMKycjLex+zUBWBs23P3MhiKj0WsMl+9!/No=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3868
X-Received-Bytes: 4047
 by: olcott - Sun, 22 Aug 2021 04:01 UTC

On 8/21/2021 8:27 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/21/2021 6:14 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>
>>>> It is trivially easy for me to understand that the simulation of ⟨Ĥ1⟩
>>>> ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops running unless
>>>> this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>>>
>>> You are reduced to saying things not in dispute as if they change any of
>>> the facts you are wrong about.
>>
>> You never agreed to this before.
>
> Don't be silly. I even gave this problem a name: "PO's Other Halting"
> problem. You remember the POOH problem? What happens "unless" (rather
> than what actually happens) is the same silly ruse you've been pulling
> for years.
>
>> Now we apply this Theorem:
>> Simulating Halt Decider Theorem (Olcott 2020):
>> A simulating halt decider correctly decides that any input that never
>> halts unless the simulating halt decider aborts its simulation of this
>> input is an input that never halts.
>
> This is not a theorem but the definition of what "correct" means for the
> POOH problem. A problem no one else cares about.
>

You have already agreed to it:

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ double-talk "rebuttal" ]

<ae-dnRm7Xc6LHb_8nZ2dnUU7-d3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7274&group=comp.ai.philosophy#7274

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 Aug 2021 11:49:26 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ double-talk "rebuttal" ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com> <87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <0WpUI.59077$Nc1.2096@fx34.iad> <87wnodilmx.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 22 Aug 2021 11:49:22 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87wnodilmx.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <ae-dnRm7Xc6LHb_8nZ2dnUU7-d3NnZ2d@giganews.com>
Lines: 85
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ygqDehTj6XKXqZRh2ZiclwD1aEhgFHNJ+Z93gRKxst7xGaN08f3ES78VC9iFsCcgZvriIACd/mFtD1r!zgejqWF43nFbNHsmn9ICR8RiOA9PfANDF89GjWCpui14Jnrl/Hj36FLDkJcm/gkOhvWAlIkvbR2Z!jHY=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5587
 by: olcott - Sun, 22 Aug 2021 16:49 UTC

On 8/22/2021 9:45 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 8/22/21 12:01 AM, olcott wrote:
>>> On 8/21/2021 8:27 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/21/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> It is trivially easy for me to understand that the simulation of ⟨Ĥ1⟩
>>>>>>> ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops running unless
>>>>>>> this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>>>>>>
>>>>>> You are reduced to saying things not in dispute as if they change
>>>>>> any of
>>>>>> the facts you are wrong about.
>>>>>
>>>>> You never agreed to this before.
>>>>
>>>> Don't be silly.  I even gave this problem a name: "PO's Other Halting"
>>>> problem.  You remember the POOH problem?  What happens "unless" (rather
>>>> than what actually happens) is the same silly ruse you've been pulling
>>>> for years.
>>>>
>>>>> Now we apply this Theorem:
>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>> A simulating halt decider correctly decides that any input that never
>>>>> halts unless the simulating halt decider aborts its simulation of this
>>>>> input is an input that never halts.
>>>>
>>>> This is not a theorem but the definition of what "correct" means for the
>>>> POOH problem.  A problem no one else cares about.
>>>>
>>>
>>> You have already agreed to it:
>>>
>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Truism:
>>>>> Every simulation that would never stop unless Halts() stops
>>>>> it at some point specifies infinite execution.
>>>>
>>>> Any algorithm that implements this truism is, of course, a halting
>>>> decider.
>>
>> I think you just got him too confused at some point and he made a
>> misstatement. You abuse the language enough that this is quite
>> possible.
>
> Excuse me! I was not at all confused. Something is lost by removing
> the context (and the rest if the paragraph that PO cuts helps to make
> the meaning clearer) but any algorithm that can decide that a simulation
> would never stop is a halt decider. The irony is that if he uses that
> algorithm to turn the simulator into a partial one, the result is not a
> halt decider!
>
> I don't really know what PO thinks I meant by these words, but since you
> are sane and knowledgeable and you think I made a mistake, my words can
> obviously be misunderstood. What did you think I was saying?
>

While a simulating halt decider is in simulation mode it cannot possibly
have any effect on the behavior of its input. While it cannot possibly
have any effect on the behavior of its input it is computationally
equivalent to a pure simulator's effect on the behavior of its input.

While a simulating halt decider is computationally equivalent to a pure
simulator and this simulation would never stop unless it stops it at
some point we can know that this input specifies infinite execution.

There may be some double-talk "rebuttal" that will fool the ignorant and
gullible if you try hard enough. The ignorant and gullible are not in my
target audience.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]

<c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7275&group=comp.ai.philosophy#7275

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 Aug 2021 12:18:47 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com> <87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 22 Aug 2021 12:18:44 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87r1elihh9.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>
Lines: 129
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ccVd9AAmrmiioE3qx5j4tC45YUdYkZ3TQ91BuXpkD5KczGmVGFJ/FkuiuPi7+MLUwQgdvX+rNwrHVNv!WdDINZfCBM9/dkoSPK6kGyr+F7ZAGSO/6yn7iV3LyhoW+LKrHiuodBmDmfreEp2GwbJ8g7XBqHzV!Gss=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7709
 by: olcott - Sun, 22 Aug 2021 17:18 UTC

On 8/22/2021 11:14 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 9:34 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/21/2021 8:27 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/21/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> It is trivially easy for me to understand that the simulation of ⟨Ĥ1⟩
>>>>>>>> ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops running unless
>>>>>>>> this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>>>>>>>
>>>>>>> You are reduced to saying things not in dispute as if they change any of
>>>>>>> the facts you are wrong about.
>>>>>>
>>>>>> You never agreed to this before.
>>>>> Don't be silly. I even gave this problem a name: "PO's Other Halting"
>>>>> problem. You remember the POOH problem? What happens "unless" (rather
>>>>> than what actually happens) is the same silly ruse you've been pulling
>>>>> for years.
>>>>>
>>>>>> Now we apply this Theorem:
>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>> A simulating halt decider correctly decides that any input that never
>>>>>> halts unless the simulating halt decider aborts its simulation of this
>>>>>> input is an input that never halts.
>>>>>
>>>>> This is not a theorem but the definition of what "correct" means for the
>>>>> POOH problem. A problem no one else cares about.
>>>>
>>>> You have already agreed to it:
>>> Yes, I have agreed that you get to define what the correct answer is for
>>> any instance of the POOH problem. The wold continues to spin and no one
>>> gives a flying fig about it.
>>>
>>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Truism:
>>>>>> Every simulation that would never stop unless Halts() stops
>>>>>> it at some point specifies infinite execution.
>>>>>
>>>>> Any algorithm that implements this truism is, of course, a halting
>>>>> decider.
>>> I find your endless quoting of this peculiar because you disagree with
>>> it! You adamantly state that you don't have a halt decider (as I and
>>> the world defines is). Are your really saying that you have such an
>>> algorithm? We know you have a partial POOH decider, but that's not what
>>> I mean when I talk of a halt decider.
>>>
>>> No comment of course on your mistake. It's too serious and too obvious
>>> to do anything but deflect attention from it. Your "⟨Ĥ⟩ ⟨Ĥ⟩ does not
>>> encode a halting computation" can not be justified.
>>
>> It is justified on the basis that it meets the
>> Simulating Halt Decider Theorem (Olcott 2020)
>> non halting criteria that you agreed to.
>
> But not on the basis of what a halt decider is.
>

You already agreed that it <is> a halting decider, any reversal on this
can only be construed as deception.

> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The difference in the behavior of the Ĥ at the beginning of the above
template and the behavior of the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is accounted
for by the fact that these are distinctly different computations that
are not computationally equivalent.

This is much more easily understood by the H(P,P) model where every
detail is explicitly specified and no details are left to the
imagination. The very preliminary very rough draft of this analysis is
currently on page 7 of this paper.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

The basic idea that two distinctly different computations are not
required to have the same behavior is very obviously correct common
knowledge.

The analysis of how these intuitively identical computations are
actually distinctly different is the only difficult aspect of this. The
verified fact that their correct x86 execution trace is not the same
conclusively proves that they are distinctly different computations,
thus can have different behavior without contradiction.

The same function with the same input must derive identical results or
the results are not a pure function of its inputs.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

In the above computation the computational distinction between Ĥ.qx that
transitions to its final state of Ĥ.qn and its input ⟨Ĥ1⟩ ⟨Ĥ2⟩ that
never transitions to any final state is that the execution of Ĥ.qx is
the outer-most instance of what would otherwise be an infinite set of
nested simulations.

It is the only instance of Ĥ.qx that is not under the dominion of
another instance of Ĥ.qx. This makes this outermost instance
computationally distinct from the inner instances.

>> Are you going to try to doubletalk your way out of that one?
>
> It would be a waste of everyone's time but would serve you well as a
> distraction from a, b and c. What matters (or should matter to you) is
> that you are obviously wrong. That remains true even if I were to agree
> with everything you have ever said.
>

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]

<WKmdnbc68LLPBb_8nZ2dnUU7-LHNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7276&group=comp.ai.philosophy#7276

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 Aug 2021 13:32:50 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com> <87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 22 Aug 2021 13:32:48 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <WKmdnbc68LLPBb_8nZ2dnUU7-LHNnZ2d@giganews.com>
Lines: 165
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-uKfuqxQILMzWrhNQqPCk1gdKa7sGS4xKHh8F5IaXkEh9pIEc34COeHZs7K2uzQt4WSCiyCQVxllz8tc!CoSjftQ+Rq015FxP4NM3HBrpCa5lBKsfxOQ4tVtOZSWaheW5me81LTbyws+zzDIuxp3hbsSjw/W/!38Y=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8593
 by: olcott - Sun, 22 Aug 2021 18:32 UTC

On 8/22/2021 12:18 PM, olcott wrote:
> On 8/22/2021 11:14 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 9:34 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/21/2021 8:27 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/21/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> It is trivially easy for me to understand that the simulation
>>>>>>>>> of ⟨Ĥ1⟩
>>>>>>>>> ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops running
>>>>>>>>> unless
>>>>>>>>> this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>>>>>>>>
>>>>>>>> You are reduced to saying things not in dispute as if they
>>>>>>>> change any of
>>>>>>>> the facts you are wrong about.
>>>>>>>
>>>>>>> You never agreed to this before.
>>>>>> Don't be silly.  I even gave this problem a name: "PO's Other
>>>>>> Halting"
>>>>>> problem.  You remember the POOH problem?  What happens "unless"
>>>>>> (rather
>>>>>> than what actually happens) is the same silly ruse you've been
>>>>>> pulling
>>>>>> for years.
>>>>>>
>>>>>>> Now we apply this Theorem:
>>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>>> A simulating halt decider correctly decides that any input that
>>>>>>> never
>>>>>>> halts unless the simulating halt decider aborts its simulation of
>>>>>>> this
>>>>>>> input is an input that never halts.
>>>>>>
>>>>>> This is not a theorem but the definition of what "correct" means
>>>>>> for the
>>>>>> POOH problem.  A problem no one else cares about.
>>>>>
>>>>> You have already agreed to it:
>>>> Yes, I have agreed that you get to define what the correct answer is
>>>> for
>>>> any instance of the POOH problem.  The wold continues to spin and no
>>>> one
>>>> gives a flying fig about it.
>>>>
>>>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Truism:
>>>>>>> Every simulation that would never stop unless Halts() stops
>>>>>>> it at some point specifies infinite execution.
>>>>>>
>>>>>> Any algorithm that implements this truism is, of course, a halting
>>>>>> decider.
>>>> I find your endless quoting of this peculiar because you disagree with
>>>> it!  You adamantly state that you don't have a halt decider (as I and
>>>> the world defines is).  Are your really saying that you have such an
>>>> algorithm?  We know you have a partial POOH decider, but that's not
>>>> what
>>>> I mean when I talk of a halt decider.
>>>>
>>>> No comment of course on your mistake.  It's too serious and too obvious
>>>> to do anything but deflect attention from it.  Your "⟨Ĥ⟩ ⟨Ĥ⟩ does not
>>>> encode a halting computation" can not be justified.
>>>
>>> It is justified on the basis that it meets the
>>> Simulating Halt Decider Theorem (Olcott 2020)
>>> non halting criteria that you agreed to.
>>
>> But not on the basis of what a halt decider is.
>>
>
> You already agreed that it <is> a halting decider, any reversal on this
> can only be construed as deception.
>
>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> The difference in the behavior of the Ĥ at the beginning of the above
> template and the behavior of the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is accounted
> for by the fact that these are distinctly different computations that
> are not computationally equivalent.
>
> This is much more easily understood by the H(P,P) model where every
> detail is explicitly specified and no details are left to the
> imagination. The very preliminary very rough draft of this analysis is
> currently on page 7 of this paper.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> The basic idea that two distinctly different computations are not
> required to have the same behavior is very obviously correct common
> knowledge.
>
> The analysis of how these intuitively identical computations are
> actually distinctly different is the only difficult aspect of this. The
> verified fact that their correct x86 execution trace is not the same
> conclusively proves that they are distinctly different computations,
> thus can have different behavior without contradiction.
>
> The same function with the same input must derive identical results or
> the results are not a pure function of its inputs.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> In the above computation the computational distinction between Ĥ.qx that
> transitions to its final state of Ĥ.qn and its input ⟨Ĥ1⟩ ⟨Ĥ2⟩ that
> never transitions to any final state is that the execution of Ĥ.qx is
> the outer-most instance of what would otherwise be an infinite set of
> nested simulations.
>
> It is the only instance of Ĥ.qx that is not under the dominion of
> another instance of Ĥ.qx. This makes this outermost instance
> computationally distinct from the inner instances.
>

The executed instances of H(P,P) are distinctly different computations
than the simulated instances in that the executed instances are not
under the dominion of a halt decider. It is this difference that enables
them to have different behavior.

// 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((u32)P);
}

>>> Are you going to try to doubletalk your way out of that one?
>>
>> It would be a waste of everyone's time but would serve you well as a
>> distraction from a, b and c.  What matters (or should matter to you) is
>> that you are obviously wrong.  That remains true even if I were to agree
>> with everything you have ever said.
>>
>
>

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]

<xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7277&group=comp.ai.philosophy#7277

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 Aug 2021 15:06:06 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com> <87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com> <87czq5i9u0.fsf@bsb.me.uk> <srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com> <87y28tgt3w.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 22 Aug 2021 15:06:03 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87y28tgt3w.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com>
Lines: 45
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-deOl3B5l/e/JhqSLvaUXKLfNrcu9HxXS6aTFdTLkXRk4uXvSugqoxfdeBXv/Y3mSJaX2azvoL20/a65!lFkAFAAKr8dwrpmk8ZYaqfilXz4uI/5KbQd1dUvDbTrkoQZyu/udv2i8guUVKIWyZddr1IPYn/of!W9o=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3978
 by: olcott - Sun, 22 Aug 2021 20:06 UTC

On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> (anything to avoid addressing the incontrovertible facts)
>
>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>
>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>
>>> I take it you agree with a, b and c since you make no comment about
>>> them. If you do not agree, you need to say which ones you disagree
>>> with.
>
> You have not said which of a, b or c you deny. I don't want to put
> words in your mouth (what sort of person would do that, eh?) but I will
> have to assume you agree with them all if you don't say.
>

As I have already explained in complete detail your simplistic analysis
conflates together two distinctly different computations:
(1) Executed Ĥ applied to ⟨Ĥ⟩ // can't be aborted

(2) Simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ by a simulating halt decider
// can be and is aborted.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The execution of Ĥ is computationally distinct from the simulation of
⟨Ĥ1⟩ ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx so the fact that Ĥ.qx
transitions to its final state of Ĥ.qn does not contradict the fact that
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ correctly decides that its input never halts.

THIS SEEMS BEYOND YOUR CAPACITY TO COMPREHEND:
The executed instances of Ĥ are not under the dominion of a simulating
halt decider that can abort them before they get started. This
conclusively proves that they can have different behavior without
forming any contradiction.

--
Copyright 2021 Pete Olcott

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

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor