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.

--
Copyright 2022 Pete Olcott

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