Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Life sucks, but death doesn't put out at all...." -- Thomas J. Kopp


computers / comp.theory / Re: Conquering the last rebuttal to H(P,P)==0 refutation of the halting problem proofs

Re: Conquering the last rebuttal to H(P,P)==0 refutation of the halting problem proofs

<UNqdnX_o1MjBiSb_nZ2dnUU7_83NnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=35075&group=comp.theory#35075

  copy link   Newsgroups: comp.theory 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!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 28 Jun 2022 09:46:52 -0500
Date: Tue, 28 Jun 2022 09:46:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Conquering the last rebuttal to H(P,P)==0 refutation of the
halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math
References: <PqadncNqadjPDST_nZ2dnUU7_8zNnZ2d@giganews.com>
<f5adnZz_oeLyLST_nZ2dnUU7_8zNnZ2d@giganews.com>
<c4f7fa35-d1a7-4e55-b230-4253bf0a7256n@googlegroups.com>
<Sv-dnX5Vh499eyT_nZ2dnUU7_8zNnZ2d@giganews.com>
<fc96a583-3a51-45fd-8275-4bc8aaca8fc0n@googlegroups.com>
<Lfudna-pu95HbyT_nZ2dnUU7_83NnZ2d@giganews.com>
<8bca30ba-3f3f-4b76-b401-504b4873e55en@googlegroups.com>
<c5e0f904-cd76-493c-8e40-4ceee0fdb605n@googlegroups.com>
<s8ednRTcbPnnhSf_nZ2dnUU7_83NnZ2d@giganews.com>
<71b90384-d502-4a24-a1a7-b6f7548e0ebbn@googlegroups.com>
<pcudnZlH9bNmgSf_nZ2dnUU7_83NnZ2d@giganews.com>
<f0391029-35e5-4e6f-90f1-dfdf23672b9an@googlegroups.com>
<h-adnYr3jJSuvif_nZ2dnUU7_83NnZ2d@giganews.com>
<6f94d7fa-7fe3-4bd5-8f91-e9ca40f2d34cn@googlegroups.com>
<DOWdnQ8KZpiFtSf_nZ2dnUU7_8zNnZ2d@giganews.com>
<3266962b-052a-4afe-b544-7afe3ce73f40n@googlegroups.com>
<Lpudne_5E-1fkSb_nZ2dnUU7_8zNnZ2d@giganews.com>
<d24daf9a-94ba-4261-98ce-573e52281f99n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <d24daf9a-94ba-4261-98ce-573e52281f99n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <UNqdnX_o1MjBiSb_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 306
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-iZGiuy6NZ84IT7hSiUullertBchAZyai1CmFImr2zkIbbOWa3mTCke9i8JHpDadlyXSzFWZj6lJzKvP!+YxA4FDjldLWzdYnGm2sj9xLssbQzIl6lrFcDRZm9IfkGZFqQpZ1tK47Yhn3Jsbjye7ClkWjt82e
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: 20507
 by: olcott - Tue, 28 Jun 2022 14:46 UTC

On 6/28/2022 9:22 AM, Dennis Bush wrote:
> On Tuesday, June 28, 2022 at 10:14:33 AM UTC-4, olcott wrote:
>> On 6/27/2022 5:03 PM, Dennis Bush wrote:
>>> On Monday, June 27, 2022 at 5:58:55 PM UTC-4, olcott wrote:
>>>> On 6/27/2022 4:46 PM, Dennis Bush wrote:
>>>>> On Monday, June 27, 2022 at 5:38:02 PM UTC-4, olcott wrote:
>>>>>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>>>>>> On Monday, June 27, 2022 at 5:11:30 PM UTC-4, olcott wrote:
>>>>>>>> On 6/27/2022 4:02 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, June 27, 2022 at 4:52:17 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/27/2022 2:45 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, June 27, 2022 at 2:13:44 PM UTC-4, Dennis Bush wrote:
>>>>>>>>>>>> On Monday, June 27, 2022 at 2:11:45 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 6/27/2022 1:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Monday, June 27, 2022 at 1:20:39 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 6/27/2022 12:03 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 9:28:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/27/2022 7:58 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:50:05 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:40 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:34:22 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 7:26 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 8:14:31 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/27/2022 6:57 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Monday, June 27, 2022 at 7:11:21 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> *This is the outline of the complete refutation*
>>>>>>>>>>>>>>>>>>>>>>>>> *of the only rebuttal that anyone has left*
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> (a) The complete and correct x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>>>>> never reaches the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is known that H aborts its simulation and returns 0. That means that H *by definition* does not perform a complete and correct emulation. And since H (if it was constructed correctly) is a pure function of its inputs, it will ALWAYS return the same return for a given input.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> To state that H aborts *and* does a complete and correct simulation is simply nonsense.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> What *does* perform a complete and correct emulation of the input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The above two are proven to be verified facts entirely on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>> the semantics of the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> A nonsense statement can't be a "fact", verified or otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Which for H(P,P) is BY DEFINITION is the behavior of P(P). The halting problem says that H MUST implement the following mapping (i.e. the halting function):
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H does not perform this mapping.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> P(P) is provably not the actual behavior of the actual input.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is BY DEFINITION. So if H comes up with something different that means it did something wrong, specifically it aborted a halting computation too soon.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6](01) 50 push eax
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa](01) 51 push ecx
>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb](05) e820feffff call 00001020
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> [00001200](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>> [00001203](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>> [00001205](02) 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>> [00001207](02) ebfe jmp 00001207
>>>>>>>>>>>>>>>>>>>>>>>>> [00001209](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000120a]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _main()
>>>>>>>>>>>>>>>>>>>>>>>>> [00001210](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>> [00001218](05) e8d3ffffff call 000011f0
>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>> [00001220](02) 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>> [00001222](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001223](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0020) [00001223]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>>>>>>>>> [00001210][00101fba][00000000] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001211][00101fba][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
>>>>>>>>>>>>>>>>>>>>>>>>> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][00101fae][00101fba] 55 push ebp // enter executed P
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][00101fae][00101fba] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00101faa][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00101fa6][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Begin Simulation Execution Trace Stored at:21206e
>>>>>>>>>>>>>>>>>>>>>>>>> Address_of_H:1020
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f1][0021205a][0021205e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f6][00212056][000011f0] 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>> [000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [000011fa][00212052][000011f0] 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
>>>>>>>>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>>>>>>>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise infinitely
>>>>>>>>>>>>>>>>>>>>>>>>> recursive emulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> FALSE. P contains these instructions:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
>>>>>>>>>>>>>>>>>>>>>>>> &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> That *can* and *do* prevent infinite recursive emulation in a *correct* and *complete* emulation
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And in doing so it fails to see that the call to H, since H is a computation, will aborts *its* simulation of P and return 0 to the outer P being emulated, which would cause it to halt, making H(P,P)==0 wrong.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> [00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>> [00001203][00101fae][00101fba] 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>> [00001205][00101fae][00101fba] 7402 jz 00001209
>>>>>>>>>>>>>>>>>>>>>>>>> [00001209][00101fb2][0000121d] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [0000120a][00101fb6][000011f0] c3 ret // return from
>>>>>>>>>>>>>>>>>>>>>>>>> executed P
>>>>>>>>>>>>>>>>>>>>>>>>> [0000121d][00101fba][00000000] 83c404 add esp,+04
>>>>>>>>>>>>>>>>>>>>>>>>> [00001220][00101fba][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>> [00001222][00101fbe][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001223][00101fc2][00000000] c3 ret // ret from main
>>>>>>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(878) / 67 = 13 pages
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I've stated in detail why you're wrong. Now you need to explain in detail why I'm wrong.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Failure to do so, which includes simply restating your original point, will be taken as admission that what I've stated is correct.
>>>>>>>>>>>>>>>>>>>>>>> H correctly predicts that its complete and correct x86 emulation of its
>>>>>>>>>>>>>>>>>>>>>>> input never reaches the the "ret" instruction of P.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This is the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> P(P) is not the actual behavior of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Never reaching the "ret" instruction means that P does not halt.
>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>>>>>>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>> Therefore H(P,P)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> And again, repeating your original point.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So no explanation as to why I'm wrong, just a repetition of your original points.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That means you accept that what I've said is true, and that H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>>>> You rebuttal is based on rejecting the verified fact that a simulating
>>>>>>>>>>>>>>>>>>>>> halt decider correctly predicts that its correctly simulated input will
>>>>>>>>>>>>>>>>>>>>> never reach the final state "ret" instruction of this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> FALSE. The correctly simulated input to H(P,P) is UTM(P,P) which halts, therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>>>> First of all I am not talking about UTM's.
>>>>>>>>>>>>>>>>>>> I am talking about x86 emulation.
>>>>>>>>>>>>>>>>>>> Try to encode what you mean, here is my guess:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> if (emulate_x86(x, x))
>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> P is a computation and therefore it can't be changed, nor can anything that it calls. I mean UTM(P,P). The simplest way to implement this is:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void UTM(u32 x, u32 y)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> x(y)
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H cannot by definition perform a correct and complete emulation if it aborts, so the input must be passed to something that does, i.e. a UTM, for the source of truth.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A simulating halt decider correctly simulates its input until it
>>>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But H isn't such a decider, because the simulated input does reach a final state when correctly simulated, i.e. by UTM(P,P), therefore H(P,P)==0 is wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every simulating decider that correctly simulates its input until it
>>>>>>>>>>>>>>> correctly determines that this simulated input would never reach its
>>>>>>>>>>>>>>> final state correctly determines the halt status of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And H isn't such a decider, because it does not correctly determine that the input to H(P,P) would never halt as demonstrated by UTM(P,P) halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The specification for H:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>>>>>>> H(x,y)==1 if and only if x(y) halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H does not meet the specification.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> The spec is provably incorrect in this case:
>>>>>>>>>>>> A spec can't be incorrect. It just is. If it can't be satisfied, then that validates the halting problem proofs that say it can't be satisfied.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No response to this I see. So you agree that your H does not meet the above spec that the halting problem requires?
>>>>>>>>>> You are just playing word games so I will use a different word:
>>>>>>>>>> "criterion measure".
>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>> specified by these inputs.
>>>>>>>>>
>>>>>>>>> As per this specification:
>>>>>>>>>
>>>>>>>>> H(x,y)==0 if and only if x(y) does not halt, and
>>>>>>>>> H(x,y)==1 if and only if x(y) halts
>>>>>>>>>
>>>>>>>>> Which means the actual behavior of the actual input to H(P,P) is defined to be the behavior of P(P).
>>>>>>>>>
>>>>>>>>> Remember, the halting problem is ultimately about algorithms, not some simulator's simulation of it.
>>>>>>>>>
>>>>>>>>> This also means that if the result of H(P,P) doesn't match the behavior of P(P) then H is wrong by definition.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> P(P) is provably not the actual behavior of the actual input,
>>>>>>>>>
>>>>>>>>> If you mean that H(P,P) can't simulate its input to a final state, then any simulator that aborts its input for any reason is necessarily correct, which is clearly nonsense.
>>>>>>>> The formal mathematical semantics of the x86 language conclusively
>>>>>>>> proves that P(P) is not the actual behavior of the actual input to H(P,P).
>>>>>>>
>>>>>>> UTM(P,P) halting proves otherwise, demonstrating that H aborted its simulation too soon.
>>>>>> BUSTED!
>>>>>> I GOT YOU NOW!
>>>>>>
>>>>>> How many recursive emulations does H need to wait before its emulated P
>>>>>> to reaches its final instruction?
>>>>>
>>>>> Since H has a fixed algorithm (which we'll refer to as Ha, and the P that calls it we'll refer to as Pa to make that point clear) to to stop after N recursive emulations, it would need to simulate for N+1 emulations. But its fixed algorithm prevents it from simulating any more than N emulations.
>>>>
>>>> "H aborted its simulation too soon."
>>>> Liar liar pants on fire.
>>>
>>> PO-speak for "I know you proved me wrong and I don't know what else to say"

>> It is PO-speak for I just proved that you are lying:
>> On 6/27/2022 4:14 PM, Dennis Bush wrote:
>>> demonstrating that H aborted its simulation too soon.

>> How many recursive emulations must H(P,P) emulate its input until its
>> emulated input reaches the "ret" instruction of the emulated P?
>
> The fixed algorithm of H, which we'll refer to as Ha and the P that calls it we'll refer to as Pa, simulates for N recursive emulations. Therefore the input must be simulated for N+1 recursive emulations. The fixed algorthm Ha is unable to simulate for this many cycles and therefore gets the wrong answer.
>

*Because I boxed you into a corner* you are finally implicitly admitting
that there is no integer value N number of cycles of recursive emulation
that H(P,P) can emulate its input such that the emulated P reaches its
final state "ret" instruction.

--
Copyright 2022 Pete Olcott

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

SubjectRepliesAuthor
o Conquering the last rebuttal to H(P,P)==0 refutation of the halting

By: olcott on Mon, 27 Jun 2022

201olcott
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor