Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The Macintosh is Xerox technology at its best.


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

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

<20220625201852.00001c98@reddwarf.jmc>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Technically competent Software engineers can verify this
halting problem proof refutation [ tautology ]
Message-ID: <20220625201852.00001c98@reddwarf.jmc>
References: <EOydnaeszcdfHS__nZ2dnUU7_83NnZ2d@giganews.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>
<Uaudnfan2u21gyv_nZ2dnUU7_83NnZ2d@giganews.com>
<ba57458e-02e2-4d31-af47-972c96a34871n@googlegroups.com>
<zZqdnd7eJKj_iir_nZ2dnUU7_8zNnZ2d@giganews.com>
<f0fa1007-c2e1-405d-b74c-b9701fc33ab0n@googlegroups.com>
<S8udnWTpo617qir_nZ2dnUU7_8zNnZ2d@giganews.com>
<bf7c8dfe-4551-4589-a273-d0dff16a87a0n@googlegroups.com>
<w6GdnTS8QYHH1ir_nZ2dnUU7_83NnZ2d@giganews.com>
<bf62d3d3-2adb-4546-a6d7-dd5bcca2a611n@googlegroups.com>
<udWdnT9pv9NZwyr_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 620
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sat, 25 Jun 2022 19:18:48 UTC
Date: Sat, 25 Jun 2022 20:18:52 +0100
X-Received-Bytes: 32723
 by: Mr Flibble - Sat, 25 Jun 2022 19:18 UTC

On Sat, 25 Jun 2022 14:15:15 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 1:58 PM, Paul N wrote:
> > On Saturday, June 25, 2022 at 6:52:33 PM UTC+1, olcott wrote:
> >> On 6/25/2022 12:21 PM, Paul N wrote:
> >>> On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:
> >>>> On 6/25/2022 11:19 AM, Paul N wrote:
> >>>>> On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:
> >>>>>> On 6/25/2022 6:56 AM, Paul N wrote:
> >>>>>>> On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>> It might help people's understanding if we had a few more
> >>>>>>> examples. Suppose, in addition to the normal P and H, we have
> >>>>>>> two more functions as follows:
> >>>>>>>
> >>>>>>> void Q(void)
> >>>>>>> {
> >>>>>>> if (H(P, P))
> >>>>>>> H2: goto H2;
> >>>>>>> return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> void R(void)
> >>>>>>> {
> >>>>>>> H(P, P);
> >>>>>>> return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> Will Q return? Will R return?
> >>>>>>>
> >>>>>> Yes they both return.
> >>>>>> void Q(void)
> >>>>>> {
> >>>>>> if (H(P, P))
> >>>>>> H2: goto H2;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> void R(void)
> >>>>>> {
> >>>>>> H(P, P);
> >>>>>> return;
> >>>>>> }
> >>>>>> _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]
> >>>>>>
> >>>>>> _Q()
> >>>>>> [00001210](01) 55 push ebp
> >>>>>> [00001211](02) 8bec mov ebp,esp
> >>>>>> [00001213](05) 68f0110000 push 000011f0
> >>>>>> [00001218](05) 68f0110000 push 000011f0
> >>>>>> [0000121d](05) e8fefdffff call 00001020
> >>>>>> [00001222](03) 83c408 add esp,+08
> >>>>>> [00001225](02) 85c0 test eax,eax
> >>>>>> [00001227](02) 7402 jz 0000122b
> >>>>>> [00001229](02) ebfe jmp 00001229
> >>>>>> [0000122b](01) 5d pop ebp
> >>>>>> [0000122c](01) c3 ret
> >>>>>> Size in bytes:(0029) [0000122c]
> >>>>>>
> >>>>>> _main()
> >>>>>> [00001250](01) 55 push ebp
> >>>>>> [00001251](02) 8bec mov ebp,esp
> >>>>>> [00001253](05) e8b8ffffff call 00001210
> >>>>>> [00001258](02) 33c0 xor eax,eax
> >>>>>> [0000125a](01) 5d pop ebp
> >>>>>> [0000125b](01) c3 ret
> >>>>>> Size in bytes:(0012) [0000125b]
> >>>>>> machine stack stack machine assembly
> >>>>>> address address data code language
> >>>>>> ======== ======== ======== ========= ============> >>>>>> ...[00001250][00102048][00000000] 55 push ebp
> >>>>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> >>>>>> ...[00001253][00102044][00001258] e8b8ffffff call 00001210
> >>>>>> ...[00001210][00102040][00102048] 55 push ebp
> >>>>>> ...[00001211][00102040][00102048] 8bec mov ebp,esp
> >>>>>> ...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[00001218][00102038][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[0000121d][00102034][00001222] e8fefdffff call 00001020
> >>>>>>
> >>>>>> Begin Simulation Execution Trace Stored at:2120fc
> >>>>>> Address_of_H:1020
> >>>>>> ...[000011f0][002120e8][002120ec] 55 push ebp
> >>>>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> >>>>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> >>>>>> ...[000011f6][002120e4][000011f0] 50 push eax
> >>>>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>> ...[000011fa][002120e0][000011f0] 51 push ecx
> >>>>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> >>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>> ...[00001222][00102040][00102048] 83c408 add esp,+08
> >>>>>> ...[00001225][00102040][00102048] 85c0 test eax,eax
> >>>>>> ...[00001227][00102040][00102048] 7402 jz 0000122b
> >>>>>> ...[0000122b][00102044][00001258] 5d pop ebp
> >>>>>> ...[0000122c][00102048][00000000] c3 ret
> >>>>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> >>>>>> ...[0000125a][0010204c][00100000] 5d pop ebp
> >>>>>> ...[0000125b][00102050][00000000] c3 ret
> >>>>>> Number of Instructions Executed(874)
> >>>>>>
> >>>>>> Above is:
> >>>>>> int main()
> >>>>>> {
> >>>>>> Q();
> >>>>>> //R();
> >>>>>> }
> >>>>>>
> >>>>>> ---
> >>>>>> machine stack stack machine assembly
> >>>>>> address address data code language
> >>>>>> ======== ======== ======== ========= ============> >>>>>> ...[00001250][00102048][00000000] 55 push ebp
> >>>>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
> >>>>>> ...[00001253][00102044][00001258] e8d8ffffff call 00001230
> >>>>>> ...[00001230][00102040][00102048] 55 push ebp
> >>>>>> ...[00001231][00102040][00102048] 8bec mov ebp,esp
> >>>>>> ...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[00001238][00102038][000011f0] 68f0110000 push 000011f0
> >>>>>> ...[0000123d][00102034][00001242] e8defdffff call 00001020
> >>>>>>
> >>>>>> Begin Simulation Execution Trace Stored at:2120fc
> >>>>>> Address_of_H:1020
> >>>>>> ...[000011f0][002120e8][002120ec] 55 push ebp
> >>>>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
> >>>>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
> >>>>>> ...[000011f6][002120e4][000011f0] 50 push eax
> >>>>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
> >>>>>> ...[000011fa][002120e0][000011f0] 51 push ecx
> >>>>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
> >>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>> ...[00001242][00102040][00102048] 83c408 add esp,+08
> >>>>>> ...[00001245][00102044][00001258] 5d pop ebp
> >>>>>> ...[00001246][00102048][00000000] c3 ret
> >>>>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
> >>>>>> ...[0000125a][0010204c][00100000] 5d pop ebp
> >>>>>> ...[0000125b][00102050][00000000] c3 ret
> >>>>>> Number of Instructions Executed(872)
> >>>>>>
> >>>>>> Above is:
> >>>>>> int main()
> >>>>>> {
> >>>>>> //Q();
> >>>>>> R();
> >>>>>> }
> >>>>>
> >>>>> Right, so we're getting somewhere. Can you explain why Q()
> >>>>> returns, and P(P) doesn't, when they both do the same thing in
> >>>>> the same way?
> >>>> int main()
> >>>> {
> >>>> P(P);
> >>>> }
> >>>>
> >>>> does return.
> >>>>
> >>>> The correct and complete x86 emulation of its input by H(P,P)
> >>>> would never reach the "ret" instruction of P because both H and
> >>>> P would remain stuck in infinitely nested emulation.
> >>>
> >>> These last two statements of yours are a contradiction.
> >>>
> >>> If P(P) returns, then a CORRECT emulation of it will reach the
> >>> ret instruction. An emulation that runs forever, when P(P) does
> >>> not, is not a correct emulation.
> >>
> >> 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 predict*
> >> that its correct and complete x86 emulation of its input would
> >> never reach the "ret" instruction (final state) of this input thus
> >> never halts. The correct and complete x86 emulation of its input
> >> by H would never reach the "ret" instruction of P because both H
> >> and P would remain stuck in infinitely nested emulation.
> >>
> >> I need reviewers like you so that I can *fine tune* my words.
> >
> > If you are saying that P(P) returns, but that a correct and
> > complete x86 emulation of P(P) does not, then I think you are going
> > to have to change either "correct" or "emulation" to some very
> > different word.
>
> The correct and complete emulation of the input to H(P,P) has halting
> behavior that is provably different than the the direct execution of
> P(P).
>
> "Common sense" tells you that they must be the same empirical proof
> proves that they are not the same.
>
> >> A halt decider must compute the mapping from its inputs to an
> >> accept or reject state on the basis of the actual behavior of
> >> these actual inputs.
> >
> > Exactly. The actual behaviour. Not the behaviour it would have if
> > things were different. In particular, you need to take into account
> > H's ability to detect infinite loops.
>
> I initially made H robust enough that it does correctly reject
> infinite loops and infinite recursion and have code samples to prove
> it.
>
> >> When a simulating halt decider rejects all inputs as non-halting
> >> whenever it correctly detects [in a finite number of steps] that
> >> its correct and complete simulation of its input would never reach
> >> [a] final state of this input then all [these] inputs (including
> >> pathological inputs) are correctly decided as non-halting.
> >
> > If you are fine-tuning your wording, could you do something about
> > this passage? Having both "When" and "whenever" makes it difficult
> > to parse.
>
> When a simulating halt decider correctly detects [in a finite number
> of steps] that its correct and complete simulation of its input would
> never reach [a] final state of this input then all [these] inputs
> (including pathological inputs) are correctly rejected as non-halting.
Your method for detecting pathological inputs precludes detecting
non-pathological inputs:

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

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