#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)

--
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/21/22 10:38 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));
> }
>
> _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)
>

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

On 6/21/2022 9:52 PM, Richard Damon wrote:
> On 6/21/22 10:38 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));
>> }
>>
>> _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)
>>
>
> 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.

--
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/21/22 11:10 PM, olcott wrote:
> On 6/21/2022 9:52 PM, Richard Damon wrote:
>> On 6/21/22 10:38 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));
>>> }
>>>
>>> _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)
>>>
>>
>> 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.

"Inputs" don't have "behavior" except by what they represent.

>
> 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.
>
Nope, YOU are the one making the stupid assumption that you get to
change the meaning of the definitions.

All you are doing is CONFIRMING that it is impossible to build a decider
to do the job of a Halt decider, because YOU are claiming you can't even
ask it the question.

If your system can't prhase the question, it can't answer it, so that
shows that there exists a machine that it can't give the corret answer two.

You are reversing the direction of requirements.

H doesn't need to be able to answer for every machine that can be
represented to it, it need to define how to represent every machine that
can exist, and then answer correctly for it.

The domain for H is the representation of ALL possible machines x
representation of ALL possible inputs for that machine.

Yes, if CAN only answer for machines you can represent for it, but if
there is a machine you can't represent, that makes H FAIL, not give H a
"psss" for that input.

You claim that you can't represent that input just PROVES that you
counter is incorrect.

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

Peter Olcott wrote:
> [snip badly regurgitated boring bullshit]

People feel embarrassed for you, Peter, you know?

On the other hand, after all, you are a convicted liar, a blatant
idiot, a pathetic bigot and an ass, Peter, so we don't care that
much.

(stop absusing Usenet by multi-posting without followup, this is
rude)

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 would have far-reaching consequences. Before going there, maybe
think up some simpler, alternative explanations and eliminate them.

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 would have far-reaching consequences. Before going there, maybe
> think up some simpler, alternative explanations and eliminate them.

There are no alternatives to immutable verified facts. H(P,P) halts only
because H(P,P) correctly determines that its input never halts.

Technically competent software engineers would agree. On the basis of
the much more complete details that I provided in my original post.

When P(P) is called from main its behavior depends on the return value
of H. When H is called from main P(P) cannot possibly depend on the
return value of H because the correctly emulated input to H(P,P)
continues to remain stuck in infinite emulation until H aborts it.

--
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 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. In these circumstances, the sensible
scientist (or I suppose mathematician, though I'm a scientist and not a
mathematician) looks for alternative explanations which aren't quite as
consequential.
> > That would have far-reaching consequences. Before going there, maybe
> > think up some simpler, alternative explanations and eliminate them.
> There are no alternatives to immutable verified facts. H(P,P) halts only
> because H(P,P) correctly determines that its input never halts.
>
> Technically competent software engineers would agree. On the basis of
> the much more complete details that I provided in my original post.
>
> When P(P) is called from main its behavior depends on the return value
> of H. When H is called from main P(P) cannot possibly depend on the
> return value of H because the correctly emulated input to H(P,P)
> continues to remain stuck in infinite emulation until H aborts it.
>
That would be one consequence of going with your explanation. We'd have to
say the behaviour of P(P) differs depending on caller. As I said, try simpler,
less far-reaching explanations first.

On 6/22/2022 7:45 AM, Malcolm McLean wrote:
> 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. In these circumstances, the sensible
> scientist (or I suppose mathematician, though I'm a scientist and not a
> mathematician) looks for alternative explanations which aren't quite as
> consequential.

That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct

>>> That would have far-reaching consequences. Before going there, maybe
>>> think up some simpler, alternative explanations and eliminate them.
>> There are no alternatives to immutable verified facts. H(P,P) halts only
>> because H(P,P) correctly determines that its input never halts.
>>
>> Technically competent software engineers would agree. On the basis of
>> the much more complete details that I provided in my original post.
>>
>> When P(P) is called from main its behavior depends on the return value
>> of H. When H is called from main P(P) cannot possibly depend on the
>> return value of H because the correctly emulated input to H(P,P)
>> continues to remain stuck in infinite emulation until H aborts it.
>>
> That would be one consequence of going with your explanation. We'd have to
> say the behaviour of P(P) differs depending on caller. As I said, try simpler,
> less far-reaching explanations first.

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

H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).

--
Copyright 2022 Pete Olcott

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

On 6/22/2022 7:53 AM, olcott wrote:
> On 6/22/2022 7:45 AM, Malcolm McLean wrote:
>> 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. In these circumstances, the sensible
>> scientist (or I suppose mathematician, though I'm a scientist and not a
>> mathematician) looks for alternative explanations which aren't quite as
>> consequential.
>
> That is like looking for alternatives to 5 > 3
> 5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct
>
>>>> That would have far-reaching consequences. Before going there, maybe
>>>> think up some simpler, alternative explanations and eliminate them.
>>> There are no alternatives to immutable verified facts. H(P,P) halts only
>>> because H(P,P) correctly determines that its input never halts.
>>>
>>> Technically competent software engineers would agree. On the basis of
>>> the much more complete details that I provided in my original post.
>>>
>>> When P(P) is called from main its behavior depends on the return value
>>> of H. When H is called from main P(P) cannot possibly depend on the
>>> return value of H because the correctly emulated input to H(P,P)
>>> continues to remain stuck in infinite emulation until H aborts it.
>>>
>> That would be one consequence of going with your explanation. We'd
>> have to
>> say the behaviour of P(P) differs depending on caller. As I said, try
>> simpler,
>> less far-reaching explanations first.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
>  H(P,P)==0 is provably correct
> H1(P,P)==1 is provably correct.
> H1(P,P) reports on the behavior of P(P).
>

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. The actual behavior of the actual input to
H(P,P) is non halting thus rejecting its input is necessarily correct.

--
Copyright 2022 Pete Olcott

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

Malcolm McLean <malcolm.arthur.mclean@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.

--
Ben.

On 6/21/2022 8:38 PM, olcott wrote:

<SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>

Peter, you must first identify a competent Software Engineer to do said
verification. There are two problems: The first is that no competent SE
would verify your claims whether or not you shared your crap code with
them. You don't certify a black box from the outside because there are
too many simple errors that wont be caught.

The second is that you have nominated yourself as a competent SE. NOT!!!
You have tried this sham before; it didn't work then and it wont work
now. We are on to you. You told us some of the projects you worked on
and there is a choice of reactions: Assume you lied or assume you did
not and deliberately named projects all of whom were failures. Take your
pick. The truth is that you couldn't even stay employed on government
sponsored make work programs. You know the kind where a manager sends a
WBR* to the personnel office when thy need to increase spending.

Everyone in all the newsgroups you soil with these threads, who has
shown actual competence in SE, Computer Science, or Programming agrees
that you are an incompetent nut. You also showed us one of the worst
written and worst conceived patents we had ever see. If it wasn't for
your learning disabilities and inability to allocate time to useful
sub-projects, you might have done okay. But you have my sympathy; few
are able to overcome nature's limits.

So this thread, like so many others, is dead on arrival.

* Warm Body Requisition. Someone actual showed me such a form used on a
part of Apollo back in the early 1960s. So we see that if you were a
little older there would have been jobs for you but now days, the
requirements are simply too high.
--
Jeff Barnett

On 6/22/2022 10:50 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@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.
>

My words are perfectly clear and correct thus leaving the only possible
rebuttal of changing the words and forming a rebuttal on the basis of
these changed words.

straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

#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(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.

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.

--
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/22/2022 12:11 PM, Jeff Barnett wrote:
> On 6/21/2022 8:38 PM, olcott wrote:
>
> <SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
>
> Peter, you must first identify a competent Software Engineer to do said
> verification. There are two problems: The first is that no competent SE
> would verify your claims whether or not you shared your crap code with
> them. You don't certify a black box from the outside because there are
> too many simple errors that wont be caught.
>

My words are perfectly clear and correct thus leaving the only possible
rebuttal of changing the words and forming a rebuttal on the basis of
these changed words.

straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

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

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.

Sufficiently competent software engineers will agree that if you cannot
verify that the above reasoning is valid forms sufficient proof that you
are not a sufficiently competent software engineer as defined below:

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 second is that you have nominated yourself as a competent SE. NOT!!!

Clueless wonders always use ad hominem personal attacks as their basis
of rebuttal because that is all that they have.

--
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 Tue, 21 Jun 2022 21:38:56 -0500
olcott <NoOne@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

On 6/22/2022 2:31 PM, Mr Flibble wrote:
> On Tue, 21 Jun 2022 21:38:56 -0500
> olcott <NoOne@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.

--
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/22/2022 2:31 PM, Mr Flibble wrote:
> On Tue, 21 Jun 2022 21:38:56 -0500
> olcott <NoOne@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.

The proof of your technical incompetence that others can see is that you
only stater dogmatically that I am wrong without pointing out any actual
mistakes.

The proof of the technical incompetence of Richard and Ben is that they
intentionally paraphrase what I said incorrect so that they can use the
strawman deception to form a rebuttal on the basis of this intentionally
incorrect paraphrase.

straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

The proof of the technical incompetence of most everyone else is that
they simply provide ad hominem insults as the entire basis of their fake
"rebuttal". That zero rebuttals with any plausible basis have been
presented for many weeks is very encouraging.

--
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 Wed, 22 Jun 2022 15:47:58 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> > On Tue, 21 Jun 2022 21:38:56 -0500
> > olcott <NoOne@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.
>
> The proof of your technical incompetence that others can see is that
> you only stater dogmatically that I am wrong without pointing out any
> actual mistakes.
>
> The proof of the technical incompetence of Richard and Ben is that
> they intentionally paraphrase what I said incorrect so that they can
> use the strawman deception to form a rebuttal on the basis of this
> intentionally incorrect paraphrase.
>
> straw man
> An intentionally misrepresented proposition that is set up because it
> is easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> The proof of the technical incompetence of most everyone else is that
> they simply provide ad hominem insults as the entire basis of their
> fake "rebuttal". That zero rebuttals with any plausible basis have
> been presented for many weeks is very encouraging.

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)

On Wed, 22 Jun 2022 15:27:01 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> > On Tue, 21 Jun 2022 21:38:56 -0500
> > olcott <NoOne@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: the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in finite
time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.

/Flibble

On 6/22/2022 4:20 PM, Mr Flibble wrote:
> On Wed, 22 Jun 2022 15:27:01 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>> olcott <NoOne@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.

On Wed, 22 Jun 2022 16:41:43 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> > On Wed, 22 Jun 2022 15:27:01 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>> olcott <NoOne@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.
>
> Otherwise you are incompetent.
>
> > the recursion simply isn't there for a "valid" halt
> > decider, that being a halt decider that can return an answer in
> > finite time to ALL invokers: H needs to return an answer to Px to be
> > considered a valid halt decider.
> >
> > /Flibble

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.

On 6/22/2022 4:49 PM, Mr Flibble wrote:
> On Wed, 22 Jun 2022 16:41:43 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>> olcott <NoOne@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.
>>
>> Otherwise you are incompetent.
>>
>>> the recursion simply isn't there for a "valid" halt
>>> decider, that being a halt decider that can return an answer in
>>> finite time to ALL invokers: H needs to return an answer to Px to be
>>> considered a valid halt decider.
>>>
>>> /Flibble
>
> Why did you ignore the second part? Again:
>
> The problem is that you cannot recognize the fact that the infinite
> recursion only manifests as part of your invalid simulation-based

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:
>>
>> <SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
>>
>> Peter, you must first identify a competent Software Engineer to do
>> said verification. There are two problems: The first is that no
>> competent SE would verify your claims whether or not you shared your
>> crap code with them. You don't certify a black box from the outside
>> because there are too many simple errors that wont be caught.

> My words are perfectly clear and correct thus leaving the only possible
> rebuttal of changing the words and forming a rebuttal on the basis of
> these changed words.
Your words are not clear even to you. Are you really that stupid? Your
not a Software Engineer, Computer Scientist, or a Programmer of even
modest skills. Sorry. Your accomplishments here on USENET or on the job
are of so trite a nature that no one of any accomplishments in these
areas can allow you pollute newsgroup after newsgroup with the same
repetitive dribble. I think you have invented the "E" version of the
good old "cluster fuck". (That's one innovation you can put on your resume.)

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

And that's the point. You are neither a competent Software Engineer nor
one who can judge competence. Remember all those employers who told you
the same thing.

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

> Sufficiently competent software engineers will agree that if you cannot
> verify that the above reasoning is valid forms sufficient proof that you
> are not a sufficiently competent software engineer as defined below:

Ass backwards as usual.

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

That's really a shame for you since you have little knowledge or
competence in anything above. Strangely you need knowledge of the
halting problem to judge whether you have a legit counter example. So as
to what you "need knowledge of", you are once again ass backward.

>> The second is that you have nominated yourself as a competent SE. NOT!!!
>
> Clueless wonders always use ad hominem personal attacks as their basis
> of rebuttal because that is all that they have.

Mine isn't an ad hominem attack: It is based not only on my perception
of your nonsense but 100's of others pointing out glaring repetitive
errors. You on the other hand repeated nonsense, most of it off topic,
and then claim that someone else's competence is lacking.

Let's close by paraphrasing Schopenhauer to describe you Peter:

"Ignorance induces errors no one else could duplicate;
Ignorance + stupidity and ambition induce errors no one could foresee."
--
Jeff Barnett

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.