Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Been through Hell? Whaddya bring back for me?" -- A. Brilliant


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

<Lpudne_5E-1fkSb_nZ2dnUU7_8zNnZ2d@giganews.com>

  copy mid

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

  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!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 28 Jun 2022 09:14:26 -0500
Date: Tue, 28 Jun 2022 09:14:25 -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>
<YNKdnT0wGczrOiT_nZ2dnUU7_8zNnZ2d@giganews.com>
<62035ef4-5a47-47bc-8997-38a3498d26d1n@googlegroups.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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <3266962b-052a-4afe-b544-7afe3ce73f40n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Lpudne_5E-1fkSb_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 298
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-S3RotXr33lttEjRH1NTJsF/G+mVnyBGNR7Q2GSJo2rxV1O9MuoTJ6bVGAlSKP30eedLxCbrdDZShGIY!DV4nThSxE11uO1nm6/Rpg5UoyZKFBejh/f4apMqBy+qMxBE8Pzk+drEDpIzxIxYAHeXA1ox6rZ65
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: 19252
 by: olcott - Tue, 28 Jun 2022 14:14 UTC

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?

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