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();
> }

On Sat, 25 Jun 2022 11:06:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 10:59 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 10:54:13 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 10:21 AM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 10:19:02 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> >>>>> On Sat, 25 Jun 2022 10:03:17 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/25/2022 9:28 AM, olcott wrote:
> >>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
> >>>>>>>>>>>>>> code, and determines
> >>>>>>>>>>>>>> what it does, without actually executing it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
> >>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't
> >>>>>>>>>>>>> halt. He's invoked H
> >>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
> >>>>>>>>>>>>> P(P) and it halts.
> >>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
> >>>>>>>>>>>>> indeed done such
> >>>>>>>>>>>>> a thing) is incorrect.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Exactly.
> >>>>>>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>>>>>> tigers spend more energy
> >>>>>>>>>>>> than they take in. Well potentially this is dynamite. One
> >>>>>>>>>>>> explanation is that the
> >>>>>>>>>>>> law of conservation of energy is wrong.
> >>>>>>>>>>>> Except, before we countenance that explanation, we need
> >>>>>>>>>>>> to rule out a much
> >>>>>>>>>>>> simpler explanation. Which is that our measurements are
> >>>>>>>>>>>> wrong.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
> >>>>>>>>>>>> be doing, by dry-running
> >>>>>>>>>>>> it, and then actually run P(P) and obtained a different
> >>>>>>>>>>>> result. He also found that H
> >>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>>>>>> conclusion, but it is extensive
> >>>>>>>>>>>> and far-reaching in its implications. The behaviour of
> >>>>>>>>>>>> code when run is different
> >>>>>>>>>>>> from the correct behaviour of the code when simulated. If
> >>>>>>>>>>>> that's true, then it has
> >>>>>>>>>>>> similar implications for computer science that disproving
> >>>>>>>>>>>> the conservation law
> >>>>>>>>>>>> has for physics.
> >>>>>>>>>>>>
> >>>>>>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>>>>>> incorrect. Lots of people have
> >>>>>>>>>>>> suggested why it is incorrect. But they can't actually
> >>>>>>>>>>>> see the code. PO needs to
> >>>>>>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>>>>>> far-reaching explanation,
> >>>>>>>>>>>> until the simple explanation has been ruled out.
> >>>>>>>>>>>
> >>>>>>>>>>> I already proved that the dry run is correct.
> >>>>>>>>>>>
> >>>>>>>>>> Someone reports that tigers use more energy than they take
> >>>>>>>>>> in, and concludes that
> >>>>>>>>>> the energy conservation law is incorrect.
> >>>>>>>>>> Naturally, everyone is going to say "There must be some
> >>>>>>>>>> mistake. How were your
> >>>>>>>>>> measurements taken? Show us your calculations, maybe you've
> >>>>>>>>>> got your sums wrong."
> >>>>>>>>>>
> >>>>>>>>>> Now if they are also uncooperative about sharing the
> >>>>>>>>>> details of the investigation,
> >>>>>>>>>> those reservations will be magnified. There can be
> >>>>>>>>>> legitimate reasons. Tigers are
> >>>>>>>>>> rare and need to be conserved, you can't let anyone who
> >>>>>>>>>> wants have access to the
> >>>>>>>>>> tigers to try to repeat the measurements. But there's also
> >>>>>>>>>> a common illegitimate
> >>>>>>>>>> reason put forwards by people who make extraordinary
> >>>>>>>>>> claims. If the claims were
> >>>>>>>>>> unexceptional, such as that tigers have a similar energy
> >>>>>>>>>> budget to lions, then no-one
> >>>>>>>>>> would be saying "Show me your notebooks. How do you know
> >>>>>>>>>> that calorimeter was
> >>>>>>>>>> calibrated accurately? What's the name of the person who
> >>>>>>>>>> took that measurement
> >>>>>>>>>> and can I interview them?" Extraordinary claims are put
> >>>>>>>>>> through the wringer in a way
> >>>>>>>>>> that ordinary ones are not. I've seen complaints about this
> >>>>>>>>>> from parapsychologists.
> >>>>>>>>>> But if you're going to claim to have discovered a new
> >>>>>>>>>> physical principle, you need
> >>>>>>>>>> to present rock solid evidence.
> >>>>>>>>>>
> >>>>>>>>>> In this case, we can't see H. We can only suggest
> >>>>>>>>>> explanations for its behaviour.
> >>>>>>>>> It seems that you simply lack the technical competence.
> >>>>>>>>> Go back and look at my proof again.
> >>>>>>>>>
> >>>>>>>> Sorry no. I've been programming since I was a boy and I have
> >>>>>>>> a PhD in a computational-
> >>>>>>>> related subject. I'm confident of my technical abilities.
> >>>>>>>> What I can't do of course
> >>>>>>>> is tell you exactly what is going on in code I cannot see.
> >>>>>>>> I've got a pretty good idea,
> >>>>>>>> but I can only reconstruct on the basis of what you tell me.
> >>>>>>>> Ben thinks that I've
> >>>>>>>> got it wrong and in fact there are no nested emulations at
> >>>>>>>> all. I've no way of actually
> >>>>>>>> disproving that idea without seeing H.
> >>>>>>>>
> >>>>>>>
> >>>>>>> To fully understand this a software engineer must be an expert
> >>>>>>> in: (a) The C programming language,
> >>>>>>> (b) The x86 programming language,
> >>>>>>> (c) Exactly how C translates into x86 and,
> >>>>>>> (d) The ability to recognize infinite recursion at the x86
> >>>>>>> assembly language level.
> >>>>>>>
> >>>>>>> Anyone having the above credentials can validate my work, if
> >>>>>>> you cannot validate my work then you do not sufficiently have
> >>>>>>> the above credentials.
> >>>>>>>
> >>>>>>> Exactly how C translates into x86 is mandatory. If you don't
> >>>>>>> know how the C calling conventions are implemented in x86 you
> >>>>>>> cannot validate my work.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> void P(u32 x)
> >>>>>>> {
> >>>>>>>   if (H(x, x))
> >>>>>>>     HERE: goto HERE;
> >>>>>>>   return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> int main()
> >>>>>>> {
> >>>>>>>   Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>> }
> >>>>>>>
> >>>>>>> _P()
> >>>>>>> [00001202](01)  55              push ebp
> >>>>>>> [00001203](02)  8bec            mov ebp,esp
> >>>>>>> [00001205](03)  8b4508          mov eax,[ebp+08]
> >>>>>>> [00001208](01)  50              push eax
> >>>>>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
> >>>>>>> [0000120c](01)  51              push ecx
> >>>>>>> [0000120d](05)  e820feffff      call 00001032
> >>>>>>> [00001212](03)  83c408          add esp,+08
> >>>>>>> [00001215](02)  85c0            test eax,eax
> >>>>>>> [00001217](02)  7402            jz 0000121b
> >>>>>>> [00001219](02)  ebfe            jmp 00001219
> >>>>>>> [0000121b](01)  5d              pop ebp
> >>>>>>> [0000121c](01)  c3              ret
> >>>>>>> Size in bytes:(0027) [0000121c]
> >>>>>>>
> >>>>>>> _main()
> >>>>>>> [00001222](01)  55              push ebp
> >>>>>>> [00001223](02)  8bec            mov ebp,esp
> >>>>>>> [00001225](05)  6802120000      push 00001202
> >>>>>>> [0000122a](05)  6802120000      push 00001202
> >>>>>>> [0000122f](05)  e8fefdffff      call 00001032
> >>>>>>> [00001234](03)  83c408          add esp,+08
> >>>>>>> [00001237](01)  50              push eax
> >>>>>>> [00001238](05)  68b3030000      push 000003b3
> >>>>>>> [0000123d](05)  e8c0f1ffff      call 00000402
> >>>>>>> [00001242](03)  83c408          add esp,+08
> >>>>>>> [00001245](02)  33c0            xor eax,eax
> >>>>>>> [00001247](01)  5d              pop ebp
> >>>>>>> [00001248](01)  c3              ret
> >>>>>>> Size in bytes:(0039) [00001248]
> >>>>>>>
> >>>>>>>  machine   stack     stack     machine    assembly
> >>>>>>>  address   address   data      code       language
> >>>>>>>  ========  ========  ========  =========  ============> >>>>>>> [00001222][0010200f][00000000] 55         push ebp
> >>>>>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
> >>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 //
> >>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
> >>>>>>> 00001202 // push P [0000122f][00102003][00001234] e8fefdffff
> >>>>>>> call 00001032 // call executed H
> >>>>>>>
> >>>>>>> Begin Simulation   Execution Trace Stored at:2120c3
> >>>>>>> Address_of_H:1032
> >>>>>>> [00001202][002120af][002120b3] 55         push ebp
> >>>>>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
> >>>>>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
> >>>>>>> [00001208][002120ab][00001202] 50         push eax      //
> >>>>>>> push P [00001209][002120ab][00001202] 8b4d08     mov
> >>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51         push
> >>>>>>> ecx      // push P [0000120d][002120a3][00001212] e820feffff
> >>>>>>> call 00001032 // 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.
> >>>>>>> (c) H aborts its emulation of P before its call to H is
> >>>>>>> emulated.
> >>>>>>
> >>>>>> When you know that H simply implements the above algorithm
> >>>>>> there is no need to see its source code. I am reserving the
> >>>>>> publication of the 5 pages of the source code of the halt
> >>>>>> decider for journal publication.
> >>>>>
> >>>>> Your H is not a pure function as it behaves differently
> >>>>> depending on what is invoking it (it returns a decision answer
> >>>>> to main() but not to P()) and it has side effects (aborting a
> >>>>> simulation).
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Finally a critique that has a reasonable basis.
> >>>>
> >>>> When I transformed H into a pure function of its inputs it always
> >>>> has the same behavior no matter how it is invoked.
> >>>>
> >>>> The x86 emulation of P is aborted before P invokes H.
> >>>
> >>> Nope. Preventing a call to H is equivalent to H behaving
> >>> differently for same inputs. Aborting a simulation is a side
> >>> effect: pure functions do not have side effects.
> >>>
> >>> /Flibble
> >>>
> >>
> >> In other words you are saying that a halt decider is simply not
> >> allowed to report when it correctly detects that it is being called
> >> in infinitely recursive simulation.
> >
> > I keep telling you this: the infinite recursion is NOT present when
> > using a valid halt decider: your H is NOT a valid halt
> > decider.
> >
> > Simulation is an erroneous approach as a simulating halt decider
> > can not answer in finite time for a non-halting input as there is no
> > proven general solution for detecting non-halting behaviour.
> >
> > /Flibble
> >
>
> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
> YOU DENY THIS VERIFIABLE FACT:
>
> 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.

Click here to read the complete article

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?

Demented bigot, Peter Olcott wrote:
....
> In other words you are saying that a halt decider is simply not allowed
> to report when it correctly detects that it is being called in
> infinitely recursive simulation.
>
> We could also "prove" that a correct halt decider is impossible by
> making another similar rule that halt deciders are simply not allowed to
> report on infinite loops.

You can also "prove" that a natural number that is both even and odd
is even. It doesn't mean that such a number exists.

Publish your code for H. We do have a proof (mutiple proofs) that it
cannot exist as you specify it. You know that we could, then, prove
that it doesn't work. This is why you are not publishing it. You are
a LIAR, a DELUSIONAL CRANK, a DESPICABLE FRAUD, Olcott.

[AGAIN: STOP MULTI-POSTING WITHOUT FOLLOW-UP, YOU ASSHOLE!!!]

On 6/25/2022 11:25 AM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 11:06:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 10:59 AM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 10:54:13 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
>>>>> On Sat, 25 Jun 2022 10:19:02 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
>>>>>>>>>>>>>>>> code, and determines
>>>>>>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't
>>>>>>>>>>>>>>> halt. He's invoked H
>>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
>>>>>>>>>>>>>>> P(P) and it halts.
>>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
>>>>>>>>>>>>>>> indeed done such
>>>>>>>>>>>>>>> a thing) is incorrect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Exactly.
>>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>>>>>> tigers spend more energy
>>>>>>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>>>>>>> explanation is that the
>>>>>>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>>>>>>> Except, before we countenance that explanation, we need
>>>>>>>>>>>>>> to rule out a much
>>>>>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
>>>>>>>>>>>>>> be doing, by dry-running
>>>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>>>>>>> result. He also found that H
>>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>>>>>>> conclusion, but it is extensive
>>>>>>>>>>>>>> and far-reaching in its implications. The behaviour of
>>>>>>>>>>>>>> code when run is different
>>>>>>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>>>>>>> that's true, then it has
>>>>>>>>>>>>>> similar implications for computer science that disproving
>>>>>>>>>>>>>> the conservation law
>>>>>>>>>>>>>> has for physics.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>>>>>> incorrect. Lots of people have
>>>>>>>>>>>>>> suggested why it is incorrect. But they can't actually
>>>>>>>>>>>>>> see the code. PO needs to
>>>>>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>>>>>> far-reaching explanation,
>>>>>>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>> Someone reports that tigers use more energy than they take
>>>>>>>>>>>> in, and concludes that
>>>>>>>>>>>> the energy conservation law is incorrect.
>>>>>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>>>>>> mistake. How were your
>>>>>>>>>>>> measurements taken? Show us your calculations, maybe you've
>>>>>>>>>>>> got your sums wrong."
>>>>>>>>>>>>
>>>>>>>>>>>> Now if they are also uncooperative about sharing the
>>>>>>>>>>>> details of the investigation,
>>>>>>>>>>>> those reservations will be magnified. There can be
>>>>>>>>>>>> legitimate reasons. Tigers are
>>>>>>>>>>>> rare and need to be conserved, you can't let anyone who
>>>>>>>>>>>> wants have access to the
>>>>>>>>>>>> tigers to try to repeat the measurements. But there's also
>>>>>>>>>>>> a common illegitimate
>>>>>>>>>>>> reason put forwards by people who make extraordinary
>>>>>>>>>>>> claims. If the claims were
>>>>>>>>>>>> unexceptional, such as that tigers have a similar energy
>>>>>>>>>>>> budget to lions, then no-one
>>>>>>>>>>>> would be saying "Show me your notebooks. How do you know
>>>>>>>>>>>> that calorimeter was
>>>>>>>>>>>> calibrated accurately? What's the name of the person who
>>>>>>>>>>>> took that measurement
>>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
>>>>>>>>>>>> through the wringer in a way
>>>>>>>>>>>> that ordinary ones are not. I've seen complaints about this
>>>>>>>>>>>> from parapsychologists.
>>>>>>>>>>>> But if you're going to claim to have discovered a new
>>>>>>>>>>>> physical principle, you need
>>>>>>>>>>>> to present rock solid evidence.
>>>>>>>>>>>>
>>>>>>>>>>>> In this case, we can't see H. We can only suggest
>>>>>>>>>>>> explanations for its behaviour.
>>>>>>>>>>> It seems that you simply lack the technical competence.
>>>>>>>>>>> Go back and look at my proof again.
>>>>>>>>>>>
>>>>>>>>>> Sorry no. I've been programming since I was a boy and I have
>>>>>>>>>> a PhD in a computational-
>>>>>>>>>> related subject. I'm confident of my technical abilities.
>>>>>>>>>> What I can't do of course
>>>>>>>>>> is tell you exactly what is going on in code I cannot see.
>>>>>>>>>> I've got a pretty good idea,
>>>>>>>>>> but I can only reconstruct on the basis of what you tell me.
>>>>>>>>>> Ben thinks that I've
>>>>>>>>>> got it wrong and in fact there are no nested emulations at
>>>>>>>>>> all. I've no way of actually
>>>>>>>>>> disproving that idea without seeing H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To fully understand this a software engineer must be an expert
>>>>>>>>> in: (a) The C programming language,
>>>>>>>>> (b) The x86 programming language,
>>>>>>>>> (c) Exactly how C translates into x86 and,
>>>>>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>>>>>> assembly language level.
>>>>>>>>>
>>>>>>>>> Anyone having the above credentials can validate my work, if
>>>>>>>>> you cannot validate my work then you do not sufficiently have
>>>>>>>>> the above credentials.
>>>>>>>>>
>>>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
>>>>>>>>> know how the C calling conventions are implemented in x86 you
>>>>>>>>> cannot validate my work.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>   if (H(x, x))
>>>>>>>>>     HERE: goto HERE;
>>>>>>>>>   return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>   Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001202](01)  55              push ebp
>>>>>>>>> [00001203](02)  8bec            mov ebp,esp
>>>>>>>>> [00001205](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>> [00001208](01)  50              push eax
>>>>>>>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>> [0000120c](01)  51              push ecx
>>>>>>>>> [0000120d](05)  e820feffff      call 00001032
>>>>>>>>> [00001212](03)  83c408          add esp,+08
>>>>>>>>> [00001215](02)  85c0            test eax,eax
>>>>>>>>> [00001217](02)  7402            jz 0000121b
>>>>>>>>> [00001219](02)  ebfe            jmp 00001219
>>>>>>>>> [0000121b](01)  5d              pop ebp
>>>>>>>>> [0000121c](01)  c3              ret
>>>>>>>>> Size in bytes:(0027) [0000121c]
>>>>>>>>>
>>>>>>>>> _main()
>>>>>>>>> [00001222](01)  55              push ebp
>>>>>>>>> [00001223](02)  8bec            mov ebp,esp
>>>>>>>>> [00001225](05)  6802120000      push 00001202
>>>>>>>>> [0000122a](05)  6802120000      push 00001202
>>>>>>>>> [0000122f](05)  e8fefdffff      call 00001032
>>>>>>>>> [00001234](03)  83c408          add esp,+08
>>>>>>>>> [00001237](01)  50              push eax
>>>>>>>>> [00001238](05)  68b3030000      push 000003b3
>>>>>>>>> [0000123d](05)  e8c0f1ffff      call 00000402
>>>>>>>>> [00001242](03)  83c408          add esp,+08
>>>>>>>>> [00001245](02)  33c0            xor eax,eax
>>>>>>>>> [00001247](01)  5d              pop ebp
>>>>>>>>> [00001248](01)  c3              ret
>>>>>>>>> Size in bytes:(0039) [00001248]
>>>>>>>>>
>>>>>>>>>  machine   stack     stack     machine    assembly
>>>>>>>>>  address   address   data      code       language
>>>>>>>>>  ========  ========  ========  =========  =============
>>>>>>>>> [00001222][0010200f][00000000] 55         push ebp
>>>>>>>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
>>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 //
>>>>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
>>>>>>>>> 00001202 // push P [0000122f][00102003][00001234] e8fefdffff
>>>>>>>>> call 00001032 // call executed H
>>>>>>>>>
>>>>>>>>> Begin Simulation   Execution Trace Stored at:2120c3
>>>>>>>>> Address_of_H:1032
>>>>>>>>> [00001202][002120af][002120b3] 55         push ebp
>>>>>>>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
>>>>>>>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
>>>>>>>>> [00001208][002120ab][00001202] 50         push eax      //
>>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08     mov
>>>>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51         push
>>>>>>>>> ecx      // push P [0000120d][002120a3][00001212] e820feffff
>>>>>>>>> call 00001032 // 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.
>>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>>> emulated.
>>>>>>>>
>>>>>>>> When you know that H simply implements the above algorithm
>>>>>>>> there is no need to see its source code. I am reserving the
>>>>>>>> publication of the 5 pages of the source code of the halt
>>>>>>>> decider for journal publication.
>>>>>>>
>>>>>>> Your H is not a pure function as it behaves differently
>>>>>>> depending on what is invoking it (it returns a decision answer
>>>>>>> to main() but not to P()) and it has side effects (aborting a
>>>>>>> simulation).
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Finally a critique that has a reasonable basis.
>>>>>>
>>>>>> When I transformed H into a pure function of its inputs it always
>>>>>> has the same behavior no matter how it is invoked.
>>>>>>
>>>>>> The x86 emulation of P is aborted before P invokes H.
>>>>>
>>>>> Nope. Preventing a call to H is equivalent to H behaving
>>>>> differently for same inputs. Aborting a simulation is a side
>>>>> effect: pure functions do not have side effects.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> In other words you are saying that a halt decider is simply not
>>>> allowed to report when it correctly detects that it is being called
>>>> in infinitely recursive simulation.
>>>
>>> I keep telling you this: the infinite recursion is NOT present when
>>> using a valid halt decider: your H is NOT a valid halt
>>> decider.
>>>
>>> Simulation is an erroneous approach as a simulating halt decider
>>> can not answer in finite time for a non-halting input as there is no
>>> proven general solution for detecting non-halting behaviour.
>>>
>>> /Flibble
>>>
>>
>> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
>> YOU DENY THIS VERIFIABLE FACT:
>>
>> 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.
>
> For [Strachey 1965] (and the proofs based on it) H is NOT a simulating
> halt decider so there is no infinite recursion as there is no emulation.
>
> Valid halt deciders ANALYSE P, they do not EMULATE P.
>
> /Flibble
>

On 6/25/2022 11:31 AM, Python wrote:
> Demented bigot, Peter Olcott wrote:
> ...
>> In other words you are saying that a halt decider is simply not
>> allowed to report when it correctly detects that it is being called in
>> infinitely recursive simulation.
>>
>> We could also "prove" that a correct halt decider is impossible by
>> making another similar rule that halt deciders are simply not allowed
>> to report on infinite loops.
>
> You can also "prove" that a natural number that is both even and odd
> is even. It doesn't mean that such a number exists.
>
> Publish your code for H. We do have a proof (mutiple proofs) that it
> cannot exist as you specify it.

To fully understand this a software engineer must be an expert in:
(a) The C programming language.
(b) The x86 programming language.
(c) Exactly how C translates into x86 (how C function calls are
implemented in x86).
(d) The ability to recognize infinite recursion at the x86 assembly
language level.

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.

THIS IS ALL THAT IS NEEDED TO VERIFY THAT:
On 6/25/2022 10:03 AM, olcott wrote:
[Technically competent Software engineers can verify this halting
problem proof refutation]

> You know that we could, then, prove
> that it doesn't work. This is why you are not publishing it. You are
> a LIAR, a DELUSIONAL CRANK, a DESPICABLE FRAUD, Olcott.
>
>
> [AGAIN: STOP MULTI-POSTING WITHOUT FOLLOW-UP, YOU ASSHOLE!!!]
>

Multi-posting without followup to four relevant groups does not not seem
to breach netiquette guidelines and does get more reviewers of my work.

--
Copyright 2022 Pete Olcott

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

On 6/25/22 11:19 AM, olcott wrote:
> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 10:03:17 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>> wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>> "Dry run" means that a human programmer looks at the code,
>>>>>>>>>>> and determines
>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>
>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>>> He's invoked H
>>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P) and
>>>>>>>>>> it halts.
>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has indeed
>>>>>>>>>> done such
>>>>>>>>>> a thing) is incorrect.
>>>>>>>>> Exactly.
>>>>>>>>> We do our little energy budget on tigers, and find that tigers
>>>>>>>>> spend more energy
>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>> explanation is that the
>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>> Except, before we countenance that explanation, we need to
>>>>>>>>> rule out a much
>>>>>>>>> simpler explanation. Which is that our measurements are wrong.
>>>>>>>>>
>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>>> doing, by dry-running
>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>> result. He also found that H
>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>> conclusion, but it is extensive
>>>>>>>>> and far-reaching in its implications. The behaviour of code
>>>>>>>>> when run is different
>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>> that's true, then it has
>>>>>>>>> similar implications for computer science that disproving the
>>>>>>>>> conservation law
>>>>>>>>> has for physics.
>>>>>>>>>
>>>>>>>>> But the obvious explanation is that the dry-run was incorrect.
>>>>>>>>> Lots of people have
>>>>>>>>> suggested why it is incorrect. But they can't actually see the
>>>>>>>>> code. PO needs to
>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>> far-reaching explanation,
>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>
>>>>>>>> I already proved that the dry run is correct.
>>>>>>> Someone reports that tigers use more energy than they take in,
>>>>>>> and concludes that
>>>>>>> the energy conservation law is incorrect.
>>>>>>> Naturally, everyone is going to say "There must be some mistake.
>>>>>>> How were your
>>>>>>> measurements taken? Show us your calculations, maybe you've got
>>>>>>> your sums wrong."
>>>>>>>
>>>>>>> Now if they are also uncooperative about sharing the details of
>>>>>>> the investigation,
>>>>>>> those reservations will be magnified. There can be legitimate
>>>>>>> reasons. Tigers are
>>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>>> have access to the
>>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>>> common illegitimate
>>>>>>> reason put forwards by people who make extraordinary claims. If
>>>>>>> the claims were
>>>>>>> unexceptional, such as that tigers have a similar energy budget
>>>>>>> to lions, then no-one
>>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>>> calorimeter was
>>>>>>> calibrated accurately? What's the name of the person who took
>>>>>>> that measurement
>>>>>>> and can I interview them?" Extraordinary claims are put through
>>>>>>> the wringer in a way
>>>>>>> that ordinary ones are not. I've seen complaints about this from
>>>>>>> parapsychologists.
>>>>>>> But if you're going to claim to have discovered a new physical
>>>>>>> principle, you need
>>>>>>> to present rock solid evidence.
>>>>>>>
>>>>>>> In this case, we can't see H. We can only suggest explanations
>>>>>>> for its behaviour.
>>>>>> It seems that you simply lack the technical competence.
>>>>>> Go back and look at my proof again.
>>>>> Sorry no. I've been programming since I was a boy and I have a PhD
>>>>> in a computational-
>>>>> related subject. I'm confident of my technical abilities. What I
>>>>> can't do of course
>>>>> is tell you exactly what is going on in code I cannot see. I've
>>>>> got a pretty good idea,
>>>>> but I can only reconstruct on the basis of what you tell me. Ben
>>>>> thinks that I've
>>>>> got it wrong and in fact there are no nested emulations at all.
>>>>> I've no way of actually
>>>>> disproving that idea without seeing H.
>>>>
>>>> To fully understand this a software engineer must be an expert in:
>>>> (a) The C programming language,
>>>> (b) The x86 programming language,
>>>> (c) Exactly how C translates into x86 and,
>>>> (d) The ability to recognize infinite recursion at the x86 assembly
>>>> language level.
>>>>
>>>> Anyone having the above credentials can validate my work, if you
>>>> cannot validate my work then you do not sufficiently have the above
>>>> credentials.
>>>>
>>>> Exactly how C translates into x86 is mandatory. If you don't know
>>>> how the C calling conventions are implemented in x86 you cannot
>>>> validate my work.
>>>>
>>>>   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.
>>>>
>>>> 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.
>>>>
>>>> void P(u32 x)
>>>> {
>>>>     if (H(x, x))
>>>>       HERE: goto HERE;
>>>>     return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001202](01)  55              push ebp
>>>> [00001203](02)  8bec            mov ebp,esp
>>>> [00001205](03)  8b4508          mov eax,[ebp+08]
>>>> [00001208](01)  50              push eax
>>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
>>>> [0000120c](01)  51              push ecx
>>>> [0000120d](05)  e820feffff      call 00001032
>>>> [00001212](03)  83c408          add esp,+08
>>>> [00001215](02)  85c0            test eax,eax
>>>> [00001217](02)  7402            jz 0000121b
>>>> [00001219](02)  ebfe            jmp 00001219
>>>> [0000121b](01)  5d              pop ebp
>>>> [0000121c](01)  c3              ret
>>>> Size in bytes:(0027) [0000121c]
>>>>
>>>> _main()
>>>> [00001222](01)  55              push ebp
>>>> [00001223](02)  8bec            mov ebp,esp
>>>> [00001225](05)  6802120000      push 00001202
>>>> [0000122a](05)  6802120000      push 00001202
>>>> [0000122f](05)  e8fefdffff      call 00001032
>>>> [00001234](03)  83c408          add esp,+08
>>>> [00001237](01)  50              push eax
>>>> [00001238](05)  68b3030000      push 000003b3
>>>> [0000123d](05)  e8c0f1ffff      call 00000402
>>>> [00001242](03)  83c408          add esp,+08
>>>> [00001245](02)  33c0            xor eax,eax
>>>> [00001247](01)  5d              pop ebp
>>>> [00001248](01)  c3              ret
>>>> Size in bytes:(0039) [00001248]
>>>>
>>>>    machine   stack     stack     machine    assembly
>>>>    address   address   data      code       language
>>>>    ========  ========  ========  =========  =============
>>>> [00001222][0010200f][00000000] 55         push ebp
>>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push P
>>>> [0000122a][00102007][00001202] 6802120000 push 00001202 // push P
>>>> [0000122f][00102003][00001234] e8fefdffff call 00001032 // call
>>>> executed H
>>>>
>>>> Begin Simulation   Execution Trace Stored at:2120c3
>>>> Address_of_H:1032
>>>> [00001202][002120af][002120b3] 55         push ebp
>>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
>>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
>>>> [00001208][002120ab][00001202] 50         push eax      // push P
>>>> [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
>>>> [0000120c][002120a7][00001202] 51         push ecx      // push P
>>>> [0000120d][002120a3][00001212] e820feffff call 00001032 // 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.
>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>
>>> When you know that H simply implements the above algorithm there is
>>> no need to see its source code. I am reserving the publication of the
>>> 5 pages of the source code of the halt decider for journal
>>> publication.
>>
>> Your H is not a pure function as it behaves differently depending on
>> what is invoking it (it returns a decision answer to main() but not
>> to P()) and it has side effects (aborting a simulation).
>>
>> /Flibble
>>
>
> Finally a critique that has a reasonable basis.
>
> When I transformed H into a pure function of its inputs it always has
> the same behavior no matter how it is invoked.
>
> The x86 emulation of P is aborted before P invokes H.
>

On 6/25/22 12:06 PM, olcott wrote:
> On 6/25/2022 10:59 AM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 10:54:13 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
>>>> On Sat, 25 Jun 2022 10:19:02 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
>>>>>>>>>>>>>>> code, and determines
>>>>>>>>>>>>>>> what it does, without actually executing it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Going back, now, to what you think needs to be resolved:
>>>>>>>>>>>>>> | He's dry-run P(P) and established that it doesn't halt.
>>>>>>>>>>>>>> He's invoked H
>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run P(P)
>>>>>>>>>>>>>> and it halts.
>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
>>>>>>>>>>>>>> indeed done such
>>>>>>>>>>>>>> a thing) is incorrect.
>>>>>>>>>>>>> Exactly.
>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
>>>>>>>>>>>>> tigers spend more energy
>>>>>>>>>>>>> than they take in. Well potentially this is dynamite. One
>>>>>>>>>>>>> explanation is that the
>>>>>>>>>>>>> law of conservation of energy is wrong.
>>>>>>>>>>>>> Except, before we countenance that explanation, we need to
>>>>>>>>>>>>> rule out a much
>>>>>>>>>>>>> simpler explanation. Which is that our measurements are
>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should be
>>>>>>>>>>>>> doing, by dry-running
>>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
>>>>>>>>>>>>> result. He also found that H
>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
>>>>>>>>>>>>> conclusion, but it is extensive
>>>>>>>>>>>>> and far-reaching in its implications. The behaviour of code
>>>>>>>>>>>>> when run is different
>>>>>>>>>>>>> from the correct behaviour of the code when simulated. If
>>>>>>>>>>>>> that's true, then it has
>>>>>>>>>>>>> similar implications for computer science that disproving
>>>>>>>>>>>>> the conservation law
>>>>>>>>>>>>> has for physics.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
>>>>>>>>>>>>> incorrect. Lots of people have
>>>>>>>>>>>>> suggested why it is incorrect. But they can't actually see
>>>>>>>>>>>>> the code. PO needs to
>>>>>>>>>>>>> understand that no-one will accept the complicated,
>>>>>>>>>>>>> far-reaching explanation,
>>>>>>>>>>>>> until the simple explanation has been ruled out.
>>>>>>>>>>>>
>>>>>>>>>>>> I already proved that the dry run is correct.
>>>>>>>>>>> Someone reports that tigers use more energy than they take
>>>>>>>>>>> in, and concludes that
>>>>>>>>>>> the energy conservation law is incorrect.
>>>>>>>>>>> Naturally, everyone is going to say "There must be some
>>>>>>>>>>> mistake. How were your
>>>>>>>>>>> measurements taken? Show us your calculations, maybe you've
>>>>>>>>>>> got your sums wrong."
>>>>>>>>>>>
>>>>>>>>>>> Now if they are also uncooperative about sharing the details
>>>>>>>>>>> of the investigation,
>>>>>>>>>>> those reservations will be magnified. There can be legitimate
>>>>>>>>>>> reasons. Tigers are
>>>>>>>>>>> rare and need to be conserved, you can't let anyone who wants
>>>>>>>>>>> have access to the
>>>>>>>>>>> tigers to try to repeat the measurements. But there's also a
>>>>>>>>>>> common illegitimate
>>>>>>>>>>> reason put forwards by people who make extraordinary claims.
>>>>>>>>>>> If the claims were
>>>>>>>>>>> unexceptional, such as that tigers have a similar energy
>>>>>>>>>>> budget to lions, then no-one
>>>>>>>>>>> would be saying "Show me your notebooks. How do you know that
>>>>>>>>>>> calorimeter was
>>>>>>>>>>> calibrated accurately? What's the name of the person who took
>>>>>>>>>>> that measurement
>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
>>>>>>>>>>> through the wringer in a way
>>>>>>>>>>> that ordinary ones are not. I've seen complaints about this
>>>>>>>>>>> from parapsychologists.
>>>>>>>>>>> But if you're going to claim to have discovered a new
>>>>>>>>>>> physical principle, you need
>>>>>>>>>>> to present rock solid evidence.
>>>>>>>>>>>
>>>>>>>>>>> In this case, we can't see H. We can only suggest
>>>>>>>>>>> explanations for its behaviour.
>>>>>>>>>> It seems that you simply lack the technical competence.
>>>>>>>>>> Go back and look at my proof again.
>>>>>>>>> Sorry no. I've been programming since I was a boy and I have a
>>>>>>>>> PhD in a computational-
>>>>>>>>> related subject. I'm confident of my technical abilities. What
>>>>>>>>> I can't do of course
>>>>>>>>> is tell you exactly what is going on in code I cannot see. I've
>>>>>>>>> got a pretty good idea,
>>>>>>>>> but I can only reconstruct on the basis of what you tell me.
>>>>>>>>> Ben thinks that I've
>>>>>>>>> got it wrong and in fact there are no nested emulations at all.
>>>>>>>>> I've no way of actually
>>>>>>>>> disproving that idea without seeing H.
>>>>>>>>
>>>>>>>> To fully understand this a software engineer must be an expert
>>>>>>>> in: (a) The C programming language,
>>>>>>>> (b) The x86 programming language,
>>>>>>>> (c) Exactly how C translates into x86 and,
>>>>>>>> (d) The ability to recognize infinite recursion at the x86
>>>>>>>> assembly language level.
>>>>>>>>
>>>>>>>> Anyone having the above credentials can validate my work, if you
>>>>>>>> cannot validate my work then you do not sufficiently have the
>>>>>>>> above credentials.
>>>>>>>>
>>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
>>>>>>>> know how the C calling conventions are implemented in x86 you
>>>>>>>> cannot validate my work.
>>>>>>>>
>>>>>>>>     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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>       if (H(x, x))
>>>>>>>>         HERE: goto HERE;
>>>>>>>>       return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>       Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00001202](01)  55              push ebp
>>>>>>>> [00001203](02)  8bec            mov ebp,esp
>>>>>>>> [00001205](03)  8b4508          mov eax,[ebp+08]
>>>>>>>> [00001208](01)  50              push eax
>>>>>>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>> [0000120c](01)  51              push ecx
>>>>>>>> [0000120d](05)  e820feffff      call 00001032
>>>>>>>> [00001212](03)  83c408          add esp,+08
>>>>>>>> [00001215](02)  85c0            test eax,eax
>>>>>>>> [00001217](02)  7402            jz 0000121b
>>>>>>>> [00001219](02)  ebfe            jmp 00001219
>>>>>>>> [0000121b](01)  5d              pop ebp
>>>>>>>> [0000121c](01)  c3              ret
>>>>>>>> Size in bytes:(0027) [0000121c]
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [00001222](01)  55              push ebp
>>>>>>>> [00001223](02)  8bec            mov ebp,esp
>>>>>>>> [00001225](05)  6802120000      push 00001202
>>>>>>>> [0000122a](05)  6802120000      push 00001202
>>>>>>>> [0000122f](05)  e8fefdffff      call 00001032
>>>>>>>> [00001234](03)  83c408          add esp,+08
>>>>>>>> [00001237](01)  50              push eax
>>>>>>>> [00001238](05)  68b3030000      push 000003b3
>>>>>>>> [0000123d](05)  e8c0f1ffff      call 00000402
>>>>>>>> [00001242](03)  83c408          add esp,+08
>>>>>>>> [00001245](02)  33c0            xor eax,eax
>>>>>>>> [00001247](01)  5d              pop ebp
>>>>>>>> [00001248](01)  c3              ret
>>>>>>>> Size in bytes:(0039) [00001248]
>>>>>>>>
>>>>>>>>      machine   stack     stack     machine    assembly
>>>>>>>>      address   address   data      code       language
>>>>>>>>      ========  ========  ========  =========  =============
>>>>>>>> [00001222][0010200f][00000000] 55         push ebp
>>>>>>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 // push
>>>>>>>> P [0000122a][00102007][00001202] 6802120000 push 00001202 //
>>>>>>>> push P [0000122f][00102003][00001234] e8fefdffff call 00001032
>>>>>>>> // call executed H
>>>>>>>>
>>>>>>>> Begin Simulation   Execution Trace Stored at:2120c3
>>>>>>>> Address_of_H:1032
>>>>>>>> [00001202][002120af][002120b3] 55         push ebp
>>>>>>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
>>>>>>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
>>>>>>>> [00001208][002120ab][00001202] 50         push eax      // push
>>>>>>>> P [00001209][002120ab][00001202] 8b4d08     mov ecx,[ebp+08]
>>>>>>>> [0000120c][002120a7][00001202] 51         push ecx      // push
>>>>>>>> P [0000120d][002120a3][00001212] e820feffff call 00001032 //
>>>>>>>> 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.
>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>> emulated.
>>>>>>>
>>>>>>> When you know that H simply implements the above algorithm there
>>>>>>> is no need to see its source code. I am reserving the
>>>>>>> publication of the 5 pages of the source code of the halt
>>>>>>> decider for journal publication.
>>>>>>
>>>>>> Your H is not a pure function as it behaves differently depending
>>>>>> on what is invoking it (it returns a decision answer to main()
>>>>>> but not to P()) and it has side effects (aborting a simulation).
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> Finally a critique that has a reasonable basis.
>>>>>
>>>>> When I transformed H into a pure function of its inputs it always
>>>>> has the same behavior no matter how it is invoked.
>>>>>
>>>>> The x86 emulation of P is aborted before P invokes H.
>>>> Nope. Preventing a call to H is equivalent to H behaving differently
>>>> for same inputs. Aborting a simulation is a side effect: pure
>>>> functions do not have side effects.
>>>>
>>>> /Flibble
>>>
>>> In other words you are saying that a halt decider is simply not
>>> allowed to report when it correctly detects that it is being called
>>> in infinitely recursive simulation.
>>
>> I keep telling you this: the infinite recursion is NOT present when
>> using a valid halt decider: your H is NOT a valid halt
>> decider.
>>
>> Simulation is an erroneous approach as a simulating halt decider
>> can not answer in finite time for a non-halting input as there is no
>> proven general solution for detecting non-halting behaviour.
>>
>> /Flibble
>>
>
> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY YOU
> DENY THIS VERIFIABLE FACT:
>
> 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.
>

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.

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.

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.

On Sat, 25 Jun 2022 11:32:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 11:25 AM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 11:06:12 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 10:59 AM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 10:54:13 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 10:21 AM, Mr Flibble wrote:
> >>>>> On Sat, 25 Jun 2022 10:19:02 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/25/2022 10:09 AM, Mr Flibble wrote:
> >>>>>>> On Sat, 25 Jun 2022 10:03:17 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/25/2022 9:28 AM, olcott wrote:
> >>>>>>>>> On 6/25/2022 2:32 AM, Malcolm McLean wrote:
> >>>>>>>>>> On Saturday, 25 June 2022 at 06:24:23 UTC+1, olcott wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On 6/25/2022 12:09 AM, Malcolm McLean wrote:
> >>>>>>>>>>>> On Saturday, 25 June 2022 at 05:33:53 UTC+1, olcott
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> >>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben
> >>>>>>>>>>>>>> Bacarisse wrote:
> >>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
> >>>>>>>>>>>>>>>> code, and determines
> >>>>>>>>>>>>>>>> what it does, without actually executing it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Going back, now, to what you think needs to be
> >>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it
> >>>>>>>>>>>>>>> doesn't halt. He's invoked H
> >>>>>>>>>>>>>>> | on it and H reports that it doesn't halt. He's run
> >>>>>>>>>>>>>>> P(P) and it halts.
> >>>>>>>>>>>>>>> The obvious conclusion is that PO's dry run (if he has
> >>>>>>>>>>>>>>> indeed done such
> >>>>>>>>>>>>>>> a thing) is incorrect.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Exactly.
> >>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>>>>>>>> tigers spend more energy
> >>>>>>>>>>>>>> than they take in. Well potentially this is dynamite.
> >>>>>>>>>>>>>> One explanation is that the
> >>>>>>>>>>>>>> law of conservation of energy is wrong.
> >>>>>>>>>>>>>> Except, before we countenance that explanation, we need
> >>>>>>>>>>>>>> to rule out a much
> >>>>>>>>>>>>>> simpler explanation. Which is that our measurements are
> >>>>>>>>>>>>>> wrong.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
> >>>>>>>>>>>>>> be doing, by dry-running
> >>>>>>>>>>>>>> it, and then actually run P(P) and obtained a different
> >>>>>>>>>>>>>> result. He also found that H
> >>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>>>>>>>> conclusion, but it is extensive
> >>>>>>>>>>>>>> and far-reaching in its implications. The behaviour of
> >>>>>>>>>>>>>> code when run is different
> >>>>>>>>>>>>>> from the correct behaviour of the code when simulated.
> >>>>>>>>>>>>>> If that's true, then it has
> >>>>>>>>>>>>>> similar implications for computer science that
> >>>>>>>>>>>>>> disproving the conservation law
> >>>>>>>>>>>>>> has for physics.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>>>>>>>> incorrect. Lots of people have
> >>>>>>>>>>>>>> suggested why it is incorrect. But they can't actually
> >>>>>>>>>>>>>> see the code. PO needs to
> >>>>>>>>>>>>>> understand that no-one will accept the complicated,
> >>>>>>>>>>>>>> far-reaching explanation,
> >>>>>>>>>>>>>> until the simple explanation has been ruled out.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I already proved that the dry run is correct.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Someone reports that tigers use more energy than they
> >>>>>>>>>>>> take in, and concludes that
> >>>>>>>>>>>> the energy conservation law is incorrect.
> >>>>>>>>>>>> Naturally, everyone is going to say "There must be some
> >>>>>>>>>>>> mistake. How were your
> >>>>>>>>>>>> measurements taken? Show us your calculations, maybe
> >>>>>>>>>>>> you've got your sums wrong."
> >>>>>>>>>>>>
> >>>>>>>>>>>> Now if they are also uncooperative about sharing the
> >>>>>>>>>>>> details of the investigation,
> >>>>>>>>>>>> those reservations will be magnified. There can be
> >>>>>>>>>>>> legitimate reasons. Tigers are
> >>>>>>>>>>>> rare and need to be conserved, you can't let anyone who
> >>>>>>>>>>>> wants have access to the
> >>>>>>>>>>>> tigers to try to repeat the measurements. But there's
> >>>>>>>>>>>> also a common illegitimate
> >>>>>>>>>>>> reason put forwards by people who make extraordinary
> >>>>>>>>>>>> claims. If the claims were
> >>>>>>>>>>>> unexceptional, such as that tigers have a similar energy
> >>>>>>>>>>>> budget to lions, then no-one
> >>>>>>>>>>>> would be saying "Show me your notebooks. How do you know
> >>>>>>>>>>>> that calorimeter was
> >>>>>>>>>>>> calibrated accurately? What's the name of the person who
> >>>>>>>>>>>> took that measurement
> >>>>>>>>>>>> and can I interview them?" Extraordinary claims are put
> >>>>>>>>>>>> through the wringer in a way
> >>>>>>>>>>>> that ordinary ones are not. I've seen complaints about
> >>>>>>>>>>>> this from parapsychologists.
> >>>>>>>>>>>> But if you're going to claim to have discovered a new
> >>>>>>>>>>>> physical principle, you need
> >>>>>>>>>>>> to present rock solid evidence.
> >>>>>>>>>>>>
> >>>>>>>>>>>> In this case, we can't see H. We can only suggest
> >>>>>>>>>>>> explanations for its behaviour.
> >>>>>>>>>>> It seems that you simply lack the technical competence.
> >>>>>>>>>>> Go back and look at my proof again.
> >>>>>>>>>>>
> >>>>>>>>>> Sorry no. I've been programming since I was a boy and I
> >>>>>>>>>> have a PhD in a computational-
> >>>>>>>>>> related subject. I'm confident of my technical abilities.
> >>>>>>>>>> What I can't do of course
> >>>>>>>>>> is tell you exactly what is going on in code I cannot see.
> >>>>>>>>>> I've got a pretty good idea,
> >>>>>>>>>> but I can only reconstruct on the basis of what you tell
> >>>>>>>>>> me. Ben thinks that I've
> >>>>>>>>>> got it wrong and in fact there are no nested emulations at
> >>>>>>>>>> all. I've no way of actually
> >>>>>>>>>> disproving that idea without seeing H.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> To fully understand this a software engineer must be an
> >>>>>>>>> expert in: (a) The C programming language,
> >>>>>>>>> (b) The x86 programming language,
> >>>>>>>>> (c) Exactly how C translates into x86 and,
> >>>>>>>>> (d) The ability to recognize infinite recursion at the x86
> >>>>>>>>> assembly language level.
> >>>>>>>>>
> >>>>>>>>> Anyone having the above credentials can validate my work, if
> >>>>>>>>> you cannot validate my work then you do not sufficiently
> >>>>>>>>> have the above credentials.
> >>>>>>>>>
> >>>>>>>>> Exactly how C translates into x86 is mandatory. If you don't
> >>>>>>>>> know how the C calling conventions are implemented in x86
> >>>>>>>>> you cannot validate my work.
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> void P(u32 x)
> >>>>>>>>> {
> >>>>>>>>>   if (H(x, x))
> >>>>>>>>>     HERE: goto HERE;
> >>>>>>>>>   return;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> int main()
> >>>>>>>>> {
> >>>>>>>>>   Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> _P()
> >>>>>>>>> [00001202](01)  55              push ebp
> >>>>>>>>> [00001203](02)  8bec            mov ebp,esp
> >>>>>>>>> [00001205](03)  8b4508          mov eax,[ebp+08]
> >>>>>>>>> [00001208](01)  50              push eax
> >>>>>>>>> [00001209](03)  8b4d08          mov ecx,[ebp+08]
> >>>>>>>>> [0000120c](01)  51              push ecx
> >>>>>>>>> [0000120d](05)  e820feffff      call 00001032
> >>>>>>>>> [00001212](03)  83c408          add esp,+08
> >>>>>>>>> [00001215](02)  85c0            test eax,eax
> >>>>>>>>> [00001217](02)  7402            jz 0000121b
> >>>>>>>>> [00001219](02)  ebfe            jmp 00001219
> >>>>>>>>> [0000121b](01)  5d              pop ebp
> >>>>>>>>> [0000121c](01)  c3              ret
> >>>>>>>>> Size in bytes:(0027) [0000121c]
> >>>>>>>>>
> >>>>>>>>> _main()
> >>>>>>>>> [00001222](01)  55              push ebp
> >>>>>>>>> [00001223](02)  8bec            mov ebp,esp
> >>>>>>>>> [00001225](05)  6802120000      push 00001202
> >>>>>>>>> [0000122a](05)  6802120000      push 00001202
> >>>>>>>>> [0000122f](05)  e8fefdffff      call 00001032
> >>>>>>>>> [00001234](03)  83c408          add esp,+08
> >>>>>>>>> [00001237](01)  50              push eax
> >>>>>>>>> [00001238](05)  68b3030000      push 000003b3
> >>>>>>>>> [0000123d](05)  e8c0f1ffff      call 00000402
> >>>>>>>>> [00001242](03)  83c408          add esp,+08
> >>>>>>>>> [00001245](02)  33c0            xor eax,eax
> >>>>>>>>> [00001247](01)  5d              pop ebp
> >>>>>>>>> [00001248](01)  c3              ret
> >>>>>>>>> Size in bytes:(0039) [00001248]
> >>>>>>>>>
> >>>>>>>>>  machine   stack     stack     machine    assembly
> >>>>>>>>>  address   address   data      code       language
> >>>>>>>>>  ========  ========  ========  =========  ============> >>>>>>>>> [00001222][0010200f][00000000] 55         push ebp
> >>>>>>>>> [00001223][0010200f][00000000] 8bec       mov ebp,esp
> >>>>>>>>> [00001225][0010200b][00001202] 6802120000 push 00001202 //
> >>>>>>>>> push P [0000122a][00102007][00001202] 6802120000 push
> >>>>>>>>> 00001202 // push P [0000122f][00102003][00001234] e8fefdffff
> >>>>>>>>> call 00001032 // call executed H
> >>>>>>>>>
> >>>>>>>>> Begin Simulation   Execution Trace Stored at:2120c3
> >>>>>>>>> Address_of_H:1032
> >>>>>>>>> [00001202][002120af][002120b3] 55         push ebp
> >>>>>>>>> [00001203][002120af][002120b3] 8bec       mov ebp,esp
> >>>>>>>>> [00001205][002120af][002120b3] 8b4508     mov eax,[ebp+08]
> >>>>>>>>> [00001208][002120ab][00001202] 50         push eax      //
> >>>>>>>>> push P [00001209][002120ab][00001202] 8b4d08     mov
> >>>>>>>>> ecx,[ebp+08] [0000120c][002120a7][00001202] 51         push
> >>>>>>>>> ecx      // push P [0000120d][002120a3][00001212] e820feffff
> >>>>>>>>> call 00001032 // 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. (c) H aborts its emulation of P before its call
> >>>>>>>>> to H is emulated.
> >>>>>>>>
> >>>>>>>> When you know that H simply implements the above algorithm
> >>>>>>>> there is no need to see its source code. I am reserving the
> >>>>>>>> publication of the 5 pages of the source code of the halt
> >>>>>>>> decider for journal publication.
> >>>>>>>
> >>>>>>> Your H is not a pure function as it behaves differently
> >>>>>>> depending on what is invoking it (it returns a decision answer
> >>>>>>> to main() but not to P()) and it has side effects (aborting a
> >>>>>>> simulation).
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> Finally a critique that has a reasonable basis.
> >>>>>>
> >>>>>> When I transformed H into a pure function of its inputs it
> >>>>>> always has the same behavior no matter how it is invoked.
> >>>>>>
> >>>>>> The x86 emulation of P is aborted before P invokes H.
> >>>>>
> >>>>> Nope. Preventing a call to H is equivalent to H behaving
> >>>>> differently for same inputs. Aborting a simulation is a side
> >>>>> effect: pure functions do not have side effects.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> In other words you are saying that a halt decider is simply not
> >>>> allowed to report when it correctly detects that it is being
> >>>> called in infinitely recursive simulation.
> >>>
> >>> I keep telling you this: the infinite recursion is NOT present
> >>> when using a valid halt decider: your H is NOT a valid halt
> >>> decider.
> >>>
> >>> Simulation is an erroneous approach as a simulating halt decider
> >>> can not answer in finite time for a non-halting input as there is
> >>> no proven general solution for detecting non-halting behaviour.
> >>>
> >>> /Flibble
> >>>
> >>
> >> IN OTHER WORDS THOROUGH LACK OF TECHNICAL COMPETANCE OR DISHONESTLY
> >> YOU DENY THIS VERIFIABLE FACT:
> >>
> >> 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.
> >
> > For [Strachey 1965] (and the proofs based on it) H is NOT a
> > simulating halt decider so there is no infinite recursion as there
> > is no emulation.
> >
> > Valid halt deciders ANALYSE P, they do not EMULATE P.
> >
> > /Flibble
> >
>
> I provide a halt decider H that gets the right answer and your
> rebuttal is that H does not get the right answer because there is
> another different halt decider named H1 that gets the wrong answer.

Click here to read the complete article

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

On Sat, 25 Jun 2022 11:58:20 -0700 (PDT)
Paul N <gw7rib@aol.com> 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.
>
> > 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.

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.

Click here to read the complete article