On 6/22/2022 10:41 PM, Richard Damon wrote:
> On 6/22/22 10:55 PM, olcott wrote:
>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>> On 6/22/22 10:18 PM, olcott wrote:
>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>> their specified context
>>>>>>>>>>>
>>>>>>>>>>> Since you haven't actualy defined you context, and imply that
>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>
>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>> of the halting problem.
>>>>>>>>>>
>>>>>>>>>> #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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, if H actually is a program that does a COMPLETE and correct
>>>>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>
>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>
>>>>>>>>> Remember, the first analysis had the CONDITION on it that H did
>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>
>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>> and you have ignored it.
>>>>>>>>>
>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>> an incorrect rule.
>>>>>>>>
>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> static count = 0;
>>>>>>>>    count++;
>>>>>>>>    if count > 3)
>>>>>>>>      return;
>>>>>>>>    if (H(x, x))
>>>>>>>>      HERE: goto HERE;
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>> at elementary logic.
>>>>>>
>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>> that is not a valid counter-example is one form of deception or
>>>>>> another.
>>>>>>
>>>>>>
>>>>>
>>>>> P(P)
>>>>
>>>> That is not any example of (b), thus another mere strawman deception.
>>>>
>>>
>>> Why not?
>>>
>> It is not an example of the simulation of the input to H(P,P) at all.
>>
>>
>
> Why is P not P?
>

On 6/23/2022 12:13 AM, olcott wrote:
> On 6/22/2022 10:41 PM, Richard Damon wrote:
>> On 6/22/22 10:55 PM, olcott wrote:
>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>
>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>> that it is the halting problem, where they can not be
>>>>>>>>>>>> correct, that is not possible.
>>>>>>>>>>>>>
>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>
>>>>>>>>>>> #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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>> correct x86 emulation of its input, then YES, as I have said
>>>>>>>>>> many time before, this combination is non-halting.
>>>>>>>>>>
>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>
>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H
>>>>>>>>>> did a COMPLETE and correct x86 emulation.
>>>>>>>>>>
>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>> and you have ignored it.
>>>>>>>>>>
>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>> an incorrect rule.
>>>>>>>>>
>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>> static count = 0;
>>>>>>>>>    count++;
>>>>>>>>>    if count > 3)
>>>>>>>>>      return;
>>>>>>>>>    if (H(x, x))
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>
>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>> at elementary logic.
>>>>>>>
>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>> another.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> P(P)
>>>>>
>>>>> That is not any example of (b), thus another mere strawman deception.
>>>>>
>>>>
>>>> Why not?
>>>>
>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>
>>>
>>
>> Why is P not P?
>>
>
> It is not a direct rebuttal of my original claim.
>
> This would be a direct rebuttal:
> You must adapt P so that when H(P,P) emulates its input it determines
> that P never reaches its "ret" instruction and the adapted emulated P
> still reaches its "ret" instruction.
>

On 6/22/2022 9:48 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 10:46:14 PM UTC-4, 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.
>> There are no UTM's in software engineering thus yet another strawman
>> deception.
>
> Now you're just making things up. Of course there are UTMs. Anything that does a correct and complete emulation is a UTM.
>
> Just goes to show how desperate you're getting to make a statement like that.
>

On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
> >> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
> >> > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
> >> >> On 6/21/2022 9:52 PM, Richard Damon wrote:
> >> >>>
> >> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
> >> >>> was incorrect in its mapping, since the behavior of P(P) is the
> >> >>> DEFINITION of the behavior of H(P,P),
> >> >> Linz and others were aware that: 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.
> >> >> Linz and others made the false assumption that the actual behavior that
> >> >> is actually specified by the inputs to a simulating halt decider is not
> >> >> the same as the direct execution of these inputs. They were unaware of
> >> >> this because no one previously fully examined a simulating halt decider
> >> >> ever before.
> >> >>> especially if that is what P calls
> >> >>> and P is claimed to be built by the Linz template.
> >> >>>
> >> >>> So, either P isn't built right, or H isn't built fight, or H is wrong.
> >> >>
> >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
> >> > reports it as non-halting. So it's reasonable to assume that H is correct.
> >> >
> >> > However, when run, P(P) halts. So what are we to conclude? That "the
> >> > actual behaviour that is actually specified by the inputs to a simulating
> >> > halt decider is not the same as the direct execution of these inputs"?
> >>
> >> That is an actual immutable verified fact.
> >>
> > That's your conclusion from your observations and reasoning. You've
> > dry-run P(P), and it doesn't halt. You've run H on P(P), and it
> > reports "non-halting". You've run P(P), and it halts. So one
> > explanation is the one you've given but, as I said, that explanation
> > has rather far-reaching consequences.
> There is only one explanation. What you call the "dry-run" is not that
> same as the P(P). We've known this since the "line 15 commented out"
> days. There are two computations -- one that is not stopped and one
> that is, the "dry-run" and the run, the "simulation of the input to
> H(P,P)" and P(P). All PO is doing is trying to find words that hide
> what's going on.
>
I'm a scientists, not a mathematician.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.

Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data.

Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.

Now let's say that the result show that tigers use more energy than they
take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?

The third is what PO is doing.

On 6/23/22 1:19 AM, olcott wrote:
> On 6/23/2022 12:13 AM, olcott wrote:
>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>> On 6/22/22 10:55 PM, olcott wrote:
>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>> that it is the halting problem, where they can not be
>>>>>>>>>>>>> correct, that is not possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>
>>>>>>>>>>>> #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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>> correct x86 emulation of its input, then YES, as I have said
>>>>>>>>>>> many time before, this combination is non-halting.
>>>>>>>>>>>
>>>>>>>>>>> The fact that you need to keep going back to this, and seem
>>>>>>>>>>> to just be refusing to accept the conditions under which you
>>>>>>>>>>> have proved it just shows the problems with your thought
>>>>>>>>>>> process.
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>
>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H
>>>>>>>>>>> did a COMPLETE and correct x86 emulation.
>>>>>>>>>>>
>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>
>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>> an incorrect rule.
>>>>>>>>>>
>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> static count = 0;
>>>>>>>>>>    count++;
>>>>>>>>>>    if count > 3)
>>>>>>>>>>      return;
>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>> sometimes true, just it isn't an always true condition. You
>>>>>>>>> fail at elementary logic.
>>>>>>>>
>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>> another.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> P(P)
>>>>>>
>>>>>> That is not any example of (b), thus another mere strawman deception.
>>>>>>
>>>>>
>>>>> Why not?
>>>>>
>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>
>>>>
>>>
>>> Why is P not P?
>>>
>>
>> It is not a direct rebuttal of my original claim.
>>
>> This would be a direct rebuttal:
>> You must adapt P so that when H(P,P) emulates its input it determines
>> that P never reaches its "ret" instruction and the adapted emulated P
>> still reaches its "ret" instruction.
>>
>
> Unless you find that at least one input where it gets the wrong answer
> you have not refuted me.
>
>

On Thursday, June 23, 2022 at 2:20:40 AM UTC+1, olcott wrote:
> On 6/22/2022 8:05 PM, Dennis Bush wrote:
> > On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
> >> On 6/22/2022 7:48 PM, Richard Damon wrote:
> >>> On 6/22/22 8:37 PM, olcott 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));
> >> }

> I claim that H(P,P) correctly predicts that its complete and correct x86
> emulation of its input would never reach the "ret" instruction of P.

To split this claim down into three parts:

You are claiming that H(P,P) terminates.
You are claiming that the value returned by H(P,P) is zero/false, indicating that P(P) would not terminate.
You are claiming that this result is correct, and that P(P) does indeed not terminate.

This is what you are saying, correct?

So let's look at P(P). The first thing is does is call H(P,P). This, you have stated many times including just above, terminates. It gives a value zero. Thus the infinite loop is not entered, and the next instruction to be executed is the "return".

So P(P) does terminate, contrary to what you claimed.

On Wednesday, June 22, 2022 at 11:10:50 PM UTC+1, Jeff Barnett wrote:
> On 6/22/2022 12:10 PM, olcott wrote:
> > On 6/22/2022 12:11 PM, Jeff Barnett wrote:
> >> On 6/21/2022 8:38 PM, olcott wrote:
> > After 100 reviewers in a dozen forums over a period of one year:
> > On 6/14/2022 6:47 AM, Paul N wrote:
> > > Yes, it is clear to us humans watching
> > > it that the program is repeating itself.
> > > Thus we can appreciate that it will never
> > > reach the final "ret" - indeed, it won't
> > > even get to the infinite loop identified above.
> >
> > If H can determine that this is the case in a finite number of steps
> > then H could correctly reject its input on this basis.
> Let's give Paul N a little credit but not much; notice that he doesn't
> even understand the point of the exercise which is that the *same
> function* must be used for both inner and outer purposes.

Olcott has snipped part of the post where I did briefly address this. However, he did say that his purpose in posting to comp.lang.c and comp.lang.c++ was simply to check the language aspects of his posts, and they did seem OK on that basis. I've just put a post here on comp.theory addressing the more theoretical points, which hopefully will be more to your liking; if you disagree with the points I've made there then probably best to reply to that post directly.

On 23/06/2022 13:13, Paul N wrote:
> On Thursday, June 23, 2022 at 2:20:40 AM UTC+1, olcott wrote:
>> On 6/22/2022 8:05 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>> On 6/22/22 8:37 PM, olcott 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));
>>>> }
>
>> I claim that H(P,P) correctly predicts that its complete and correct x86
>> emulation of its input would never reach the "ret" instruction of P.
>
> To split this claim down into three parts:
>
> You are claiming that H(P,P) terminates.
> You are claiming that the value returned by H(P,P) is zero/false, indicating that P(P) would not terminate.
> You are claiming that this result is correct, and that P(P) does indeed not terminate.
>
> This is what you are saying, correct?
>
> So let's look at P(P). The first thing is does is call H(P,P). This, you have stated many times including just above, terminates. It gives a value zero. Thus the infinite loop is not entered, and the next instruction to be executed is the "return".
>
> So P(P) does terminate, contrary to what you claimed.
>

PO acknowledges that P(P) does terminate, and has posted one of his "traces" showing this. (Note:
his traces are not showing x86 instructions from a single x86 processor - the entries are from
multiple "logical processors" with some of the processors being simulated - the simulation logic
(including tests that may decide to terminate the simulating activity at some point) is suppressed
from the trace, so that you won't be "confused"!)

PO claims instead that :
- H(P,P) returns 0 (as you say)
- P(p) terminates
- H(P,P) is "correct" to return 0, even though 0 is the wrong halting
problem answer, because H's /simulation/ of P(P) never reaches P's
final ret instruction - this is correct, because H only simulates
until some internal test matches, at which point it stops
simulating P(P), and indeed that happens before P(P) simulation
gets as far as the P ret instruction.
PO has lots of incoherent waffle which serves only to confuse PO into believing that H is returning
the "correct" answer, when it is obviously wrong [from the HP perspective].

Mike.

On 6/23/2022 11:28 AM, Mike Terry wrote:
> On 23/06/2022 13:13, Paul N wrote:
>> On Thursday, June 23, 2022 at 2:20:40 AM UTC+1, olcott wrote:
>>> On 6/22/2022 8:05 PM, Dennis Bush wrote:
>>>> On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>> On 6/22/22 8:37 PM, olcott 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));
>>>>> }
>>
>>> I claim that H(P,P) correctly predicts that its complete and correct x86
>>> emulation of its input would never reach the "ret" instruction of P.
>>
>> To split this claim down into three parts:
>>
>> You are claiming that H(P,P) terminates.
>> You are claiming that the value returned by H(P,P) is zero/false,
>> indicating that P(P) would not terminate.
>> You are claiming that this result is correct, and that P(P) does
>> indeed not terminate.
>>
>> This is what you are saying, correct?
>>
>> So let's look at P(P). The first thing is does is call H(P,P). This,
>> you have stated many times including just above, terminates. It gives
>> a value zero. Thus the infinite loop is not entered, and the next
>> instruction to be executed is the "return".
>>
>> So P(P) does terminate, contrary to what you claimed.
>>
>
> PO acknowledges that P(P) does terminate, and has posted one of his
> "traces" showing this.  (Note: his traces are not showing x86
> instructions from a single x86 processor - the entries are from multiple
> "logical processors" with some of the processors being simulated - the
> simulation logic (including tests that may decide to terminate the
> simulating activity at some point) is suppressed from the trace, so that
> you won't be "confused"!)
>
> PO claims instead that :
> -   H(P,P) returns 0 (as you say)
> -   P(p) terminates
> -   H(P,P) is "correct" to return 0, even though 0 is the wrong halting
>     problem answer, because H's /simulation/ of P(P) never reaches P's
>     final ret instruction - this is correct, because H only simulates
>     until some internal test matches, at which point it stops
>     simulating P(P), and indeed that happens before P(P) simulation
>     gets as far as the P ret instruction.
> PO has lots of incoherent waffle which serves only to confuse PO into
> believing that H is returning the "correct" answer, when it is obviously
> wrong [from the HP perspective].
>
> Mike.

Hi Mike, I am glad to see you back. I count you as one of my
sufficiently technically qualified reviewers.

The key bottom line that everyone either makes sure to ignore or
directly disagrees with the correct semantics of the x86 language is
that H does correctly predict that its own complete and correct x86
emulation of its input would never reach the "ret" instruction (final
state) of P thus never halts.

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

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

--
Copyright 2022 Pete Olcott

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

On 6/23/2022 7:13 AM, Paul N wrote:
> On Thursday, June 23, 2022 at 2:20:40 AM UTC+1, olcott wrote:
>> On 6/22/2022 8:05 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>> On 6/22/22 8:37 PM, olcott 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));
>>>> }
>
>> I claim that H(P,P) correctly predicts that its complete and correct x86
>> emulation of its input would never reach the "ret" instruction of P.
>
> To split this claim down into three parts:
>
> You are claiming that H(P,P) terminates.

Yes

> You are claiming that the value returned by H(P,P) is zero/false, indicating that P(P) would not terminate.

No. zero/false indicates that
H(P,P) does correctly determine that its correct and complete x86
emulation of its input would never reach the "ret" instruction of P.

As shown below because P(P) depends on the return value of H(P,P) it has
different behavior than the correctly emulated input to H(P,P).

The correctly emulated input to H(P,P) is stuck in recursive emulation
that never gets to the point of receiving a return value from H, thus
lacks the dependency of the executed P(P). This causes it to have
different behavior than the executed P(P) having this dependency.

> You are claiming that this result is correct, and that P(P) does indeed not terminate.
>
> This is what you are saying, correct?
>
> So let's look at P(P). The first thing is does is call H(P,P). This, you have stated many times including just above, terminates. It gives a value zero. Thus the infinite loop is not entered, and the next instruction to be executed is the "return".
>
> So P(P) does terminate, contrary to what you claimed.

To fully understand this code 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.

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

In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]

_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H

Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call 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.

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

--
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/23/2022 7:20 AM, Paul N wrote:
> On Wednesday, June 22, 2022 at 11:10:50 PM UTC+1, Jeff Barnett wrote:
>> On 6/22/2022 12:10 PM, olcott wrote:
>>> On 6/22/2022 12:11 PM, Jeff Barnett wrote:
>>>> On 6/21/2022 8:38 PM, olcott wrote:
>>> After 100 reviewers in a dozen forums over a period of one year:
>>> On 6/14/2022 6:47 AM, Paul N wrote:
>>>> Yes, it is clear to us humans watching
>>>> it that the program is repeating itself.
>>>> Thus we can appreciate that it will never
>>>> reach the final "ret" - indeed, it won't
>>>> even get to the infinite loop identified above.
>>>
>>> If H can determine that this is the case in a finite number of steps
>>> then H could correctly reject its input on this basis.
>> Let's give Paul N a little credit but not much; notice that he doesn't
>> even understand the point of the exercise which is that the *same
>> function* must be used for both inner and outer purposes.
>
> Olcott has snipped part of the post where I did briefly address this. However, he did say that his purpose in posting to comp.lang.c and comp.lang.c++ was simply to check the language aspects of his posts, and they did seem OK on that basis. I've just put a post here on comp.theory addressing the more theoretical points, which hopefully will be more to your liking; if you disagree with the points I've made there then probably best to reply to that post directly.

I have already addressed your other post completely and I stuck with
pure software engineering terms and concepts conclusively proving that
the dependency relationship that P(P) has on H(P,P) causes its behavior
to be quite different than the complete and correct x86 emulation of the
input to H(P,P) that has no such dependency relationship.

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

In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.

--
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/23/2022 3:19 AM, Malcolm McLean wrote:
> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>> Linz and others were aware that: 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.
>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>> ever before.
>>>>>>> especially if that is what P calls
>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>
>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>
>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>
>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>
>>>> That is an actual immutable verified fact.
>>>>
>>> That's your conclusion from your observations and reasoning. You've
>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>> reports "non-halting". You've run P(P), and it halts. So one
>>> explanation is the one you've given but, as I said, that explanation
>>> has rather far-reaching consequences.
>> There is only one explanation. What you call the "dry-run" is not that
>> same as the P(P). We've known this since the "line 15 commented out"
>> days. There are two computations -- one that is not stopped and one
>> that is, the "dry-run" and the run, the "simulation of the input to
>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>> what's going on.
>>
> I'm a scientists, not a mathematician.
> The example I always use is that you are doing an energy budget for tigers.
> You work how much they use on running about, lactating, maintaining their
> body temperature, and so on.
>
> Now let's say that you find that all results are within a few percentage points
> of a similar budget done for lions. You'd instantly accept this data.
>
> Now let's say that the results are wildly different from a previous budget done
> for lions. You wouldn't just accept that data. You'd check. You'd want to
> understand the reasons tigers spend far less energy on movement than lions.
>
> Now let's say that the result show that tigers use more energy than they
> take in food. Would you instantly conclude that the law of conservation of
> energy must be incorrect?
>
> The third is what PO is doing.

I rewrote this up so that sufficiently competent software engineers
would be able to confirm that the following is correct:

To fully understand this code 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.

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

In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.

The dependency relationship that P(P) has on H(P,P) causes its behavior
to be quite different than the complete and correct x86 emulation of the
input to H(P,P) that has no such dependency relationship.

As shown below because P(P) depends on the return value of H(P,P) it has
different behavior than the correctly emulated input to H(P,P).

The correctly emulated input to H(P,P) remains stuck in recursive
emulation that never gets to the point of receiving a return value from
H, thus lacks the dependency of the executed P(P).

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]

_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H

Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

--
Copyright 2022 Pete Olcott

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

i tell ten lines of intelligence daniel2391++

// high order reason for solving all qbfs of model set s
// transform all boolean models into all true questions
// ergo of thought is trailing universalism
static joy think (num vee, numnums& ezists, numnums& univessel)
{// when ezists isnay fill with univesselism
if (ezists.size() == zero) {
for (num g = zero; g < univessel.size(); g++) ezists.add(univessel[g]);
univessel.setsize(zero); return; }
// span deeper left span right
numnums al; numnums ar; span(vee + one, ezists, al, ar); ezists.setsize(zero);
numnums bl; numnums br; span(vee + one, univessel, bl, br); univessel.setsize(zero);
// think left think right
think(vee + one, al, bl);
think(vee + one, ar, br);
// reorder left right
for (num g = zero; g < al.size(); g++) { ezists.add(al[g]); }
for (num g = zero; g < ar.size(); g++) { ezists.add(ar[g]); }
for (num g = zero; g < bl.size(); g++) { univessel.add(bl[g]); }
for (num g = zero; g < br.size(); g++) { univessel.add(br[g]); } }

static joy spread (num vee, numnums& models) {
// vee true to right rest to left
numnums left;
numnums right;
span(vee, models, left, right); models.setsize(zero);
// spread left right then think
when( left.size()) spread(vee + one, left);
when(right.size()) spread(vee + one, right);
// left justify with right
think (vee, left, right);
// the vee level of the twiddle is primary depth
//
// note bring universal plan into ezistance affirmation to vee bit having spread vee plus one
for (num gee = zero; gee < left.size(); gee++) { ezis(*( left[gee]), vee); models.add( left[gee]); } left.setsize(zero);
// note universal plan ezists as needed
for (num g = zero; g < right.size(); g++) { univ(*(right[g]), vee); models.add(right[g]); } right.setsize(zero); }

static joy zerotoone /*bit is on*/(nums& s, num b) { (s[b >> five] += (ones[b & fifthtau])); } //
static num be /*is bit on*/(nums& s, num b) { return (s[b >> five] & (ones[b & fifthtau])); } //
static joy ezis(nums& s, num b) { s[b >> five] &= zeroes[b & fifthtau]; } //
static joy univ(nums& s, num b) { s[b >> five] & ones[b & fifthtau]; } //
static joy span /*leftright around bit*/(num b, numnums& s, numnums& l, numnums& r) // left right on bit b //
{for (num g = zero; g < s.size(); g++) if (be((*s[g]), b)) r.add(s[g]); else l.add(s[g]); } // oh of s.size() //

On Thu, 23 Jun 2022 00:19:23 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/23/2022 12:13 AM, olcott wrote:
> > On 6/22/2022 10:41 PM, Richard Damon wrote:
> >> On 6/22/22 10:55 PM, olcott wrote:
> >>> On 6/22/2022 9:34 PM, Richard Damon wrote:
> >>>> On 6/22/22 10:18 PM, olcott wrote:
> >>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
> >>>>>> On 6/22/22 9:41 PM, olcott wrote:
> >>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
> >>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
> >>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>> First you agree that my words are perfectly correct
> >>>>>>>>>>>>> within their specified context
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since you haven't actualy defined you context, and imply
> >>>>>>>>>>>> that it is the halting problem, where they can not be
> >>>>>>>>>>>> correct, that is not possible.
> >>>>>>>>>>>>>
> >>>>>>>>>>> First you agree that these words are 100% correct within
> >>>>>>>>>>> the context of software engineering totally ignoring the
> >>>>>>>>>>> context of the halting problem.
> >>>>>>>>>>>
> >>>>>>>>>>> #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.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> So, if H actually is a program that does a COMPLETE and
> >>>>>>>>>> correct x86 emulation of its input, then YES, as I have
> >>>>>>>>>> said many time before, this combination is non-halting.
> >>>>>>>>>>
> >>>>>>>>>> The fact that you need to keep going back to this, and
> >>>>>>>>>> seem to just be refusing to accept the conditions under
> >>>>>>>>>> which you have proved it just shows the problems with your
> >>>>>>>>>> thought process.
> >>>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> Except that NOW H isn't the H we were just talking about,
> >>>>>>>>>> so you are just proving that you are either lying or an
> >>>>>>>>>> idiot.
> >>>>>>>>>>
> >>>>>>>>>> Remember, the first analysis had the CONDITION on it that
> >>>>>>>>>> H did a COMPLETE and correct x86 emulation.
> >>>>>>>>>>
> >>>>>>>>>> Once you remove that property form H, that conclusion no
> >>>>>>>>>> long holds and you are shown to be a lying idiot.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out
> >>>>>>>>>> before, and you have ignored it.
> >>>>>>>>>>
> >>>>>>>>> That you don't understand what I mean does not mean that it
> >>>>>>>>> is an incorrect rule.
> >>>>>>>>>
> >>>>>>>>> Here is an example where P does have instruction that could
> >>>>>>>>> possibly escape this otherwise infinitely recursive
> >>>>>>>>> emulation:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> void P(ptr x)
> >>>>>>>>> {
> >>>>>>>>> static count = 0;
> >>>>>>>>>    count++;
> >>>>>>>>>    if count > 3)
> >>>>>>>>>      return;
> >>>>>>>>>    if (H(x, x))
> >>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>    return;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> FALLACY of proof by example. I never said that (b) isn't
> >>>>>>>> sometimes true, just it isn't an always true condition. You
> >>>>>>>> fail at elementary logic.
> >>>>>>>
> >>>>>>> Try and find a valid counter-example. Every attempt at
> >>>>>>> rebuttal that is not a valid counter-example is one form of
> >>>>>>> deception or another.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> P(P)
> >>>>>
> >>>>> That is not any example of (b), thus another mere strawman
> >>>>> deception.
> >>>>
> >>>> Why not?
> >>>>
> >>> It is not an example of the simulation of the input to H(P,P) at
> >>> all.
> >>>
> >>>
> >>
> >> Why is P not P?
> >>
> >
> > It is not a direct rebuttal of my original claim.
> >
> > This would be a direct rebuttal:
> > You must adapt P so that when H(P,P) emulates its input it
> > determines that P never reaches its "ret" instruction and the
> > adapted emulated P still reaches its "ret" instruction.
> >
>
> Unless you find that at least one input where it gets the wrong
> answer you have not refuted me.

On 6/23/2022 2:41 PM, Mr Flibble wrote:
> On Thu, 23 Jun 2022 00:19:23 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/23/2022 12:13 AM, olcott wrote:
>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First you agree that my words are perfectly correct
>>>>>>>>>>>>>>> within their specified context
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>>> that it is the halting problem, where they can not be
>>>>>>>>>>>>>> correct, that is not possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> First you agree that these words are 100% correct within
>>>>>>>>>>>>> the context of software engineering totally ignoring the
>>>>>>>>>>>>> context of the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>>> correct x86 emulation of its input, then YES, as I have
>>>>>>>>>>>> said many time before, this combination is non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that you need to keep going back to this, and
>>>>>>>>>>>> seem to just be refusing to accept the conditions under
>>>>>>>>>>>> which you have proved it just shows the problems with your
>>>>>>>>>>>> thought process.
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about,
>>>>>>>>>>>> so you are just proving that you are either lying or an
>>>>>>>>>>>> idiot.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that
>>>>>>>>>>>> H did a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Once you remove that property form H, that conclusion no
>>>>>>>>>>>> long holds and you are shown to be a lying idiot.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out
>>>>>>>>>>>> before, and you have ignored it.
>>>>>>>>>>>>
>>>>>>>>>>> That you don't understand what I mean does not mean that it
>>>>>>>>>>> is an incorrect rule.
>>>>>>>>>>>
>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>> possibly escape this otherwise infinitely recursive
>>>>>>>>>>> emulation:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> static count = 0;
>>>>>>>>>>>    count++;
>>>>>>>>>>>    if count > 3)
>>>>>>>>>>>      return;
>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>> sometimes true, just it isn't an always true condition. You
>>>>>>>>>> fail at elementary logic.
>>>>>>>>>
>>>>>>>>> Try and find a valid counter-example. Every attempt at
>>>>>>>>> rebuttal that is not a valid counter-example is one form of
>>>>>>>>> deception or another.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> P(P)
>>>>>>>
>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>> deception.
>>>>>>
>>>>>> Why not?
>>>>>>
>>>>> It is not an example of the simulation of the input to H(P,P) at
>>>>> all.
>>>>>
>>>>>
>>>>
>>>> Why is P not P?
>>>>
>>>
>>> It is not a direct rebuttal of my original claim.
>>>
>>> This would be a direct rebuttal:
>>> You must adapt P so that when H(P,P) emulates its input it
>>> determines that P never reaches its "ret" instruction and the
>>> adapted emulated P still reaches its "ret" instruction.
>>>
>>
>> Unless you find that at least one input where it gets the wrong
>> answer you have not refuted me.
>
> Here:
>
> 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
>
>

On Thu, 23 Jun 2022 14:56:26 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/23/2022 2:41 PM, Mr Flibble wrote:
> > On Thu, 23 Jun 2022 00:19:23 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/23/2022 12:13 AM, olcott wrote:
> >>> On 6/22/2022 10:41 PM, Richard Damon wrote:
> >>>> On 6/22/22 10:55 PM, olcott wrote:
> >>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
> >>>>>> On 6/22/22 10:18 PM, olcott wrote:
> >>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
> >>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
> >>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
> >>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
> >>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
> >>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> First you agree that my words are perfectly correct
> >>>>>>>>>>>>>>> within their specified context
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Since you haven't actualy defined you context, and
> >>>>>>>>>>>>>> imply that it is the halting problem, where they can
> >>>>>>>>>>>>>> not be correct, that is not possible.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> First you agree that these words are 100% correct within
> >>>>>>>>>>>>> the context of software engineering totally ignoring the
> >>>>>>>>>>>>> context of the halting problem.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> #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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
> >>>>>>>>>>>> correct x86 emulation of its input, then YES, as I have
> >>>>>>>>>>>> said many time before, this combination is non-halting.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The fact that you need to keep going back to this, and
> >>>>>>>>>>>> seem to just be refusing to accept the conditions under
> >>>>>>>>>>>> which you have proved it just shows the problems with
> >>>>>>>>>>>> your thought process.
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Except that NOW H isn't the H we were just talking about,
> >>>>>>>>>>>> so you are just proving that you are either lying or an
> >>>>>>>>>>>> idiot.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that
> >>>>>>>>>>>> H did a COMPLETE and correct x86 emulation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Once you remove that property form H, that conclusion no
> >>>>>>>>>>>> long holds and you are shown to be a lying idiot.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out
> >>>>>>>>>>>> before, and you have ignored it.
> >>>>>>>>>>>>
> >>>>>>>>>>> That you don't understand what I mean does not mean that
> >>>>>>>>>>> it is an incorrect rule.
> >>>>>>>>>>>
> >>>>>>>>>>> Here is an example where P does have instruction that
> >>>>>>>>>>> could possibly escape this otherwise infinitely recursive
> >>>>>>>>>>> emulation:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>> {
> >>>>>>>>>>> static count = 0;
> >>>>>>>>>>>    count++;
> >>>>>>>>>>>    if count > 3)
> >>>>>>>>>>>      return;
> >>>>>>>>>>>    if (H(x, x))
> >>>>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>>>    return;
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
> >>>>>>>>>> sometimes true, just it isn't an always true condition. You
> >>>>>>>>>> fail at elementary logic.
> >>>>>>>>>
> >>>>>>>>> Try and find a valid counter-example. Every attempt at
> >>>>>>>>> rebuttal that is not a valid counter-example is one form of
> >>>>>>>>> deception or another.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> P(P)
> >>>>>>>
> >>>>>>> That is not any example of (b), thus another mere strawman
> >>>>>>> deception.
> >>>>>>
> >>>>>> Why not?
> >>>>>>
> >>>>> It is not an example of the simulation of the input to H(P,P) at
> >>>>> all.
> >>>>>
> >>>>>
> >>>>
> >>>> Why is P not P?
> >>>>
> >>>
> >>> It is not a direct rebuttal of my original claim.
> >>>
> >>> This would be a direct rebuttal:
> >>> You must adapt P so that when H(P,P) emulates its input it
> >>> determines that P never reaches its "ret" instruction and the
> >>> adapted emulated P still reaches its "ret" instruction.
> >>>
> >>
> >> Unless you find that at least one input where it gets the wrong
> >> answer you have not refuted me.
> >
> > Here:
> >
> > 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
> >
> >
>
> To fully understand this code 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.
>
> The ordinary semantics of standard C and the conventional x86
> language are the entire semantics required to conclusively prove that
> H(Px,Px) does correctly determine that its correct and complete x86
> emulation of its input would never reach the "ret" instruction of Px.
>
> It is always the case that whenever anyone disagrees with verifiable
> facts (as you have just done) that they are necessarily always
> incorrect.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>> >> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>> >> > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>> >> >> On 6/21/2022 9:52 PM, Richard Damon wrote:
>> >> >>>
>> >> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>> >> >>> was incorrect in its mapping, since the behavior of P(P) is the
>> >> >>> DEFINITION of the behavior of H(P,P),
>> >> >> Linz and others were aware that: 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.
>> >> >> Linz and others made the false assumption that the actual behavior that
>> >> >> is actually specified by the inputs to a simulating halt decider is not
>> >> >> the same as the direct execution of these inputs. They were unaware of
>> >> >> this because no one previously fully examined a simulating halt decider
>> >> >> ever before.
>> >> >>> especially if that is what P calls
>> >> >>> and P is claimed to be built by the Linz template.
>> >> >>>
>> >> >>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>> >> >>
>> >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>> >> > reports it as non-halting. So it's reasonable to assume that H is correct.
>> >> >
>> >> > However, when run, P(P) halts. So what are we to conclude? That "the
>> >> > actual behaviour that is actually specified by the inputs to a simulating
>> >> > halt decider is not the same as the direct execution of these inputs"?
>> >>
>> >> That is an actual immutable verified fact.
>> >>
>> > That's your conclusion from your observations and reasoning. You've
>> > dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>> > reports "non-halting". You've run P(P), and it halts. So one
>> > explanation is the one you've given but, as I said, that explanation
>> > has rather far-reaching consequences.
>> There is only one explanation. What you call the "dry-run" is not that
>> same as the P(P). We've known this since the "line 15 commented out"
>> days. There are two computations -- one that is not stopped and one
>> that is, the "dry-run" and the run, the "simulation of the input to
>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>> what's going on.
>>
> I'm a scientists, not a mathematician.
> The example I always use is that you are doing an energy budget for tigers.
> You work how much they use on running about, lactating, maintaining their
> body temperature, and so on.
>
> Now let's say that you find that all results are within a few percentage points
> of a similar budget done for lions. You'd instantly accept this data.
>
> Now let's say that the results are wildly different from a previous budget done
> for lions. You wouldn't just accept that data. You'd check. You'd want to
> understand the reasons tigers spend far less energy on movement than lions.
>
> Now let's say that the result show that tigers use more energy than they
> take in food. Would you instantly conclude that the law of conservation of
> energy must be incorrect?
>
> The third is what PO is doing.

I have no idea what parts of this analogy map to the current situation.
PO has no contradictory results about anything. There's no conflict
with any established facts in anything he is doing.

--
Ben.

On 6/23/22 2:14 PM, olcott wrote:
> On 6/23/2022 3:19 AM, Malcolm McLean wrote:
>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0,
>>>>>>>> so H
>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>> Linz and others were aware that: 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.
>>>>>>> Linz and others made the false assumption that the actual
>>>>>>> behavior that
>>>>>>> is actually specified by the inputs to a simulating halt decider
>>>>>>> is not
>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>> unaware of
>>>>>>> this because no one previously fully examined a simulating halt
>>>>>>> decider
>>>>>>> ever before.
>>>>>>>> especially if that is what P calls
>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>
>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is
>>>>>>>> wrong.
>>>>>>>
>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>> decider H
>>>>>> reports it as non-halting. So it's reasonable to assume that H is
>>>>>> correct.
>>>>>>
>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>> simulating
>>>>>> halt decider is not the same as the direct execution of these
>>>>>> inputs"?
>>>>>
>>>>> That is an actual immutable verified fact.
>>>>>
>>>> That's your conclusion from your observations and reasoning. You've
>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>> explanation is the one you've given but, as I said, that explanation
>>>> has rather far-reaching consequences.
>>> There is only one explanation. What you call the "dry-run" is not that
>>> same as the P(P). We've known this since the "line 15 commented out"
>>> days. There are two computations -- one that is not stopped and one
>>> that is, the "dry-run" and the run, the "simulation of the input to
>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>> what's going on.
>>>
>> I'm a scientists, not a mathematician.
>> The example I always use is that you are doing an energy budget for
>> tigers.
>> You work how much they use on running about, lactating, maintaining their
>> body temperature, and so on.
>>
>> Now let's say that you find that all results are within a few
>> percentage points
>> of a similar budget done for lions. You'd instantly accept this data.
>>
>> Now let's say that the results are wildly different from a previous
>> budget done
>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>> understand the reasons tigers spend far less energy on movement than
>> lions.
>>
>> Now let's say that the result show that tigers use more energy than they
>> take in food. Would you instantly conclude that the law of
>> conservation of
>> energy must be incorrect?
>>
>> The third is what PO is doing.
>
> I rewrote this up so that sufficiently competent software engineers
> would be able to confirm that the following is correct:
>
> To fully understand this code 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.
>
> 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 of P.
>
> In computer science terminology this means that complete and correct
> emulation P by H would never reach its final state and halt.
>
> The dependency relationship that P(P) has on H(P,P) causes its behavior
> to be quite different than the complete and correct x86 emulation of the
> input to H(P,P) that has no such dependency relationship.
>
> As shown below because P(P) depends on the return value of H(P,P) it has
> different behavior than the correctly emulated input to H(P,P).
>
> The correctly emulated input to H(P,P) remains stuck in recursive
> emulation that never gets to the point of receiving a return value from
> H, thus lacks the dependency of the executed P(P).
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000011f0](01)  55              push ebp
> [000011f1](02)  8bec            mov ebp,esp
> [000011f3](03)  8b4508          mov eax,[ebp+08]
> [000011f6](01)  50              push eax
> [000011f7](03)  8b4d08          mov ecx,[ebp+08]
> [000011fa](01)  51              push ecx
> [000011fb](05)  e820feffff      call 00001020
> [00001200](03)  83c408          add esp,+08
> [00001203](02)  85c0            test eax,eax
> [00001205](02)  7402            jz 00001209
> [00001207](02)  ebfe            jmp 00001207
> [00001209](01)  5d              pop ebp
> [0000120a](01)  c3              ret
> Size in bytes:(0027) [0000120a]
>
> _main()
> [00001210](01)  55              push ebp
> [00001211](02)  8bec            mov ebp,esp
> [00001213](05)  68f0110000      push 000011f0
> [00001218](05)  e8d3ffffff      call 000011f0
> [0000121d](03)  83c404          add esp,+04
> [00001220](02)  33c0            xor eax,eax
> [00001222](01)  5d              pop ebp
> [00001223](01)  c3              ret
> Size in bytes:(0020) [00001223]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001210][00101fba][00000000] 55         push ebp
> [00001211][00101fba][00000000] 8bec       mov ebp,esp
> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> [000011f0][00101fae][00101fba] 55         push ebp      // enter executed P
> [000011f1][00101fae][00101fba] 8bec       mov ebp,esp
> [000011f3][00101fae][00101fba] 8b4508     mov eax,[ebp+08]
> [000011f6][00101faa][000011f0] 50         push eax      // push P
> [000011f7][00101faa][000011f0] 8b4d08     mov ecx,[ebp+08]
> [000011fa][00101fa6][000011f0] 51         push ecx      // push P
> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>
> Begin Simulation   Execution Trace Stored at:21206e
> Address_of_H:1020
> [000011f0][0021205a][0021205e] 55         push ebp      // enter emulated P
> [000011f1][0021205a][0021205e] 8bec       mov ebp,esp
> [000011f3][0021205a][0021205e] 8b4508     mov eax,[ebp+08]
> [000011f6][00212056][000011f0] 50         push eax      // push P
> [000011f7][00212056][000011f0] 8b4d08     mov ecx,[ebp+08]
> [000011fa][00212052][000011f0] 51         push ecx      // push P
> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily examine
> its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
> (c) H aborts its emulation of P before its call to H is emulated.
>
> [00001200][00101fae][00101fba] 83c408     add esp,+08   // return to
> executed P
> [00001203][00101fae][00101fba] 85c0       test eax,eax
> [00001205][00101fae][00101fba] 7402       jz 00001209
> [00001209][00101fb2][0000121d] 5d         pop ebp
> [0000120a][00101fb6][000011f0] c3         ret           // return from
> executed P
> [0000121d][00101fba][00000000] 83c404     add esp,+04
> [00001220][00101fba][00000000] 33c0       xor eax,eax
> [00001222][00101fbe][00100000] 5d         pop ebp
> [00001223][00101fc2][00000000] c3         ret           // ret from main
> Number of Instructions Executed(878) / 67 = 13 pages
>
>

On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
> On 6/22/2022 10:41 PM, Richard Damon wrote:
> > On 6/22/22 10:55 PM, olcott wrote:
> >> On 6/22/2022 9:34 PM, Richard Damon wrote:
> >>> On 6/22/22 10:18 PM, olcott wrote:
> >>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
> >>>>> On 6/22/22 9:41 PM, olcott wrote:
> >>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
> >>>>>>> On 6/22/22 9:29 PM, olcott wrote:
> >>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
> >>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
> >>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
> >>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> First you agree that my words are perfectly correct within
> >>>>>>>>>>>> their specified context
> >>>>>>>>>>>
> >>>>>>>>>>> Since you haven't actualy defined you context, and imply that
> >>>>>>>>>>> it is the halting problem, where they can not be correct,
> >>>>>>>>>>> that is not possible.
> >>>>>>>>>>>>
> >>>>>>>>>> First you agree that these words are 100% correct within the
> >>>>>>>>>> context of software engineering totally ignoring the context
> >>>>>>>>>> of the halting problem.
> >>>>>>>>>>
> >>>>>>>>>> #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.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So, if H actually is a program that does a COMPLETE and correct
> >>>>>>>>> x86 emulation of its input, then YES, as I have said many time
> >>>>>>>>> before, this combination is non-halting.
> >>>>>>>>>
> >>>>>>>>> The fact that you need to keep going back to this, and seem to
> >>>>>>>>> just be refusing to accept the conditions under which you have
> >>>>>>>>> proved it just shows the problems with your thought process.
> >>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> Except that NOW H isn't the H we were just talking about, so
> >>>>>>>>> you are just proving that you are either lying or an idiot.
> >>>>>>>>>
> >>>>>>>>> Remember, the first analysis had the CONDITION on it that H did
> >>>>>>>>> a COMPLETE and correct x86 emulation.
> >>>>>>>>>
> >>>>>>>>> Once you remove that property form H, that conclusion no long
> >>>>>>>>> holds and you are shown to be a lying idiot.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
> >>>>>>>>> and you have ignored it.
> >>>>>>>>>
> >>>>>>>> That you don't understand what I mean does not mean that it is
> >>>>>>>> an incorrect rule.
> >>>>>>>>
> >>>>>>>> Here is an example where P does have instruction that could
> >>>>>>>> possibly escape this otherwise infinitely recursive emulation:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> void P(ptr x)
> >>>>>>>> {
> >>>>>>>> static count = 0;
> >>>>>>>> count++;
> >>>>>>>> if count > 3)
> >>>>>>>> return;
> >>>>>>>> if (H(x, x))
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>
> >>>>>>> FALLACY of proof by example. I never said that (b) isn't
> >>>>>>> sometimes true, just it isn't an always true condition. You fail
> >>>>>>> at elementary logic.
> >>>>>>
> >>>>>> Try and find a valid counter-example. Every attempt at rebuttal
> >>>>>> that is not a valid counter-example is one form of deception or
> >>>>>> another.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> P(P)
> >>>>
> >>>> That is not any example of (b), thus another mere strawman deception.
> >>>>
> >>>
> >>> Why not?
> >>>
> >> It is not an example of the simulation of the input to H(P,P) at all.
> >>
> >>
> >
> > Why is P not P?
> >
> It is not a direct rebuttal of my original claim.

Click here to read the complete article

On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>> On 6/22/22 10:55 PM, olcott wrote:
>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply that
>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>
>>>>>>>>>>>> #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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and correct
>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>
>>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>
>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H did
>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>
>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>
>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>> an incorrect rule.
>>>>>>>>>>
>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> static count = 0;
>>>>>>>>>> count++;
>>>>>>>>>> if count > 3)
>>>>>>>>>> return;
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>>> at elementary logic.
>>>>>>>>
>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>> another.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> P(P)
>>>>>>
>>>>>> That is not any example of (b), thus another mere strawman deception.
>>>>>>
>>>>>
>>>>> Why not?
>>>>>
>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>
>>>>
>>>
>>> Why is P not P?
>>>
>> It is not a direct rebuttal of my original claim.
>
> And what exactly was your original claim?

On 6/23/2022 5:44 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>> Linz and others were aware that: 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.
>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>> ever before.
>>>>>>>> especially if that is what P calls
>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>
>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>
>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>
>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>
>>>>> That is an actual immutable verified fact.
>>>>>
>>>> That's your conclusion from your observations and reasoning. You've
>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>> explanation is the one you've given but, as I said, that explanation
>>>> has rather far-reaching consequences.
>>> There is only one explanation. What you call the "dry-run" is not that
>>> same as the P(P). We've known this since the "line 15 commented out"
>>> days. There are two computations -- one that is not stopped and one
>>> that is, the "dry-run" and the run, the "simulation of the input to
>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>> what's going on.
>>>
>> I'm a scientists, not a mathematician.
>> The example I always use is that you are doing an energy budget for tigers.
>> You work how much they use on running about, lactating, maintaining their
>> body temperature, and so on.
>>
>> Now let's say that you find that all results are within a few percentage points
>> of a similar budget done for lions. You'd instantly accept this data.
>>
>> Now let's say that the results are wildly different from a previous budget done
>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>> understand the reasons tigers spend far less energy on movement than lions.
>>
>> Now let's say that the result show that tigers use more energy than they
>> take in food. Would you instantly conclude that the law of conservation of
>> energy must be incorrect?
>>
>> The third is what PO is doing.
>
> I have no idea what parts of this analogy map to the current situation.
> PO has no contradictory results about anything. There's no conflict
> with any established facts in anything he is doing.
>

Thanks for that.

--
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/23/22 9:38 PM, olcott wrote:
> On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
>> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply that
>>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and correct
>>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H did
>>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>>
>>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>>> an incorrect rule.
>>>>>>>>>>>
>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> static count = 0;
>>>>>>>>>>>     count++;
>>>>>>>>>>>     if count > 3)
>>>>>>>>>>>       return;
>>>>>>>>>>>     if (H(x, x))
>>>>>>>>>>>       HERE: goto HERE;
>>>>>>>>>>>     return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>>>> at elementary logic.
>>>>>>>>>
>>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>>> another.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> P(P)
>>>>>>>
>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>> deception.
>>>>>>>
>>>>>>
>>>>>> Why not?
>>>>>>
>>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>>
>>>>>
>>>>
>>>> Why is P not P?
>>>>
>>> It is not a direct rebuttal of my original claim.
>> And what exactly was your original claim?
>
> H is always correct when it determines that an emulated input specifies
> infinitely nested emulation whenever H matches the (a)(b)(c) criteria to
> the behavior of this input.
>
> Obviously a rebuttal would be to find a case where H is incorrect under
> these exact same conditions.
>

On 6/23/2022 8:59 PM, Richard Damon wrote:
>
> On 6/23/22 9:38 PM, olcott wrote:
>> On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
>>> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>>>> correct
>>>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>>>>>>>>> just be refusing to accept the conditions under which you have
>>>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that H
>>>>>>>>>>>>> did
>>>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>>>
>>>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>>>> an incorrect rule.
>>>>>>>>>>>>
>>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> static count = 0;
>>>>>>>>>>>>     count++;
>>>>>>>>>>>>     if count > 3)
>>>>>>>>>>>>       return;
>>>>>>>>>>>>     if (H(x, x))
>>>>>>>>>>>>       HERE: goto HERE;
>>>>>>>>>>>>     return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>>> sometimes true, just it isn't an always true condition. You fail
>>>>>>>>>>> at elementary logic.
>>>>>>>>>>
>>>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>>>> another.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> P(P)
>>>>>>>>
>>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>>> deception.
>>>>>>>>
>>>>>>>
>>>>>>> Why not?
>>>>>>>
>>>>>> It is not an example of the simulation of the input to H(P,P) at all.
>>>>>>
>>>>>>
>>>>>
>>>>> Why is P not P?
>>>>>
>>>> It is not a direct rebuttal of my original claim.
>>> And what exactly was your original claim?
>>
>> H is always correct when it determines that an emulated input
>> specifies infinitely nested emulation whenever H matches the (a)(b)(c)
>> criteria to the behavior of this input.
>>
>> Obviously a rebuttal would be to find a case where H is incorrect
>> under these exact same conditions.
>>
>
> No, it doesn't, because what it shows is that a mythological machine was
> correct. The machine described is one that SIMULTANOUSLY does a complete
> and correct emulation of its input, while ALSO stopping in finite time
> to return the non-halting answer.

On 6/23/22 10:10 PM, olcott wrote:
> On 6/23/2022 8:59 PM, Richard Damon wrote:
>>
>> On 6/23/22 9:38 PM, olcott wrote:
>>> On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:
>>>> On Wednesday, June 22, 2022 at 10:13:27 PM UTC-7, olcott wrote:
>>>>> On 6/22/2022 10:41 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:55 PM, olcott wrote:
>>>>>>> On 6/22/2022 9:34 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 10:18 PM, olcott wrote:
>>>>>>>>> On 6/22/2022 8:45 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/22 9:41 PM, olcott wrote:
>>>>>>>>>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>>>>>>>>>> their specified context
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since you haven't actualy defined you context, and imply
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> it is the halting problem, where they can not be correct,
>>>>>>>>>>>>>>>> that is not possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First you agree that these words are 100% correct within the
>>>>>>>>>>>>>>> context of software engineering totally ignoring the context
>>>>>>>>>>>>>>> of the halting problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, if H actually is a program that does a COMPLETE and
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> x86 emulation of its input, then YES, as I have said many
>>>>>>>>>>>>>> time
>>>>>>>>>>>>>> before, this combination is non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fact that you need to keep going back to this, and
>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>> just be refusing to accept the conditions under which you
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> proved it just shows the problems with your thought process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that NOW H isn't the H we were just talking about, so
>>>>>>>>>>>>>> you are just proving that you are either lying or an idiot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember, the first analysis had the CONDITION on it that
>>>>>>>>>>>>>> H did
>>>>>>>>>>>>>> a COMPLETE and correct x86 emulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Once you remove that property form H, that conclusion no long
>>>>>>>>>>>>>> holds and you are shown to be a lying idiot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (b) is NOT a correct rule. Thos has been pointed out before,
>>>>>>>>>>>>>> and you have ignored it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That you don't understand what I mean does not mean that it is
>>>>>>>>>>>>> an incorrect rule.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is an example where P does have instruction that could
>>>>>>>>>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> static count = 0;
>>>>>>>>>>>>>     count++;
>>>>>>>>>>>>>     if count > 3)
>>>>>>>>>>>>>       return;
>>>>>>>>>>>>>     if (H(x, x))
>>>>>>>>>>>>>       HERE: goto HERE;
>>>>>>>>>>>>>     return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> FALLACY of proof by example. I never said that (b) isn't
>>>>>>>>>>>> sometimes true, just it isn't an always true condition. You
>>>>>>>>>>>> fail
>>>>>>>>>>>> at elementary logic.
>>>>>>>>>>>
>>>>>>>>>>> Try and find a valid counter-example. Every attempt at rebuttal
>>>>>>>>>>> that is not a valid counter-example is one form of deception or
>>>>>>>>>>> another.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> P(P)
>>>>>>>>>
>>>>>>>>> That is not any example of (b), thus another mere strawman
>>>>>>>>> deception.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why not?
>>>>>>>>
>>>>>>> It is not an example of the simulation of the input to H(P,P) at
>>>>>>> all.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Why is P not P?
>>>>>>
>>>>> It is not a direct rebuttal of my original claim.
>>>> And what exactly was your original claim?
>>>
>>> H is always correct when it determines that an emulated input
>>> specifies infinitely nested emulation whenever H matches the
>>> (a)(b)(c) criteria to the behavior of this input.
>>>
>>> Obviously a rebuttal would be to find a case where H is incorrect
>>> under these exact same conditions.
>>>
>>
>> No, it doesn't, because what it shows is that a mythological machine
>> was correct. The machine described is one that SIMULTANOUSLY does a
>> complete and correct emulation of its input, while ALSO stopping in
>> finite time to return the non-halting answer.
>
> Because of this reply after I have corrected you hundreds of times I
> have blocked you and all of your messages have been erased.
>
>

On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
> >> >> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
> >> >> > On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
> >> >> >> On 6/21/2022 9:52 PM, Richard Damon wrote:
> >> >> >>>
> >> >> >>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
> >> >> >>> was incorrect in its mapping, since the behavior of P(P) is the
> >> >> >>> DEFINITION of the behavior of H(P,P),
> >> >> >> Linz and others were aware that: 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.
> >> >> >> Linz and others made the false assumption that the actual behavior that
> >> >> >> is actually specified by the inputs to a simulating halt decider is not
> >> >> >> the same as the direct execution of these inputs. They were unaware of
> >> >> >> this because no one previously fully examined a simulating halt decider
> >> >> >> ever before.
> >> >> >>> especially if that is what P calls
> >> >> >>> and P is claimed to be built by the Linz template.
> >> >> >>>
> >> >> >>> So, either P isn't built right, or H isn't built fight, or H is wrong.
> >> >> >>
> >> >> > You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
> >> >> > reports it as non-halting. So it's reasonable to assume that H is correct.
> >> >> >
> >> >> > However, when run, P(P) halts. So what are we to conclude? That "the
> >> >> > actual behaviour that is actually specified by the inputs to a simulating
> >> >> > halt decider is not the same as the direct execution of these inputs"?
> >> >>
> >> >> That is an actual immutable verified fact.
> >> >>
> >> > That's your conclusion from your observations and reasoning. You've
> >> > dry-run P(P), and it doesn't halt. You've run H on P(P), and it
> >> > reports "non-halting". You've run P(P), and it halts. So one
> >> > explanation is the one you've given but, as I said, that explanation
> >> > has rather far-reaching consequences.
> >> There is only one explanation. What you call the "dry-run" is not that
> >> same as the P(P). We've known this since the "line 15 commented out"
> >> days. There are two computations -- one that is not stopped and one
> >> that is, the "dry-run" and the run, the "simulation of the input to
> >> H(P,P)" and P(P). All PO is doing is trying to find words that hide
> >> what's going on.
> >>
> > I'm a scientists, not a mathematician.
> > The example I always use is that you are doing an energy budget for tigers.
> > You work how much they use on running about, lactating, maintaining their
> > body temperature, and so on.
> >
> > Now let's say that you find that all results are within a few percentage points
> > of a similar budget done for lions. You'd instantly accept this data.
> >
> > Now let's say that the results are wildly different from a previous budget done
> > for lions. You wouldn't just accept that data. You'd check. You'd want to
> > understand the reasons tigers spend far less energy on movement than lions.
> >
> > Now let's say that the result show that tigers use more energy than they
> > take in food. Would you instantly conclude that the law of conservation of
> > energy must be incorrect?
> >
> > The third is what PO is doing.
> I have no idea what parts of this analogy map to the current situation.
> PO has no contradictory results about anything. There's no conflict
> with any established facts in anything he is doing.
>
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.

So something odd is going on there that needs an explanation.