Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Vini, vidi, Linux! -- Unknown source


computers / comp.ai.philosophy / How do we know that the input to H(P,P) really never halts?

SubjectAuthor
* How do we know that the input to H(P,P) really never halts?olcott
+- Re: How do we know that the input to H(P,P) really never halts? [olcott
+* Re: How do we know that the input to H(P,P) really never halts?olcott
|+- Re: How do we know that the input to H(P,P) really never halts?olcott
|`- Re: How do we know that the input to H(P,P) really never halts?olcott
+- Re: How do we know that the input to H(P,P) really never halts?olcott
`- Re: How do we know that the input to H(P,P) really never halts?olcott

1
How do we know that the input to H(P,P) really never halts?

<VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic comp.ai.philosophy sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 30 Oct 2021 21:44:56 -0500
Date: Sat, 30 Oct 2021 21:44:54 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy,sci.math
Content-Language: en-US
From: NoO...@NoWhere.com (olcott)
Subject: How do we know that the input to H(P,P) really never halts?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com>
Lines: 21
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-0TJ9d9ZGQFTb9MsQUVvJbVQbtxVC8hxSq38JklkMGjGJjdDSKmsp/u+qDTZoqFyiGbwsGuEA3KdWIuy!/Uxtk164dwyTfrCFcy1gwqXYquN0EfubbsgAwFTmWji89kr1BIMchlXgEevvz2O8NIxZxIoq4XvN!Rw==
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: 1908
 by: olcott - Sun, 31 Oct 2021 02:44 UTC

When we examine pages 4 and 5 and hypothesize
that H is merely a pure simulator we can see
that when P calls H at its machine address 0xc41
that this **is** infinitely nested simulation
such that P never reaches its final state.

The only other possibility is that H is a halt
decider that aborts its simulation of P at the
machine address 0xc41 of P. In this case P also
never reaches is final state at machine address
0xc50. Thus in every possibility P never reaches
its final state and thus never halts.

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

--
Copyright 2021 Pete Olcott

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

Re: How do we know that the input to H(P,P) really never halts? [ H(P,P)==0 is necessarily correct ]

<hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!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: Sun, 31 Oct 2021 09:41:44 -0500
Date: Sun, 31 Oct 2021 09:41:41 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: How do we know that the input to H(P,P) really never halts? [
H(P,P)==0 is necessarily correct ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com>
<pHufJ.7096$lz3.140@fx34.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <pHufJ.7096$lz3.140@fx34.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
Lines: 170
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5ZjAKOQqsfSoFUT/TekdPtYzKkfc8UIfR1g4r6rU97rxig4aMMpIPdee4I7NR9XyeOY1VdZMkTPGYNE!b02DutYMliLXhv4X+j6fK75CAuCBkNOTdxQmxRg0A7wItYtPRCYpK/jnbrgRr4yeKDXEvuBtkHM2!4A==
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: 8210
 by: olcott - Sun, 31 Oct 2021 14:41 UTC

On 10/31/2021 6:00 AM, Richard Damon wrote:
>
> On 10/30/21 10:44 PM, olcott wrote:
>> When we examine pages 4 and 5 and hypothesize
>> that H is merely a pure simulator we can see
>> that when P calls H at its machine address 0xc41
>> that this **is** infinitely nested simulation
>> such that P never reaches its final state.
>>
>> The only other possibility is that H is a halt
>> decider that aborts its simulation of P at the
>> machine address 0xc41 of P. In this case P also
>> never reaches is final state at machine address
>> 0xc50. Thus in every possibility P never reaches
>> its final state and thus never halts.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>
> Yes, if H IS a 'pure simulator', then H^/P will be non-halting. But H
> doesn't get this case right, as H never answers.
>
> This fact ONLY applies if H is actually a Pure Simulator, and in no
> other case.
>

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

The input to H(P,P) never reaches its final state at its machine address
0xc50 whether or not H(P,P) aborts the simulation of this input
therefore we can definitely conclude that the input to H(P,P) never halts.

> In your second case, yes, the partial simulation by H of P does not
> reach a halting state, but that does NOT show that P is non-halting, to
> claim it does is a logical failicy.
>

If we examine every possible case and find that the input to H(P,P)
never reaches its final state in any of them then it is necessarily true
that the input to H(P,P) never halts.

> We do see that if H aborts its simulation of a copy of P and returns
> non-halting, then another copy of P that uses a copy of this H will get
> that non-halting answer and then Halt,

Not in the above case.

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

H(P,P) is simulating its input. P invokes another instance of H to
simulate itself. When this second P is about to invoke another instance
of H, the outermost H aborts its outermost P thus terminating the entire
simulation hierarchy.

So the question comes down to this:
(a) If H(P,P) never aborts the simulation of its input then its input
never reaches its final state.
(b) If H(P,P) aborts the simulation of its input then its input never
reaches its final state.

If H aborts the simulation of its input then the whole simulation
hierarchy has been aborted because the whole simulation hierarchy
depends on the execution of the outermost P.

> showing us that P(P) is actually
> a Halting Computation.
>
> You mistaken claim that a partial simulation shows non-halting or that
> you can use different Hs when running P by itself vs what the halt
> decider is.
>

I have shown that the input to H(P,P) never reaches its final state in
every possible case therefore it is necessarily correct that the input
to H(P,P) never halts.

> Note, your claim that you can replace the simulation of a machine with
> the direct execution of that machine ONLY applies if the simulation is
> truely 'pure' or never aborted, so using that model implies that H can
> only be that real pure simulator that we have shown never answers H(P,P)
> and thus fails to meet the basic requirements of a halt decider.
>
> The transform does NOT apply to a 'pure simulator until...' machine.

--
Copyright 2021 Pete Olcott

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

Re: How do we know that the input to H(P,P) really never halts?

<sfOdnV1KyMELJuP8nZ2dnUU7-aHNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 31 Oct 2021 10:51:50 -0500
Date: Sun, 31 Oct 2021 10:51:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: How do we know that the input to H(P,P) really never halts?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com>
<87fsshtej8.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87fsshtej8.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <sfOdnV1KyMELJuP8nZ2dnUU7-aHNnZ2d@giganews.com>
Lines: 119
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9HzF84/l+KeHntZyGp5dS1MiIN6JjX7gUpwEe901oS94I3cJI1kmsCF/rpa5n4MmmLA3siOZY8fzsB1!/k6RJPoz7grqwqC+tQXXaMNEv5nXTV4LxAcHvNpKZiQIVi5M1JyUKqCTUd4NuHX+uejpKLPoTHlT!Pg==
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: 5971
 by: olcott - Sun, 31 Oct 2021 15:51 UTC

On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The only other possibility is that H is a halt
>> decider that aborts its simulation of P at the
>> machine address 0xc41 of P. In this case P also
>> never reaches is final state at machine address
>> 0xc50. Thus in every possibility P never reaches
>> its final state and thus never halts.
>
> So having lost the argument in relation to Turing machines, you have
> returned to your hidden code that gets the wrong answer?

(1) I haven't lost the argument on Turing Machines.

(2) I conclusively prove that the input to H(P,P) never halts in
Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
Giganews posted this message to other groups and skipped itself.

> Or do you now
> accept that H(P,P) == false is wrong if P(P) halts? To get any traction
> you really do have to admit that defining the wrong answer to be the
> right one simply did not cut it!
>
> By playing tricks (which will remain as hidden as your code) you can
> arrange for H(P,P) == true when P(P) halts which would be a welcome
> change of heart.
>

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

The above is from pages 4 and 5 of this paper:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

There are no tricks. There are only two possible cases:
(1) H(P,P) aborts its simulation and P never reaches its final state at
0xc50

(2) H(P,P) does not abort its simulation and P never reaches its final
state at 0xc50

Therefore when H(P,P) decides that its input never halts H is
necessarily correct.

--
Copyright 2021 Pete Olcott

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

Re: How do we know that the input to H(P,P) really never halts?

<07idnecMENQ-WOP8nZ2dnUU7-KfNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.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, 31 Oct 2021 11:34:43 -0500
Date: Sun, 31 Oct 2021 11:34:40 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: How do we know that the input to H(P,P) really never halts?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com>
<6553c55d-cd89-4b64-97fd-0d49c2836434n@googlegroups.com>
<Fuidndt6hY86OeP8nZ2dnUU7-VPNnZ2d@giganews.com>
<aa3be7a0-dbad-4895-8457-e3441c4aa9bbn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <aa3be7a0-dbad-4895-8457-e3441c4aa9bbn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <07idnecMENQ-WOP8nZ2dnUU7-KfNnZ2d@giganews.com>
Lines: 92
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-qrRmPKx/nX/x9l+aObC2NDiCEwc2PYO5Vs2gfJWkLpBt1BjgloVpDqlcbrFIi9zckhYr0bJ4QzkClf3!GcIS5Q8cNpSLbfQKMCkTkDuIZvqvtg1rHopmvMs4G+X/tmwJHc8Dx5kp+TYnK2zNZpUJ6UUYp9hm!FQ==
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: 5378
 by: olcott - Sun, 31 Oct 2021 16:34 UTC

On 10/31/2021 10:47 AM, wij wrote:
> On Sunday, 31 October 2021 at 22:14:07 UTC+8, olcott wrote:
>> On 10/30/2021 11:01 PM, wij wrote:
>>> On Sunday, 31 October 2021 at 10:45:03 UTC+8, olcott wrote:
>>>> When we examine pages 4 and 5 and hypothesize
>>>> that H is merely a pure simulator we can see
>>>> that when P calls H at its machine address 0xc41
>>>> that this **is** infinitely nested simulation
>>>> such that P never reaches its final state.
>>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>>>
>>> P exists only after the existence of H. No H, no P.
>>> Your H is specific for some 'P' already existent before H.
>>> Your understanding and implement are not what you think.
>>>
>>> GUR dictates that:
>>> ...
>>> No function f can decide the property of another function g that g can defy.
>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>> ...
>>>
>> I show all of the details of how we can know that when H(P,P) does not
>> abort its simulation of its input then its input never reaches its final
>> state. We can also see that its input never reaches its final state even
>> if H(P,P) aborts its input therefore we can know that under all possible
>> conditions the input to H(P,P) does not halt.
>>
>> You have to exactly look at pages 4 and 5 to see this:
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> On page 4:
> The word 'partial' in the title "Simulating partial halt decider H correctly decides that P(P) never halts (V1)" bugged me.
>

The "partial" halt decider takes every COFF object file that has
been generated by the Microsoft C compiler. There are a limited
number of non-halting behavior patterns that H can recognize.

As soon as it recognizes one of these patterns in its simulated input
it aborts the simulation of this input and reports non-halting. H
merely waits for its input to halt in all other cases. Some of these
cases are inputs that never halt where it does not recognize the
non-halting behavior pattern.

> On page 5:
> 1. Your H does not actually take any 'given input'.
> 2. What language (or model) C, x86 assembly, or TM are you using?
> None of these three languages are easy to take 'machine description' as input.
> You chose a hard(impossible, by GUR) way to tackle the problem.
>
> If I understand correctly, you seem to emphasize the fact that H can correctly
> decide whether its P will halt or not. I have no doubt of your case.
> But, for the conventional HP, P does not exist before H is created. Hard coding
> P into H is simply wrong. It is not a decider of any given real program.
>

H correctly decides the halt status of:
(a) Simple Infinitely nested simulation
(b) Simple Infinite recursion
(c) Simple Infinite loops

H(P,P) can see that its input never reaches its final state whether or
not H aborts the simulation of this input (thus all possible cases)
therefore H is necessarily correct when it aborts the simulation of this
input and reports non-halting.

--
Copyright 2021 Pete Olcott

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

Re: How do we know that the input to H(P,P) really never halts?

<a8-dnWfrB9r2VeP8nZ2dnUU7-SnNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 31 Oct 2021 11:46:35 -0500
Date: Sun, 31 Oct 2021 11:46:32 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: How do we know that the input to H(P,P) really never halts?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com>
<6553c55d-cd89-4b64-97fd-0d49c2836434n@googlegroups.com>
<Fuidndt6hY86OeP8nZ2dnUU7-VPNnZ2d@giganews.com> <87a6iptb4f.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87a6iptb4f.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <a8-dnWfrB9r2VeP8nZ2dnUU7-SnNnZ2d@giganews.com>
Lines: 104
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SThmLBgXAvahWaeLzv2j62y+rPgiiM1O6RoWhwsTi9kKpZBc9lWSVfgKxuPw6sGkhYap/huHzh/EUtP!JQPI7RX4O0QJ1+K9sKMnndZw8fyfrAkgXbcVtOzU9hyer5Pwa38q5NOkk3J0AotS6Yqh8e4ygEHB!gg==
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: 5456
 by: olcott - Sun, 31 Oct 2021 16:46 UTC

On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I show all of the details of how we can know that when H(P,P) does not
>> abort its simulation of its input then its input never reaches its
>> final state.
>
> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
> details. The most important details -- in the code for H -- are going
> to remain hidden forever.
>

If H is a pure simulator of its input then the function call to H at the
machine address 0xc41 of P specifies infinitely nested simulation
preventing P from ever reaching its final state of machine address 0xc50.

If H aborts its simulation of P at the machine address of P of 0xc41
then P never reaches its final state of machine address 0xc50.

Therefore in all possible cases:
(a) H(P,P) aborts its simulation of its input
(b) H(P,P) does not abort its simulation of its input
P never reaches its final state at machine address 0xc50.

Details shown below:

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

--
Copyright 2021 Pete Olcott

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

Re: How do we know that the input to H(P,P) really never halts?

<1tKdnZzc_afHReP8nZ2dnUU7-U3NnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!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: Sun, 31 Oct 2021 12:54:34 -0500
Date: Sun, 31 Oct 2021 12:54:32 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: How do we know that the input to H(P,P) really never halts?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com>
<87fsshtej8.fsf@bsb.me.uk> <sfOdnV1KyMELJuP8nZ2dnUU7-aHNnZ2d@giganews.com>
<UuAfJ.8660$831.1148@fx40.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <UuAfJ.8660$831.1148@fx40.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <1tKdnZzc_afHReP8nZ2dnUU7-U3NnZ2d@giganews.com>
Lines: 169
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-2tRfYqkc4vsRornCrnl//plQoAFYWyFlq3qBVHtLb6TLXmgQKdWsZmNoP9uEhh801RF65uSs6xIyTx1!Vb7ih/c9tfhIBrK3PEr8tCIOUcTUQY4dxmbaTK1/DX6/bzkWS5UGJUjzQsxm/GkgZotc6r/kdqdu!hg==
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: 8462
 by: olcott - Sun, 31 Oct 2021 17:54 UTC

On 10/31/2021 12:36 PM, Richard Damon wrote:
> On 10/31/21 11:51 AM, olcott wrote:
>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>>
>>> So having lost the argument in relation to Turing machines, you have
>>> returned to your hidden code that gets the wrong answer?
>>
>> (1) I haven't lost the argument on Turing Machines.
>
> Only because you haven't actually made a real arguemnt on Turing Machines.
>
>>
>> (2) I conclusively prove that the input to H(P,P) never halts in
>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>> Giganews posted this message to other groups and skipped itself.
>
> Except that is a meaningless statement.
>
> 'Inputs' don't halt. Machines Halt.
>
> When the input <H^><H^> is given to a UTM, that computation Halts, which
> is one of the ways to look at the definition of the Halting Problem.
>
> Yes, H's aborted simulation of <H^><H^> never reached a final halting
> state, but aborted simulation NEVER, in themselves, prove non-halting
> (or Halting). So you are arguing about meaningless behavior trying to
> claim that it actually means something by using bad terminology.
>
>>
>>>  Or do you now
>>> accept that H(P,P) == false is wrong if P(P) halts?  To get any traction
>>> you really do have to admit that defining the wrong answer to be the
>>> right one simply did not cut it!
>>>
>>> By playing tricks (which will remain as hidden as your code) you can
>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>> change of heart.
>>>
>>
>> // 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
>>
>> The above is from pages 4 and 5 of this paper:
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> There are no tricks. There are only two possible cases:
>> (1) H(P,P) aborts its simulation and P never reaches its final state
>> at 0xc50
>>
>> (2) H(P,P) does not abort its simulation and P never reaches its final
>> state at 0xc50
>>
>> Therefore when H(P,P) decides that its input never halts H is
>> necessarily correct.
>>
>
> You are just arguing POOP.
>
> The fact that H doesn't reach the halting state is irrelevent to the
> halting problem.
>

I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.

H either aborts the simulation of its input or does not abort the
simulation of its input.

(1) H(P,P) aborts its simulation and 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50

(2) H(P,P) does not abort its simulation and
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50

Therefore when H(P,P) decides that its input never halts H is
necessarily correct.

--
Copyright 2021 Pete Olcott

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

Re: How do we know that the input to H(P,P) really never halts?

<c8idnbFAF6C8QuP8nZ2dnUU7-avNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr3.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, 31 Oct 2021 13:23:29 -0500
Date: Sun, 31 Oct 2021 13:23:29 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Subject: Re: How do we know that the input to H(P,P) really never halts?
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <VsidnV3S8_61nuP8nZ2dnUU7-UfNnZ2d@giganews.com> <87fsshtej8.fsf@bsb.me.uk> <sfOdnV1KyMELJuP8nZ2dnUU7-aHNnZ2d@giganews.com> <874k8xt7db.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <874k8xt7db.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <c8idnbFAF6C8QuP8nZ2dnUU7-avNnZ2d@giganews.com>
Lines: 195
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Z0KKFaa86bssSJZfg/LytWnBT1iJqY+Qpf/p4HZiJkyuvBWyTUK8UXLH27lkIXL1vJt8hNWAcZvkMMU!qmqGY5bQ20TlLIqvS/X1FlQo3lI+BrPLW0HpPge0J7eiNIKl4cya5nf0e9M44KLgqAXnKcz/P414!Sw==
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: 9140
 by: olcott - Sun, 31 Oct 2021 18:23 UTC

On 10/31/2021 12:46 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>> So having lost the argument in relation to Turing machines, you have
>>> returned to your hidden code that gets the wrong answer?
>>
>> (1) I haven't lost the argument on Turing Machines.
>>
>> (2) I conclusively prove that the input to H(P,P) never halts in
>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>> Giganews posted this message to other groups and skipped itself.
>
> The input to H represents the computation P(P). At least up until
> recently you asserted that P(P) halts and you spent a lot of time trying
> to hand-wave away the wrong answer from H.
>
>>> Or do you now
>>> accept that H(P,P) == false is wrong if P(P) halts? To get any traction
>>> you really do have to admit that defining the wrong answer to be the
>>> right one simply did not cut it!
>>> By playing tricks (which will remain as hidden as your code) you can
>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>> change of heart.
>
>> There are no tricks.
>
> Good. That means you can't have H(P,P) == true iff P(P) halts.
>
>> There are only two possible cases:
>> (1) H(P,P) aborts its simulation and P never reaches its final state
>> at 0xc50
>>
>> (2) H(P,P) does not abort its simulation and P never reaches its final
>> state at 0xc50
>>
>> Therefore when H(P,P) decides that its input never halts H is
>> necessarily correct.
>
> I can see you don't want to answer.

I have answered, perhaps you are not smart enough to understand the answer?

> I was asking if you have changed
> your mind,

If in both possible cases where H(P,P) aborts the simulation of its
input or H(P,P) fails to abort the simulation of its input P never
reaches its final state at its own machine address of 0xc50 then we know
that P never reaches this final state.

Smart people that understand the x86 language know that when H is a pure
simulator that P does specify infinitely nested simulation at its
machine address 0xc41. Even Richard understands this part.

Smart people that understand the x86 language know that when H aborts
its simulation of P at the machine address of 0xc41 of P that the input
to H(P,P) never reaches its final state of 0xc50.

This means that the following code provides proof that the input to
H(P,P) never reaches its final state of 0xc50 in any possible case, thus
the input to H(P,P) never halts.

The following is taken from pages 4 and 5 of this paper:
Halting problem undecidability and infinitely nested simulation
May 2021 PL Olcott

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

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

> and I know that's very hard for someone in your position to
> admit. Here's the key question: do you still assert that H(P,P) ==
> false is the "correct" answer even though P(P) halts?

Yes that is the correct answer even though P(P) halts.
The fact that in all possible cases the input to H(P,P) never halts
conclusively proves that H(P,P)==0 is correct no matter what.

H1(P,P)==1 is consistent with the behavior of P(P).

The difference between H(P,P) and H1(P,P) is that the former has
pathological self-reference and the latter does not. This makes these
two computations distinct from each other and thus not equivalent.

> If you won't say,
> nothing you do say about what is "correct" (necessarily or otherwise) is
> pointless.
>
> Of course, it's likely you have no changed you mind and you are still
> searching for words to make the wrong answer seems less obviously
> wrong. Not answering my question is a key part of that strategy so I
> don't expect an answer.
>

Pathological self-reference has been my life's work. For other people
where this is not the case it would be much more difficult to
understand. The fact that H reports a halt status that is consistent
with the behavior of its input conclusively proves that H is correct.

The input to H1(P,P) has behavior that is computationally equivalent to
P(P).

The input to H(P,P) does not have behavior that is computationally
equivalent to P(P).

The difference in behavior is caused by pathological self-reference.

--
Copyright 2021 Pete Olcott

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

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor