Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Linux is addictive, I'm hooked! -- MaDsen Wikholm's .sig


computers / comp.ai.philosophy / Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ]

Re: Technically competent Software engineers can verify this halting problem proof refutation [ truism ]

<Uaudnfan2u21gyv_nZ2dnUU7_83NnZ2d@giganews.com>

  copy mid

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

  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: Fri, 24 Jun 2022 15:27:20 -0500
Date: Fri, 24 Jun 2022 15:27:18 -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: Technically competent Software engineers can verify this halting
problem proof refutation [ truism ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <EOydnaeszcdfHS__nZ2dnUU7_83NnZ2d@giganews.com>
<20220622203106.00003fa2@reddwarf.jmc>
<xqSdnb2KKdOL5i7_nZ2dnUU7_81g4p2d@giganews.com>
<20220622222043.00001cb9@reddwarf.jmc>
<_eidnf40g7wFES7_nZ2dnUU7_8zNnZ2d@giganews.com>
<de67d3d5-10f3-4e28-9b31-082e97c1145en@googlegroups.com>
<MtadnVqn1dCkCy7_nZ2dnUU7_8zNnZ2d@giganews.com>
<5f26b879-5cd4-4f28-b7c4-c3e4ed0614c2n@googlegroups.com>
<9OydnaRCCvQ9PC7_nZ2dnUU7_83NnZ2d@giganews.com>
<58dc4a7a-d635-44bb-bf2a-3a959d9d808an@googlegroups.com>
<SJ-dnXBdiJ6aIi7_nZ2dnUU7_83NnZ2d@giganews.com>
<d59b136e-6411-462f-9b62-229c0ac00608n@googlegroups.com>
<NZmdnRY_I-BpXi7_nZ2dnUU7_83NnZ2d@giganews.com>
<5934b17d-9607-49d1-97db-813a232a6d94n@googlegroups.com>
<AfGdncZCoPo1US7_nZ2dnUU7_83NnZ2d@giganews.com>
<15937d3c-f189-4c7a-bd39-2d7e25754d15n@googlegroups.com>
<YZqdnR1GHIpCmiv_nZ2dnUU7_8zNnZ2d@giganews.com>
<ec1c047f-97f1-49df-abf9-cc53d2d9b4e5n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <ec1c047f-97f1-49df-abf9-cc53d2d9b4e5n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Uaudnfan2u21gyv_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 310
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Rivu8gudSb2QNaIA1c+YgQ4hrgd++3Lux8XbK213xJfHxABoFPsl7mWvcIEHKvXCq0cq05bFQ7QeXk5!Lrw35iVAuerkJ3oVeRuTxJtQ2iQNHN+cVPthBgPA2QFk2LoLbmrqvi1oHBiOXqToxhHcm0adKTiD
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: 19104
 by: olcott - Fri, 24 Jun 2022 20:27 UTC

On 6/24/2022 3:05 PM, Paul N wrote:
> On Friday, June 24, 2022 at 7:52:22 PM UTC+1, olcott wrote:
>> On 6/22/2022 9:23 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>>>> examine its stored execution_trace of P and 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.
>>>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>>>>>>>>>> science:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>>>>>>>>>>>>>>> QED.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A software engineer must be an expert in: the C programming language,
>>>>>>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
>>>>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
>>>>>>>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>>>>>>>> omnishambles:
>>>>>>>>>>>>>> If you are competent then you already know this is true and lie about it:
>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
>>>>>>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>
>>>>>>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>>>>>>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
>>>>>>>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>>>>>>>> is only interested in rebuttal.
>>>>>>>>>>
>>>>>>>>>> I dare you to go back to the prior post and find any error in my
>>>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>>>>>>>> admission of defeat.
>>>>>>>>>
>>>>>>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
>>>>>>>> I never claimed that H(P,P) performs a complete and correct emulation of
>>>>>>>> its input so your rebuttal is the strawman deception.
>>>>>>>>
>>>>>>>> I claimed that H(P,P) correctly predicts that its complete and correct
>>>>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
>>>>>>>
>>>>>>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
>>>>>> _Infinite_Loop()
>>>>>> [00001082](01) 55 push ebp
>>>>>> [00001083](02) 8bec mov ebp,esp
>>>>>> [00001085](02) ebfe jmp 00001085
>>>>>> [00001087](01) 5d pop ebp
>>>>>> [00001088](01) c3 ret
>>>>>> Size in bytes:(0007) [00001088]
>>>>>>
>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
>>>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
>>>>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>>>> Infinite Loop Detected Simulation Stopped
>>>>>>
>>>>>> On the basis of this exact same utterly moronic reasoning because H
>>>>>> *can't* do a correct and complete emulation of its input, H cannot
>>>>>> possibly determine that _Infinite_Loop() never halts.
>>>>>
>>>>> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
>>>> You just said that H(P,P) cannot correctly predict that the correct and
>>>> complete x86 emulation of its input would never reach the "ret"
>>>> instruction of P without a compete x86 emulation of its input. I just
>>>> proved that is a very stupid thing to say.
>>>
>>> You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,P), would do. And it fails to do that.
>> From a purely software engineering perspective H(P,P) is required to to
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction of this input and H must
>> do this in a finite number of steps.
>>
>> The ordinary semantics of standard C and the conventional x86 language
>> are the entire semantics required to conclusively prove that H(P,P) does
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction.
>>
>> That you disagree with easily verified software engineering when you
>> already know that this software engineering is correct speaks loads
>> about your character.
>>
>> The only computer science that need be added to this is that the "ret"
>> instruction is the final state of P and that a sequence of
>> configurations that cannot possibly reach its final state is a
>> non-halting sequence.
>
> You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.
>

Thanks for continuing to review this.

No assumptions two years of software development derived fully
operational software that conclusively proves this.

> However, you have said yourself that H does not work like that. You have said "H must do this in a finite number of steps" and have said that H (whose source code you have never actually shown) detects the looping and halts, returning a value.
>

From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

> Thus H does not keep calling P over and over again, or getting deeper and deeper into emulation. It halts. Thus P also halts.

The computer science term "halts" only includes terminated normally by
reaching its final instruction.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

--
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 Technically competent Software engineers can verify this halting

By: olcott on Wed, 22 Jun 2022

158olcott
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor