On 6/22/22 9:03 PM, olcott wrote:
> On 6/22/2022 7:56 PM, Richard Damon wrote:
>> On 6/22/22 8:30 PM, olcott wrote:
>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> You have this wrong.
>>>>>>
>>>>>> A decider must compute the mapping that represents the FUNCTION it
>>>>>> is deciding, there is actually nothing about "behavior" in the
>>>>>> definition.
>>>>>>
>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>
>>>>> If you construe this as the actual behavior that the actual input
>>>>> specifies then this is correct otherwise this is incorrect.
>>>>
>>>> If it isn't the acutual behavior, then it just isn't a Halt Decider,
>>>> but maybe your POOP decider.
>>>>
>>> The behavior of P(P) is provably not the actual behavior of the
>>> actual input to H(P,P). That you are insufficiently technically
>>> competent to verify this is far less than no rebuttal at all.
>>>
>>
>> THen prove it.
>
> I have proved it dozens of times and every fake "rebuttal" simply
> ignores the proof.
>
>

On 6/22/2022 8:05 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>> On 6/22/22 8:37 PM, olcott wrote:
>>
>>>> First you agree that my words are perfectly correct within their
>>>> specified context
>>>
>>> Since you haven't actualy defined you context, and imply that it is the
>>> halting problem, where they can not be correct, that is not possible.
>>>>
>> First you agree that these words are 100% correct within the context of
>> software engineering totally ignoring the context of the halting problem.
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> void P(ptr x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> _P()
>> [000010d2](01) 55 push ebp
>> [000010d3](02) 8bec mov ebp,esp
>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>> [000010d8](01) 50 push eax
>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>> [000010dc](01) 51 push ecx
>> [000010dd](05) e820feffff call 00000f02
>> [000010e2](03) 83c408 add esp,+08
>> [000010e5](02) 85c0 test eax,eax
>> [000010e7](02) 7402 jz 000010eb
>> [000010e9](02) ebfe jmp 000010e9
>> [000010eb](01) 5d pop ebp
>> [000010ec](01) c3 ret
>> Size in bytes:(0027) [000010ec]
>>
>> Every sufficiently competent software engineer can easily verify that
>> the complete and correct x86 emulation of the input to H(P,P) by H would
>> never reach the "ret" instruction of P because both H and P would remain
>> stuck in infinitely recursive emulation.
>>
>> 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.
>
> FALSE. P contains this code:
>
> 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
>
> which CAN and DOES prevent infinite simulation in the CORRECT simulation of the input to H(P,P), or more accurately Ha(Pa,Pa)
>
>> (c) H aborts its emulation of P before its call to H is invoked.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer

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

You simply use the strawman deception to dodge this claim.

--
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, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
> On 6/22/2022 8:02 PM, Dennis Bush wrote:
> > On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
> >> On 6/22/2022 5:48 PM, Dennis Bush wrote:
> >>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
> >>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
> >>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
> >>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> #include <stdint.h>
> >>>>>>>>>> #define u32 uint32_t
> >>>>>>>>>>
> >>>>>>>>>> #include <stdint.h>
> >>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>
> >>>>>>>>>> void P(ptr x)
> >>>>>>>>>> {
> >>>>>>>>>> if (H(x, x))
> >>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> _P()
> >>>>>>>>>> [000010d2](01) 55 push ebp
> >>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>> [000010d8](01) 50 push eax
> >>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>> [000010dc](01) 51 push ecx
> >>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>>>>>> [000010eb](01) 5d pop ebp
> >>>>>>>>>> [000010ec](01) c3 ret
> >>>>>>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>>>>>
> >>>>>>>>>> Every sufficiently competent software engineer can easily verify
> >>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
> >>>>>>>>>> by H would never reach the "ret" instruction of P because both H
> >>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
> >>>>>>>>>>
> >>>>>>>>>> If H does correctly determine that this is the case in a finite
> >>>>>>>>>> number of steps then H could reject its input on this basis. Here
> >>>>>>>>>> are the details of exactly how H does this in a finite number of
> >>>>>>>>>> steps.
> >>>>>>>>>>
> >>>>>>>>>> typedef struct Decoded
> >>>>>>>>>> {
> >>>>>>>>>> u32 Address;
> >>>>>>>>>> u32 ESP; // Current value of ESP
> >>>>>>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>>>>>> u32 NumBytes;
> >>>>>>>>>> u32 Simplified_Opcode;
> >>>>>>>>>> u32 Decode_Target;
> >>>>>>>>>> } Decoded_Line_Of_Code;
> >>>>>>>>>>
> >>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>> address address data code language
> >>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> >>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
> >>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
> >>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
> >>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
> >>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>
> >>>>>>>>>> // actual fully operational code in the x86utm operating system
> >>>>>>>>>> u32 H(u32 P, u32 I)
> >>>>>>>>>> {
> >>>>>>>>>> HERE:
> >>>>>>>>>> u32 End_Of_Code;
> >>>>>>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>>>>>> u32 code_end = get_code_end(P);
> >>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> >>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>>>>>> Registers* master_state = (Registers*)
> >>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>> Registers* slave_state = (Registers*)
> >>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
> >>>>>>>>>> u32 execution_trace =
> >>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>>>>>> * 1000);
> >>>>>>>>>>
> >>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>>>>>> __asm mov eax, END_OF_CODE
> >>>>>>>>>> __asm mov End_Of_Code, eax
> >>>>>>>>>>
> >>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
> >>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> >>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
> >>>>>>>>>> execution_trace);
> >>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
> >>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>> END_OF_CODE:
> >>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>> examine its stored execution_trace of P and determine:
> >>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
> >>>>>>>>>> infinitely recursive emulation.
> >>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Technically competent software engineers may not know this computer
> >>>>>>>>>> science:
> >>>>>>>>>>
> >>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>
> >>>>>>>>>> computation that halts … the Turing machine will halt whenever it
> >>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>
> >>>>>>>>>> The "ret" instruction of P is its final state.
> >>>>>>>>>>
> >>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> >>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> void Px(u32 x)
> >>>>>>>>> {
> >>>>>>>>> H(x, x);
> >>>>>>>>> return;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> int main()
> >>>>>>>>> {
> >>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>>>>>> Input_Halts = 0
> >>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>
> >>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
> >>>>>>>>> QED.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> You and Richard are insufficiently technically competent at software
> >>>>>>>> engineering not meeting these specs:
> >>>>>>>>
> >>>>>>>> A software engineer must be an expert in: the C programming language,
> >>>>>>>> the x86 programming language, exactly how C translates into x86 and
> >>>>>>>> the ability to recognize infinite recursion at the x86 assembly
> >>>>>>>> language level. No knowledge of the halting problem is required.
> >>>>>>>
> >>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
> >>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
> >>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
> >>>>>>> the problem is that you cannot recognize the fact that the infinite
> >>>>>>> recursion only manifests as part of your invalid simulation-based
> >>>>>>> omnishambles:
> >>>>>> If you are competent then you already know this is true and lie about it:
> >>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>> would never reach the "ret" instruction of P because both H and P would
> >>>>>> remain stuck in infinitely recursive emulation.
> >>>>>
> >>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
> >>>>>
> >>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
> >>>>
> >>>> Every sufficiently competent software engineer can easily verify that
> >>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>> would never reach the "ret" instruction of Px because both H and Px
> >>>> would remain stuck in infinitely recursive emulation.
> >>>
> >>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
> >> Your entire basis and all of assumptions was incorrect so when I
> >> provided an infallible one to that cannot possibly be correctly refuted
> >> you simply dodged it. That is a smart move for a dishonest person that
> >> is only interested in rebuttal.
> >>
> >> I dare you to go back to the prior post and find any error in my
> >> airtight correct reasoning. Another dodge will be construed as a tacit
> >> admission of defeat.
> >
> > As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
> I never claimed that H(P,P) performs a complete and correct emulation of
> its input so your rebuttal is the strawman deception.
>
> I claimed that H(P,P) correctly predicts that its complete and correct
> x86 emulation of its input would never reach the "ret" instruction of P.

On 6/22/2022 8:14 PM, Richard Damon wrote:
> On 6/22/22 8:55 PM, olcott wrote:
>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>> On 6/22/22 8:37 PM, olcott wrote:
>>
>>>> First you agree that my words are perfectly correct within their
>>>> specified context
>>>
>>> Since you haven't actualy defined you context, and imply that it is
>>> the halting problem, where they can not be correct, that is not
>>> possible.
>>>>
>> First you agree that these words are 100% correct within the context
>> of software engineering totally ignoring the context of the halting
>> problem.
>>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> void P(ptr x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>> _P()
>> [000010d2](01)  55              push ebp
>> [000010d3](02)  8bec            mov ebp,esp
>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>> [000010d8](01)  50              push eax
>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>> [000010dc](01)  51              push ecx
>> [000010dd](05)  e820feffff      call 00000f02
>> [000010e2](03)  83c408          add esp,+08
>> [000010e5](02)  85c0            test eax,eax
>> [000010e7](02)  7402            jz 000010eb
>> [000010e9](02)  ebfe            jmp 000010e9
>> [000010eb](01)  5d              pop ebp
>> [000010ec](01)  c3              ret
>> Size in bytes:(0027) [000010ec]
>>
>> Every sufficiently competent software engineer can easily verify that
>> the complete and correct x86 emulation of the input to H(P,P) by H
>> would never reach the "ret" instruction of P because both H and P
>> would remain stuck in infinitely recursive emulation.
>>
>
> So, if H actually is a program that does a COMPLETE and correct x86
> emulation of its input, then YES, as I have said many time before, this
> combination is non-halting.
>
> The fact that you need to keep going back to this, and seem to just be
> refusing to accept the conditions under which you have proved it just
> shows the problems with your thought process.
>
>> If H does correctly determine that this is the case in a finite number
>> of steps then H could reject its input on this basis. Here are the
>> details of exactly how H does this in a finite number of steps.
>
> Except that NOW H isn't the H we were just talking about, so you are
> just proving that you are either lying or an idiot.
>
> Remember, the first analysis had the CONDITION on it that H did a
> COMPLETE and correct x86 emulation.
>
> Once you remove that property form H, that conclusion no long holds and
> you are shown to be a lying idiot.
>
>>
>> typedef struct Decoded
>> {
>>    u32 Address;
>>    u32 ESP;          // Current value of ESP
>>    u32 TOS;          // Current value of Top of Stack
>>    u32 NumBytes;
>>    u32 Simplified_Opcode;
>>    u32 Decode_Target;
>> } Decoded_Line_Of_Code;
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [000010d2][00211e8a][00211e8e] 55         push ebp
>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>> Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> // actual fully operational code in the x86utm operating system
>> u32 H(u32 P, u32 I)
>> {
>> HERE:
>>    u32 End_Of_Code;
>>    u32 Address_of_H;              // 2022-06-17
>>    u32 code_end                  = get_code_end(P);
>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>> Allocate(sizeof(Decoded_Line_Of_Code));
>>    Registers*  master_state      = (Registers*)
>> Allocate(sizeof(Registers));
>>    Registers*  slave_state       = (Registers*)
>> Allocate(sizeof(Registers));
>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
>> 1000);
>>
>>    __asm lea eax, HERE             // 2022-06-18
>>    __asm sub eax, 6                // 2022-06-18
>>    __asm mov Address_of_H, eax     // 2022-06-18
>>    __asm mov eax, END_OF_CODE
>>    __asm mov End_Of_Code, eax
>>
>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>> execution_trace);
>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>> &master_state,
>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>        goto END_OF_CODE;
>>    return 0;  // Does not halt
>> END_OF_CODE:
>>    return 1; // Input has normally terminated
>> }
>>
>> H knows its own machine address and on this basis it can easily
>> examine its stored execution_trace of P and determine:
>> (a) P is calling H with the same arguments that H was called with.
>> (b) No instructions in P could possibly escape this otherwise
>> infinitely recursive emulation.
>> (c) H aborts its emulation of P before its call to H is invoked.
>>
>>
>
> (b) is NOT a correct rule. Thos has been pointed out before, and you
> have ignored it.
>
That you don't understand what I mean does not mean that it is an
incorrect rule.

Here is an example where P does have instruction that could possibly
escape this otherwise infinitely recursive emulation:

void P(ptr x)
{ static count = 0;
count++;
if count > 3)
return;
if (H(x, x))
HERE: goto HERE;
return;
}

--
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/22 9:20 PM, olcott wrote:
> On 6/22/2022 8:05 PM, Dennis Bush wrote:
>> On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>
>>>>> First you agree that my words are perfectly correct within their
>>>>> specified context
>>>>
>>>> Since you haven't actualy defined you context, and imply that it is the
>>>> halting problem, where they can not be correct, that is not possible.
>>>>>
>>> First you agree that these words are 100% correct within the context of
>>> software engineering totally ignoring the context of the halting
>>> problem.
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [000010d2](01) 55 push ebp
>>> [000010d3](02) 8bec mov ebp,esp
>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>> [000010d8](01) 50 push eax
>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>> [000010dc](01) 51 push ecx
>>> [000010dd](05) e820feffff call 00000f02
>>> [000010e2](03) 83c408 add esp,+08
>>> [000010e5](02) 85c0 test eax,eax
>>> [000010e7](02) 7402 jz 000010eb
>>> [000010e9](02) ebfe jmp 000010e9
>>> [000010eb](01) 5d pop ebp
>>> [000010ec](01) c3 ret
>>> Size in bytes:(0027) [000010ec]
>>>
>>> Every sufficiently competent software engineer can easily verify that
>>> the complete and correct x86 emulation of the input to H(P,P) by H would
>>> never reach the "ret" instruction of P because both H and P would remain
>>> stuck in infinitely recursive emulation.
>>>
>>> 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.
>>
>> FALSE.  P contains this code:
>>
>> 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
>>
>> which CAN and DOES prevent infinite simulation in the CORRECT
>> simulation of the input to H(P,P), or more accurately Ha(Pa,Pa)
>>
>>> (c) H aborts its emulation of P before its call to H is invoked.
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>
>
> I claim that H(P,P) correctly predicts that its complete and correct x86
> emulation of its input would never reach the "ret" instruction of P.
>
> You simply use the strawman deception to dodge this claim.
>

Except that when you give that input to a definitionally complete and
correct emulator, you get P(P) and that it halts.

That is what happens when actually do what you claim, and not try
replacing H with something that isn't actually H.

That is where you logic breaks, H doesn't see an actual H in the input,
but uses is MISCONCEPTION of H.

On 6/22/2022 8:19 PM, Richard Damon wrote:
> On 6/22/22 9:03 PM, olcott wrote:
>> On 6/22/2022 7:56 PM, Richard Damon wrote:
>>> On 6/22/22 8:30 PM, olcott wrote:
>>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> You have this wrong.
>>>>>>>
>>>>>>> A decider must compute the mapping that represents the FUNCTION
>>>>>>> it is deciding, there is actually nothing about "behavior" in the
>>>>>>> definition.
>>>>>>>
>>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>>
>>>>>> If you construe this as the actual behavior that the actual input
>>>>>> specifies then this is correct otherwise this is incorrect.
>>>>>
>>>>> If it isn't the acutual behavior, then it just isn't a Halt
>>>>> Decider, but maybe your POOP decider.
>>>>>
>>>> The behavior of P(P) is provably not the actual behavior of the
>>>> actual input to H(P,P). That you are insufficiently technically
>>>> competent to verify this is far less than no rebuttal at all.
>>>>
>>>
>>> THen prove it.
>>
>> I have proved it dozens of times and every fake "rebuttal" simply
>> ignores the proof.
>>
>>
>
> Nope, you have claimed it, and given rhetorical arguments.

On 6/22/22 9:29 PM, olcott wrote:
> On 6/22/2022 8:14 PM, Richard Damon wrote:
>> On 6/22/22 8:55 PM, olcott wrote:
>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>
>>>>> First you agree that my words are perfectly correct within their
>>>>> specified context
>>>>
>>>> Since you haven't actualy defined you context, and imply that it is
>>>> the halting problem, where they can not be correct, that is not
>>>> possible.
>>>>>
>>> First you agree that these words are 100% correct within the context
>>> of software engineering totally ignoring the context of the halting
>>> problem.
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [000010d2](01)  55              push ebp
>>> [000010d3](02)  8bec            mov ebp,esp
>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>> [000010d8](01)  50              push eax
>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>> [000010dc](01)  51              push ecx
>>> [000010dd](05)  e820feffff      call 00000f02
>>> [000010e2](03)  83c408          add esp,+08
>>> [000010e5](02)  85c0            test eax,eax
>>> [000010e7](02)  7402            jz 000010eb
>>> [000010e9](02)  ebfe            jmp 000010e9
>>> [000010eb](01)  5d              pop ebp
>>> [000010ec](01)  c3              ret
>>> Size in bytes:(0027) [000010ec]
>>>
>>> Every sufficiently competent software engineer can easily verify that
>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>> would never reach the "ret" instruction of P because both H and P
>>> would remain stuck in infinitely recursive emulation.
>>>
>>
>> So, if H actually is a program that does a COMPLETE and correct x86
>> emulation of its input, then YES, as I have said many time before,
>> this combination is non-halting.
>>
>> The fact that you need to keep going back to this, and seem to just be
>> refusing to accept the conditions under which you have proved it just
>> shows the problems with your thought process.
>>
>>> If H does correctly determine that this is the case in a finite
>>> number of steps then H could reject its input on this basis. Here are
>>> the details of exactly how H does this in a finite number of steps.
>>
>> Except that NOW H isn't the H we were just talking about, so you are
>> just proving that you are either lying or an idiot.
>>
>> Remember, the first analysis had the CONDITION on it that H did a
>> COMPLETE and correct x86 emulation.
>>
>> Once you remove that property form H, that conclusion no long holds
>> and you are shown to be a lying idiot.
>>
>>>
>>> typedef struct Decoded
>>> {
>>>    u32 Address;
>>>    u32 ESP;          // Current value of ESP
>>>    u32 TOS;          // Current value of Top of Stack
>>>    u32 NumBytes;
>>>    u32 Simplified_Opcode;
>>>    u32 Decode_Target;
>>> } Decoded_Line_Of_Code;
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> // actual fully operational code in the x86utm operating system
>>> u32 H(u32 P, u32 I)
>>> {
>>> HERE:
>>>    u32 End_Of_Code;
>>>    u32 Address_of_H;              // 2022-06-17
>>>    u32 code_end                  = get_code_end(P);
>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>    Registers*  master_state      = (Registers*)
>>> Allocate(sizeof(Registers));
>>>    Registers*  slave_state       = (Registers*)
>>> Allocate(sizeof(Registers));
>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>> * 1000);
>>>
>>>    __asm lea eax, HERE             // 2022-06-18
>>>    __asm sub eax, 6                // 2022-06-18
>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>    __asm mov eax, END_OF_CODE
>>>    __asm mov End_Of_Code, eax
>>>
>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>> execution_trace);
>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>> &master_state,
>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>        goto END_OF_CODE;
>>>    return 0;  // Does not halt
>>> END_OF_CODE:
>>>    return 1; // Input has normally terminated
>>> }
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P and determine:
>>> (a) P is calling H with the same arguments that H was called with.
>>> (b) No instructions in P could possibly escape this otherwise
>>> infinitely recursive emulation.
>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>
>>>
>>
>> (b) is NOT a correct rule. Thos has been pointed out before, and you
>> have ignored it.
>>
> That you don't understand what I mean does not mean that it is an
> incorrect rule.
>
> Here is an example where P does have instruction that could possibly
> escape this otherwise infinitely recursive emulation:
>
>
> void P(ptr x)
> {
> static count = 0;
>   count++;
>   if count > 3)
>     return;
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>

FALLACY of proof by example. I never said that (b) isn't sometimes true,
just it isn't an always true condition. You fail at elementary logic.

The fundamental problem is you don't understand what is 'P' to
computation theory, it isn't just the 'C Function' but includes
EVERYTHING that P calls, and thus includes H.

Thus, the conditional in H that decides to abort its further emulation
is PART of the program P, and thus the 'No Conditional' condition isn't
satisfied.

You just seem to be too ignorant of the basic to be able to reason.

On 6/22/2022 8:21 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>
>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>
>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>
>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>>>> steps.
>>>>>>>>>>>>
>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>> {
>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>
>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>> address address data code language
>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>
>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>> {
>>>>>>>>>>>> HERE:
>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>
>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>
>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>>>> science:
>>>>>>>>>>>>
>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>
>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>> H(x, x);
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>
>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>>>>>>>>> QED.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>
>>>>>>>>>> A software engineer must be an expert in: the C programming language,
>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>
>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>> omnishambles:
>>>>>>>> If you are competent then you already know this is true and lie about it:
>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>> would never reach the "ret" instruction of P because both H and P would
>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>
>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>>>
>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>
>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>
>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>>>> Your entire basis and all of assumptions was incorrect so when I
>>>> provided an infallible one to that cannot possibly be correctly refuted
>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>> is only interested in rebuttal.
>>>>
>>>> I dare you to go back to the prior post and find any error in my
>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>> admission of defeat.
>>>
>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
>> I never claimed that H(P,P) performs a complete and correct emulation of
>> its input so your rebuttal is the strawman deception.
>>
>> I claimed that H(P,P) correctly predicts that its complete and correct
>> x86 emulation of its input would never reach the "ret" instruction of P.
>
> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.

On 6/22/2022 8:36 PM, Richard Damon wrote:
> On 6/22/22 9:29 PM, olcott wrote:
>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>> On 6/22/22 8:55 PM, olcott wrote:
>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>
>>>>>> First you agree that my words are perfectly correct within their
>>>>>> specified context
>>>>>
>>>>> Since you haven't actualy defined you context, and imply that it is
>>>>> the halting problem, where they can not be correct, that is not
>>>>> possible.
>>>>>>
>>>> First you agree that these words are 100% correct within the context
>>>> of software engineering totally ignoring the context of the halting
>>>> problem.
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> _P()
>>>> [000010d2](01)  55              push ebp
>>>> [000010d3](02)  8bec            mov ebp,esp
>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>> [000010d8](01)  50              push eax
>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>> [000010dc](01)  51              push ecx
>>>> [000010dd](05)  e820feffff      call 00000f02
>>>> [000010e2](03)  83c408          add esp,+08
>>>> [000010e5](02)  85c0            test eax,eax
>>>> [000010e7](02)  7402            jz 000010eb
>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>> [000010eb](01)  5d              pop ebp
>>>> [000010ec](01)  c3              ret
>>>> Size in bytes:(0027) [000010ec]
>>>>
>>>> Every sufficiently competent software engineer can easily verify
>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>> by H would never reach the "ret" instruction of P because both H and
>>>> P would remain stuck in infinitely recursive emulation.
>>>>
>>>
>>> So, if H actually is a program that does a COMPLETE and correct x86
>>> emulation of its input, then YES, as I have said many time before,
>>> this combination is non-halting.
>>>
>>> The fact that you need to keep going back to this, and seem to just
>>> be refusing to accept the conditions under which you have proved it
>>> just shows the problems with your thought process.
>>>
>>>> If H does correctly determine that this is the case in a finite
>>>> number of steps then H could reject its input on this basis. Here
>>>> are the details of exactly how H does this in a finite number of steps.
>>>
>>> Except that NOW H isn't the H we were just talking about, so you are
>>> just proving that you are either lying or an idiot.
>>>
>>> Remember, the first analysis had the CONDITION on it that H did a
>>> COMPLETE and correct x86 emulation.
>>>
>>> Once you remove that property form H, that conclusion no long holds
>>> and you are shown to be a lying idiot.
>>>
>>>>
>>>> typedef struct Decoded
>>>> {
>>>>    u32 Address;
>>>>    u32 ESP;          // Current value of ESP
>>>>    u32 TOS;          // Current value of Top of Stack
>>>>    u32 NumBytes;
>>>>    u32 Simplified_Opcode;
>>>>    u32 Decode_Target;
>>>> } Decoded_Line_Of_Code;
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> // actual fully operational code in the x86utm operating system
>>>> u32 H(u32 P, u32 I)
>>>> {
>>>> HERE:
>>>>    u32 End_Of_Code;
>>>>    u32 Address_of_H;              // 2022-06-17
>>>>    u32 code_end                  = get_code_end(P);
>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>    Registers*  master_state      = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>    Registers*  slave_state       = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>    u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>> * 1000);
>>>>
>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>    __asm sub eax, 6                // 2022-06-18
>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>    __asm mov eax, END_OF_CODE
>>>>    __asm mov End_Of_Code, eax
>>>>
>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>> execution_trace);
>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>> &master_state,
>>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>>        goto END_OF_CODE;
>>>>    return 0;  // Does not halt
>>>> END_OF_CODE:
>>>>    return 1; // Input has normally terminated
>>>> }
>>>>
>>>> H knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of P and determine:
>>>> (a) P is calling H with the same arguments that H was called with.
>>>> (b) No instructions in P could possibly escape this otherwise
>>>> infinitely recursive emulation.
>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>
>>>>
>>>
>>> (b) is NOT a correct rule. Thos has been pointed out before, and you
>>> have ignored it.
>>>
>> That you don't understand what I mean does not mean that it is an
>> incorrect rule.
>>
>> Here is an example where P does have instruction that could possibly
>> escape this otherwise infinitely recursive emulation:
>>
>>
>> void P(ptr x)
>> {
>> static count = 0;
>>    count++;
>>    if count > 3)
>>      return;
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>
> FALLACY of proof by example. I never said that (b) isn't sometimes true,
> just it isn't an always true condition. You fail at elementary logic.

Try and find a valid counter-example. Every attempt at rebuttal that is
not a valid counter-example is one form of deception or another.

--
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, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
> On 6/22/2022 8:21 PM, Dennis Bush wrote:
> > On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
> >> On 6/22/2022 8:02 PM, Dennis Bush wrote:
> >>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
> >>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
> >>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
> >>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
> >>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>> #define u32 uint32_t
> >>>>>>>>>>>>
> >>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>
> >>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> _P()
> >>>>>>>>>>>> [000010d2](01) 55 push ebp
> >>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>> [000010d8](01) 50 push eax
> >>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>> [000010dc](01) 51 push ecx
> >>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>>>>>>>> [000010eb](01) 5d pop ebp
> >>>>>>>>>>>> [000010ec](01) c3 ret
> >>>>>>>>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>>>>>>>
> >>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
> >>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
> >>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
> >>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If H does correctly determine that this is the case in a finite
> >>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
> >>>>>>>>>>>> are the details of exactly how H does this in a finite number of
> >>>>>>>>>>>> steps.
> >>>>>>>>>>>>
> >>>>>>>>>>>> typedef struct Decoded
> >>>>>>>>>>>> {
> >>>>>>>>>>>> u32 Address;
> >>>>>>>>>>>> u32 ESP; // Current value of ESP
> >>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>>>>>>>> u32 NumBytes;
> >>>>>>>>>>>> u32 Simplified_Opcode;
> >>>>>>>>>>>> u32 Decode_Target;
> >>>>>>>>>>>> } Decoded_Line_Of_Code;
> >>>>>>>>>>>>
> >>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>> address address data code language
> >>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> >>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
> >>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
> >>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
> >>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
> >>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>
> >>>>>>>>>>>> // actual fully operational code in the x86utm operating system
> >>>>>>>>>>>> u32 H(u32 P, u32 I)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> HERE:
> >>>>>>>>>>>> u32 End_Of_Code;
> >>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>>>>>>>> u32 code_end = get_code_end(P);
> >>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> >>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>>>>>>>> Registers* master_state = (Registers*)
> >>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>> Registers* slave_state = (Registers*)
> >>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
> >>>>>>>>>>>> u32 execution_trace =
> >>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>>>>>>>> * 1000);
> >>>>>>>>>>>>
> >>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>>>>>>>> __asm mov eax, END_OF_CODE
> >>>>>>>>>>>> __asm mov End_Of_Code, eax
> >>>>>>>>>>>>
> >>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
> >>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> >>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
> >>>>>>>>>>>> execution_trace);
> >>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
> >>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>> examine its stored execution_trace of P and determine:
> >>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
> >>>>>>>>>>>> infinitely recursive emulation.
> >>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Technically competent software engineers may not know this computer
> >>>>>>>>>>>> science:
> >>>>>>>>>>>>
> >>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>
> >>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
> >>>>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>>>
> >>>>>>>>>>>> The "ret" instruction of P is its final state.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> >>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>> {
> >>>>>>>>>>> H(x, x);
> >>>>>>>>>>> return;
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> int main()
> >>>>>>>>>>> {
> >>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>>>>>>>> Input_Halts = 0
> >>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>
> >>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
> >>>>>>>>>>> QED.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> You and Richard are insufficiently technically competent at software
> >>>>>>>>>> engineering not meeting these specs:
> >>>>>>>>>>
> >>>>>>>>>> A software engineer must be an expert in: the C programming language,
> >>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
> >>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
> >>>>>>>>>> language level. No knowledge of the halting problem is required.
> >>>>>>>>>
> >>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
> >>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
> >>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
> >>>>>>>>> the problem is that you cannot recognize the fact that the infinite
> >>>>>>>>> recursion only manifests as part of your invalid simulation-based
> >>>>>>>>> omnishambles:
> >>>>>>>> If you are competent then you already know this is true and lie about it:
> >>>>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>>>> would never reach the "ret" instruction of P because both H and P would
> >>>>>>>> remain stuck in infinitely recursive emulation.
> >>>>>>>
> >>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
> >>>>>>>
> >>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
> >>>>>>
> >>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>> would never reach the "ret" instruction of Px because both H and Px
> >>>>>> would remain stuck in infinitely recursive emulation.
> >>>>>
> >>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
> >>>> Your entire basis and all of assumptions was incorrect so when I
> >>>> provided an infallible one to that cannot possibly be correctly refuted
> >>>> you simply dodged it. That is a smart move for a dishonest person that
> >>>> is only interested in rebuttal.
> >>>>
> >>>> I dare you to go back to the prior post and find any error in my
> >>>> airtight correct reasoning. Another dodge will be construed as a tacit
> >>>> admission of defeat.
> >>>
> >>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
> >> I never claimed that H(P,P) performs a complete and correct emulation of
> >> its input so your rebuttal is the strawman deception.
> >>
> >> I claimed that H(P,P) correctly predicts that its complete and correct
> >> x86 emulation of its input would never reach the "ret" instruction of P.
> >
> > But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
> _Infinite_Loop()
> [00001082](01) 55 push ebp
> [00001083](02) 8bec mov ebp,esp
> [00001085](02) ebfe jmp 00001085
> [00001087](01) 5d pop ebp
> [00001088](01) c3 ret
> Size in bytes:(0007) [00001088]
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
> ...[00001082][00211e7f][00211e83] 55 push ebp
> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> Infinite Loop Detected Simulation Stopped
>
> On the basis of this exact same utterly moronic reasoning because H
> *can't* do a correct and complete emulation of its input, H cannot
> possibly determine that _Infinite_Loop() never halts.

On 6/22/22 9:41 PM, olcott wrote:
> On 6/22/2022 8:36 PM, Richard Damon wrote:
>> On 6/22/22 9:29 PM, olcott wrote:
>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>
>>>>>>> First you agree that my words are perfectly correct within their
>>>>>>> specified context
>>>>>>
>>>>>> Since you haven't actualy defined you context, and imply that it
>>>>>> is the halting problem, where they can not be correct, that is not
>>>>>> possible.
>>>>>>>
>>>>> First you agree that these words are 100% correct within the
>>>>> context of software engineering totally ignoring the context of the
>>>>> halting problem.
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [000010d2](01)  55              push ebp
>>>>> [000010d3](02)  8bec            mov ebp,esp
>>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>>> [000010d8](01)  50              push eax
>>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [000010dc](01)  51              push ecx
>>>>> [000010dd](05)  e820feffff      call 00000f02
>>>>> [000010e2](03)  83c408          add esp,+08
>>>>> [000010e5](02)  85c0            test eax,eax
>>>>> [000010e7](02)  7402            jz 000010eb
>>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>>> [000010eb](01)  5d              pop ebp
>>>>> [000010ec](01)  c3              ret
>>>>> Size in bytes:(0027) [000010ec]
>>>>>
>>>>> Every sufficiently competent software engineer can easily verify
>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>> by H would never reach the "ret" instruction of P because both H
>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>
>>>>
>>>> So, if H actually is a program that does a COMPLETE and correct x86
>>>> emulation of its input, then YES, as I have said many time before,
>>>> this combination is non-halting.
>>>>
>>>> The fact that you need to keep going back to this, and seem to just
>>>> be refusing to accept the conditions under which you have proved it
>>>> just shows the problems with your thought process.
>>>>
>>>>> If H does correctly determine that this is the case in a finite
>>>>> number of steps then H could reject its input on this basis. Here
>>>>> are the details of exactly how H does this in a finite number of
>>>>> steps.
>>>>
>>>> Except that NOW H isn't the H we were just talking about, so you are
>>>> just proving that you are either lying or an idiot.
>>>>
>>>> Remember, the first analysis had the CONDITION on it that H did a
>>>> COMPLETE and correct x86 emulation.
>>>>
>>>> Once you remove that property form H, that conclusion no long holds
>>>> and you are shown to be a lying idiot.
>>>>
>>>>>
>>>>> typedef struct Decoded
>>>>> {
>>>>>    u32 Address;
>>>>>    u32 ESP;          // Current value of ESP
>>>>>    u32 TOS;          // Current value of Top of Stack
>>>>>    u32 NumBytes;
>>>>>    u32 Simplified_Opcode;
>>>>>    u32 Decode_Target;
>>>>> } Decoded_Line_Of_Code;
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> // actual fully operational code in the x86utm operating system
>>>>> u32 H(u32 P, u32 I)
>>>>> {
>>>>> HERE:
>>>>>    u32 End_Of_Code;
>>>>>    u32 Address_of_H;              // 2022-06-17
>>>>>    u32 code_end                  = get_code_end(P);
>>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>    Registers*  master_state      = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>    Registers*  slave_state       = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>    u32  execution_trace =
>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
>>>>>
>>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>>    __asm sub eax, 6                // 2022-06-18
>>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>>    __asm mov eax, END_OF_CODE
>>>>>    __asm mov End_Of_Code, eax
>>>>>
>>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>> execution_trace);
>>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>> &master_state,
>>>>>                       &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>        goto END_OF_CODE;
>>>>>    return 0;  // Does not halt
>>>>> END_OF_CODE:
>>>>>    return 1; // Input has normally terminated
>>>>> }
>>>>>
>>>>> H knows its own machine address and on this basis it can easily
>>>>> examine its stored execution_trace of P and determine:
>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>> infinitely recursive emulation.
>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>
>>>>>
>>>>
>>>> (b) is NOT a correct rule. Thos has been pointed out before, and you
>>>> have ignored it.
>>>>
>>> That you don't understand what I mean does not mean that it is an
>>> incorrect rule.
>>>
>>> Here is an example where P does have instruction that could possibly
>>> escape this otherwise infinitely recursive emulation:
>>>
>>>
>>> void P(ptr x)
>>> {
>>> static count = 0;
>>>    count++;
>>>    if count > 3)
>>>      return;
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>
>> FALLACY of proof by example. I never said that (b) isn't sometimes
>> true, just it isn't an always true condition. You fail at elementary
>> logic.
>
> Try and find a valid counter-example. Every attempt at rebuttal that is
> not a valid counter-example is one form of deception or another.
>
>

On 6/22/22 9:33 PM, olcott wrote:
> On 6/22/2022 8:19 PM, Richard Damon wrote:
>> On 6/22/22 9:03 PM, olcott wrote:
>>> On 6/22/2022 7:56 PM, Richard Damon wrote:
>>>> On 6/22/22 8:30 PM, olcott wrote:
>>>>> On 6/22/2022 7:22 PM, Richard Damon wrote:
>>>>>> On 6/22/22 7:39 PM, olcott wrote:
>>>>>>> On 6/22/2022 6:05 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 10:55 AM, olcott wrote:
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> You have this wrong.
>>>>>>>>
>>>>>>>> A decider must compute the mapping that represents the FUNCTION
>>>>>>>> it is deciding, there is actually nothing about "behavior" in
>>>>>>>> the definition.
>>>>>>>>
>>>>>>>> For a HALTING decider, that mapping is based on the HALTING
>>>>>>>> Behavior of the machine the input REPRESENTS.
>>>>>>>
>>>>>>> If you construe this as the actual behavior that the actual input
>>>>>>> specifies then this is correct otherwise this is incorrect.
>>>>>>
>>>>>> If it isn't the acutual behavior, then it just isn't a Halt
>>>>>> Decider, but maybe your POOP decider.
>>>>>>
>>>>> The behavior of P(P) is provably not the actual behavior of the
>>>>> actual input to H(P,P). That you are insufficiently technically
>>>>> competent to verify this is far less than no rebuttal at all.
>>>>>
>>>>
>>>> THen prove it.
>>>
>>> I have proved it dozens of times and every fake "rebuttal" simply
>>> ignores the proof.
>>>
>>>
>>
>> Nope, you have claimed it, and given rhetorical arguments.
>
> I have provided a complete provably correct execution traces of H(P,P)
> and P(P) that conclusively proves that they really do have different
> behavior yet people rejected it on the basis that they simply do not
> "believe in" the x86 language. This is why I aptly called them
> despicable liars.
>

On 6/22/22 9:37 PM, olcott wrote:
> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>
>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _P()
>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>>>>>> verify
>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to
>>>>>>>>>>>>> H(P,P)
>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because
>>>>>>>>>>>>> both H
>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If H does correctly determine that this is the case in a
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> number of steps then H could reject its input on this
>>>>>>>>>>>>> basis. Here
>>>>>>>>>>>>> are the details of exactly how H does this in a finite
>>>>>>>>>>>>> number of
>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>> {
>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>
>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 //
>>>>>>>>>>>>> call H
>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>
>>>>>>>>>>>>> // actual fully operational code in the x86utm operating
>>>>>>>>>>>>> system
>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>
>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>
>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P,
>>>>>>>>>>>>> I))
>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>>>>>> easily
>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was
>>>>>>>>>>>>> called with.
>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>>>>>>> invoked.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Technically competent software engineers may not know this
>>>>>>>>>>>>> computer
>>>>>>>>>>>>> science:
>>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior
>>>>>>>>>>>>> that is
>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>
>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided
>>>>>>>>>>>> correctly.
>>>>>>>>>>>> QED.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You and Richard are insufficiently technically competent at
>>>>>>>>>>> software
>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>
>>>>>>>>>>> A software engineer must be an expert in: the C programming
>>>>>>>>>>> language,
>>>>>>>>>>> the x86 programming language, exactly how C translates into
>>>>>>>>>>> x86 and
>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
>>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>>
>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++
>>>>>>>>>> experience; I also
>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite
>>>>>>>>>> recursion;
>>>>>>>>>> the problem is that you cannot recognize the fact that the
>>>>>>>>>> infinite
>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>>> omnishambles:
>>>>>>>>> If you are competent then you already know this is true and lie
>>>>>>>>> about it:
>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>> verify that
>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px)
>>>>>>>>> by H
>>>>>>>>> would never reach the "ret" instruction of P because both H and
>>>>>>>>> P would
>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>
>>>>>>>> H (if it was constructed correctly) is a computation, and a
>>>>>>>> computation *always* gives the same output for a given input. So
>>>>>>>> it doesn't make sense to say what it "would" do. It either does
>>>>>>>> or does not perform a complete and correct emulation. And
>>>>>>>> because H contains code to abort, and does abort, it does not do
>>>>>>>> a complete emulation.
>>>>>>>>
>>>>>>>> So the input must be given to a UTM, which by definition does a
>>>>>>>> correct and complete simulation, to see what the actual behavior
>>>>>>>> is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>
>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>> that
>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>
>>>>>> So you just repeated what you said instead of explaining why I'm
>>>>>> wrong. In other words you provided no rebuttal, which can only be
>>>>>> taken to mean that you have none.
>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>> provided an infallible one to that cannot possibly be correctly
>>>>> refuted
>>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>>> is only interested in rebuttal.
>>>>>
>>>>> I dare you to go back to the prior post and find any error in my
>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>>> admission of defeat.
>>>>
>>>> As stated before H (or more accurately Ha) does not perform a
>>>> complete and correct emulation because it aborts. So by definition
>>>> it cannot be complete.
>>> I never claimed that H(P,P) performs a complete and correct emulation of
>>> its input so your rebuttal is the strawman deception.
>>>
>>> I claimed that H(P,P) correctly predicts that its complete and correct
>>> x86 emulation of its input would never reach the "ret" instruction of P.
>>
>> But since H, or more accurately Ha, *can't* do a correct and complete
>> emulation of its input, your point is moot.
>
> _Infinite_Loop()
> [00001082](01)  55              push ebp
> [00001083](02)  8bec            mov ebp,esp
> [00001085](02)  ebfe            jmp 00001085
> [00001087](01)  5d              pop ebp
> [00001088](01)  c3              ret
> Size in bytes:(0007) [00001088]
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:211e8f
> ...[00001082][00211e7f][00211e83] 55       push ebp
> ...[00001083][00211e7f][00211e83] 8bec     mov ebp,esp
> ...[00001085][00211e7f][00211e83] ebfe     jmp 00001085
> ...[00001085][00211e7f][00211e83] ebfe     jmp 00001085
> Infinite Loop Detected Simulation Stopped
>
> On the basis of this exact same utterly moronic reasoning because H
> *can't* do a correct and complete emulation of its input, H cannot
> possibly determine that _Infinite_Loop() never halts.
>

On 6/22/2022 8:44 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>>>>>> science:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>
>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>>>>>>>>>>> QED.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>>
>>>>>>>>>>>> A software engineer must be an expert in: the C programming language,
>>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
>>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
>>>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>>>
>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>>>> omnishambles:
>>>>>>>>>> If you are competent then you already know this is true and lie about it:
>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
>>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>>
>>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>>>>>
>>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>>
>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>>
>>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>>> provided an infallible one to that cannot possibly be correctly refuted
>>>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>>>> is only interested in rebuttal.
>>>>>>
>>>>>> I dare you to go back to the prior post and find any error in my
>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>>>> admission of defeat.
>>>>>
>>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
>>>> I never claimed that H(P,P) performs a complete and correct emulation of
>>>> its input so your rebuttal is the strawman deception.
>>>>
>>>> I claimed that H(P,P) correctly predicts that its complete and correct
>>>> x86 emulation of its input would never reach the "ret" instruction of P.
>>>
>>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
>> _Infinite_Loop()
>> [00001082](01) 55 push ebp
>> [00001083](02) 8bec mov ebp,esp
>> [00001085](02) ebfe jmp 00001085
>> [00001087](01) 5d pop ebp
>> [00001088](01) c3 ret
>> Size in bytes:(0007) [00001088]
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
>> ...[00001082][00211e7f][00211e83] 55 push ebp
>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>> Infinite Loop Detected Simulation Stopped
>>
>> On the basis of this exact same utterly moronic reasoning because H
>> *can't* do a correct and complete emulation of its input, H cannot
>> possibly determine that _Infinite_Loop() never halts.
>
> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B

On 6/22/2022 8:45 PM, Richard Damon wrote:
> On 6/22/22 9:41 PM, olcott wrote:
>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>> On 6/22/22 9:29 PM, olcott wrote:
>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>
>>>>>>>> First you agree that my words are perfectly correct within their
>>>>>>>> specified context
>>>>>>>
>>>>>>> Since you haven't actualy defined you context, and imply that it
>>>>>>> is the halting problem, where they can not be correct, that is
>>>>>>> not possible.
>>>>>>>>
>>>>>> First you agree that these words are 100% correct within the
>>>>>> context of software engineering totally ignoring the context of
>>>>>> the halting problem.
>>>>>>
>>>>>> #include <stdint.h>
>>>>>> #define u32 uint32_t
>>>>>>
>>>>>> #include <stdint.h>
>>>>>> typedef void (*ptr)();
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    if (H(x, x))
>>>>>>      HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [000010d2](01)  55              push ebp
>>>>>> [000010d3](02)  8bec            mov ebp,esp
>>>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>>>> [000010d8](01)  50              push eax
>>>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>>>> [000010dc](01)  51              push ecx
>>>>>> [000010dd](05)  e820feffff      call 00000f02
>>>>>> [000010e2](03)  83c408          add esp,+08
>>>>>> [000010e5](02)  85c0            test eax,eax
>>>>>> [000010e7](02)  7402            jz 000010eb
>>>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>>>> [000010eb](01)  5d              pop ebp
>>>>>> [000010ec](01)  c3              ret
>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>
>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>
>>>>>
>>>>> So, if H actually is a program that does a COMPLETE and correct x86
>>>>> emulation of its input, then YES, as I have said many time before,
>>>>> this combination is non-halting.
>>>>>
>>>>> The fact that you need to keep going back to this, and seem to just
>>>>> be refusing to accept the conditions under which you have proved it
>>>>> just shows the problems with your thought process.
>>>>>
>>>>>> If H does correctly determine that this is the case in a finite
>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>> are the details of exactly how H does this in a finite number of
>>>>>> steps.
>>>>>
>>>>> Except that NOW H isn't the H we were just talking about, so you
>>>>> are just proving that you are either lying or an idiot.
>>>>>
>>>>> Remember, the first analysis had the CONDITION on it that H did a
>>>>> COMPLETE and correct x86 emulation.
>>>>>
>>>>> Once you remove that property form H, that conclusion no long holds
>>>>> and you are shown to be a lying idiot.
>>>>>
>>>>>>
>>>>>> typedef struct Decoded
>>>>>> {
>>>>>>    u32 Address;
>>>>>>    u32 ESP;          // Current value of ESP
>>>>>>    u32 TOS;          // Current value of Top of Stack
>>>>>>    u32 NumBytes;
>>>>>>    u32 Simplified_Opcode;
>>>>>>    u32 Decode_Target;
>>>>>> } Decoded_Line_Of_Code;
>>>>>>
>>>>>>   machine   stack     stack     machine    assembly
>>>>>>   address   address   data      code       language
>>>>>>   ========  ========  ========  =========  =============
>>>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>
>>>>>> // actual fully operational code in the x86utm operating system
>>>>>> u32 H(u32 P, u32 I)
>>>>>> {
>>>>>> HERE:
>>>>>>    u32 End_Of_Code;
>>>>>>    u32 Address_of_H;              // 2022-06-17
>>>>>>    u32 code_end                  = get_code_end(P);
>>>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>    Registers*  master_state      = (Registers*)
>>>>>> Allocate(sizeof(Registers));
>>>>>>    Registers*  slave_state       = (Registers*)
>>>>>> Allocate(sizeof(Registers));
>>>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>>    u32  execution_trace =
>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
>>>>>>
>>>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>>>    __asm sub eax, 6                // 2022-06-18
>>>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>>>    __asm mov eax, END_OF_CODE
>>>>>>    __asm mov End_Of_Code, eax
>>>>>>
>>>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>>> execution_trace);
>>>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>> &master_state,
>>>>>>                       &slave_state, &slave_stack, Address_of_H, P,
>>>>>> I))
>>>>>>        goto END_OF_CODE;
>>>>>>    return 0;  // Does not halt
>>>>>> END_OF_CODE:
>>>>>>    return 1; // Input has normally terminated
>>>>>> }
>>>>>>
>>>>>> H knows its own machine address and on this basis it can easily
>>>>>> examine its stored execution_trace of P and determine:
>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>> infinitely recursive emulation.
>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>
>>>>>>
>>>>>
>>>>> (b) is NOT a correct rule. Thos has been pointed out before, and
>>>>> you have ignored it.
>>>>>
>>>> That you don't understand what I mean does not mean that it is an
>>>> incorrect rule.
>>>>
>>>> Here is an example where P does have instruction that could possibly
>>>> escape this otherwise infinitely recursive emulation:
>>>>
>>>>
>>>> void P(ptr x)
>>>> {
>>>> static count = 0;
>>>>    count++;
>>>>    if count > 3)
>>>>      return;
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>
>>> FALLACY of proof by example. I never said that (b) isn't sometimes
>>> true, just it isn't an always true condition. You fail at elementary
>>> logic.
>>
>> Try and find a valid counter-example. Every attempt at rebuttal that
>> is not a valid counter-example is one form of deception or another.
>>
>>
>
> P(P)

On 6/22/22 10:15 PM, olcott wrote:
> On 6/22/2022 8:44 PM, Dennis Bush wrote:
>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>>>>>>>> verify
>>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input
>>>>>>>>>>>>>>> to H(P,P)
>>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because
>>>>>>>>>>>>>>> both H
>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If H does correctly determine that this is the case in a
>>>>>>>>>>>>>>> finite
>>>>>>>>>>>>>>> number of steps then H could reject its input on this
>>>>>>>>>>>>>>> basis. Here
>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite
>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02
>>>>>>>>>>>>>>> // call H
>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating
>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state,
>>>>>>>>>>>>>>> slave_stack);
>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H,
>>>>>>>>>>>>>>> P, I))
>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>>>>>>>> easily
>>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was
>>>>>>>>>>>>>>> called with.
>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this
>>>>>>>>>>>>>>> otherwise
>>>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>>>>>>>>> invoked.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Technically competent software engineers may not know
>>>>>>>>>>>>>>> this computer
>>>>>>>>>>>>>>> science:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs
>>>>>>>>>>>>>>> to an
>>>>>>>>>>>>>>> accept or reject state on the basis of the actual
>>>>>>>>>>>>>>> behavior that is
>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided
>>>>>>>>>>>>>> correctly.
>>>>>>>>>>>>>> QED.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You and Richard are insufficiently technically competent at
>>>>>>>>>>>>> software
>>>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>>>
>>>>>>>>>>>>> A software engineer must be an expert in: the C programming
>>>>>>>>>>>>> language,
>>>>>>>>>>>>> the x86 programming language, exactly how C translates into
>>>>>>>>>>>>> x86 and
>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86
>>>>>>>>>>>>> assembly
>>>>>>>>>>>>> language level. No knowledge of the halting problem is
>>>>>>>>>>>>> required.
>>>>>>>>>>>>
>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++
>>>>>>>>>>>> experience; I also
>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog
>>>>>>>>>>>> Z80A CPU
>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite
>>>>>>>>>>>> recursion;
>>>>>>>>>>>> the problem is that you cannot recognize the fact that the
>>>>>>>>>>>> infinite
>>>>>>>>>>>> recursion only manifests as part of your invalid
>>>>>>>>>>>> simulation-based
>>>>>>>>>>>> omnishambles:
>>>>>>>>>>> If you are competent then you already know this is true and
>>>>>>>>>>> lie about it:
>>>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>>>> verify that
>>>>>>>>>>> the complete and correct x86 emulation of the input to
>>>>>>>>>>> H(Px,Px) by H
>>>>>>>>>>> would never reach the "ret" instruction of P because both H
>>>>>>>>>>> and P would
>>>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>>>
>>>>>>>>>> H (if it was constructed correctly) is a computation, and a
>>>>>>>>>> computation *always* gives the same output for a given input.
>>>>>>>>>> So it doesn't make sense to say what it "would" do. It either
>>>>>>>>>> does or does not perform a complete and correct emulation. And
>>>>>>>>>> because H contains code to abort, and does abort, it does not
>>>>>>>>>> do a complete emulation.
>>>>>>>>>>
>>>>>>>>>> So the input must be given to a UTM, which by definition does
>>>>>>>>>> a correct and complete simulation, to see what the actual
>>>>>>>>>> behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>>>
>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>> verify that
>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px)
>>>>>>>>> by H
>>>>>>>>> would never reach the "ret" instruction of Px because both H
>>>>>>>>> and Px
>>>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>>>
>>>>>>>> So you just repeated what you said instead of explaining why I'm
>>>>>>>> wrong. In other words you provided no rebuttal, which can only
>>>>>>>> be taken to mean that you have none.
>>>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>>>> provided an infallible one to that cannot possibly be correctly
>>>>>>> refuted
>>>>>>> you simply dodged it. That is a smart move for a dishonest person
>>>>>>> that
>>>>>>> is only interested in rebuttal.
>>>>>>>
>>>>>>> I dare you to go back to the prior post and find any error in my
>>>>>>> airtight correct reasoning. Another dodge will be construed as a
>>>>>>> tacit
>>>>>>> admission of defeat.
>>>>>>
>>>>>> As stated before H (or more accurately Ha) does not perform a
>>>>>> complete and correct emulation because it aborts. So by definition
>>>>>> it cannot be complete.
>>>>> I never claimed that H(P,P) performs a complete and correct
>>>>> emulation of
>>>>> its input so your rebuttal is the strawman deception.
>>>>>
>>>>> I claimed that H(P,P) correctly predicts that its complete and correct
>>>>> x86 emulation of its input would never reach the "ret" instruction
>>>>> of P.
>>>>
>>>> But since H, or more accurately Ha, *can't* do a correct and
>>>> complete emulation of its input, your point is moot.
>>> _Infinite_Loop()
>>> [00001082](01) 55 push ebp
>>> [00001083](02) 8bec mov ebp,esp
>>> [00001085](02) ebfe jmp 00001085
>>> [00001087](01) 5d pop ebp
>>> [00001088](01) c3 ret
>>> Size in bytes:(0007) [00001088]
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
>>> ...[00001082][00211e7f][00211e83] 55 push ebp
>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>> Infinite Loop Detected Simulation Stopped
>>>
>>> On the basis of this exact same utterly moronic reasoning because H
>>> *can't* do a correct and complete emulation of its input, H cannot
>>> possibly determine that _Infinite_Loop() never halts.
>>
>> Now who's using the strawman error?  Just because H can determine that
>> _Infinite_Loop does not halt doesn't mean that it gets other cases
>> right.  B
>
> You just said that H(P,P) cannot correctly predict that the correct and
> complete x86 emulation of its input would never reach the "ret"
> instruction of P without a compete x86 emulation of its input. I just
> proved that is a very stupid thing to say.
>

On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
> On 6/22/2022 8:44 PM, Dennis Bush wrote:
> > On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
> >> On 6/22/2022 8:21 PM, Dennis Bush wrote:
> >>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
> >>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
> >>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
> >>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
> >>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>> #define u32 uint32_t
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>> [000010d2](01) 55 push ebp
> >>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>> [000010d8](01) 50 push eax
> >>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>> [000010dc](01) 51 push ecx
> >>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
> >>>>>>>>>>>>>> [000010ec](01) c3 ret
> >>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
> >>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
> >>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
> >>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation..
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
> >>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
> >>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
> >>>>>>>>>>>>>> steps.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> typedef struct Decoded
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> u32 Address;
> >>>>>>>>>>>>>> u32 ESP; // Current value of ESP
> >>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>>>>>>>>>> u32 NumBytes;
> >>>>>>>>>>>>>> u32 Simplified_Opcode;
> >>>>>>>>>>>>>> u32 Decode_Target;
> >>>>>>>>>>>>>> } Decoded_Line_Of_Code;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> >>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
> >>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
> >>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
> >>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
> >>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
> >>>>>>>>>>>>>> u32 H(u32 P, u32 I)
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> HERE:
> >>>>>>>>>>>>>> u32 End_Of_Code;
> >>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>>>>>>>>>> u32 code_end = get_code_end(P);
> >>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> >>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>>>>>>>>>> Registers* master_state = (Registers*)
> >>>>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>>>> Registers* slave_state = (Registers*)
> >>>>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
> >>>>>>>>>>>>>> u32 execution_trace =
> >>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>>>>>>>>>> * 1000);
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
> >>>>>>>>>>>>>> __asm mov End_Of_Code, eax
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
> >>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> >>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
> >>>>>>>>>>>>>> execution_trace);
> >>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
> >>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
> >>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
> >>>>>>>>>>>>>> infinitely recursive emulation.
> >>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Technically competent software engineers may not know this computer
> >>>>>>>>>>>>>> science:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
> >>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The "ret" instruction of P is its final state.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> >>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>> return;
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> int main()
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>>>>>>>>>> Input_Halts = 0
> >>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
> >>>>>>>>>>>>> QED.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> You and Richard are insufficiently technically competent at software
> >>>>>>>>>>>> engineering not meeting these specs:
> >>>>>>>>>>>>
> >>>>>>>>>>>> A software engineer must be an expert in: the C programming language,
> >>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
> >>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
> >>>>>>>>>>>> language level. No knowledge of the halting problem is required.
> >>>>>>>>>>>
> >>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
> >>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
> >>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
> >>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
> >>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
> >>>>>>>>>>> omnishambles:
> >>>>>>>>>> If you are competent then you already know this is true and lie about it:
> >>>>>>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
> >>>>>>>>>> remain stuck in infinitely recursive emulation.
> >>>>>>>>>
> >>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
> >>>>>>>>>
> >>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
> >>>>>>>>
> >>>>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>>>> would never reach the "ret" instruction of Px because both H and Px
> >>>>>>>> would remain stuck in infinitely recursive emulation.
> >>>>>>>
> >>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
> >>>>>> Your entire basis and all of assumptions was incorrect so when I
> >>>>>> provided an infallible one to that cannot possibly be correctly refuted
> >>>>>> you simply dodged it. That is a smart move for a dishonest person that
> >>>>>> is only interested in rebuttal.
> >>>>>>
> >>>>>> I dare you to go back to the prior post and find any error in my
> >>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
> >>>>>> admission of defeat.
> >>>>>
> >>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
> >>>> I never claimed that H(P,P) performs a complete and correct emulation of
> >>>> its input so your rebuttal is the strawman deception.
> >>>>
> >>>> I claimed that H(P,P) correctly predicts that its complete and correct
> >>>> x86 emulation of its input would never reach the "ret" instruction of P.
> >>>
> >>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
> >> _Infinite_Loop()
> >> [00001082](01) 55 push ebp
> >> [00001083](02) 8bec mov ebp,esp
> >> [00001085](02) ebfe jmp 00001085
> >> [00001087](01) 5d pop ebp
> >> [00001088](01) c3 ret
> >> Size in bytes:(0007) [00001088]
> >>
> >> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
> >> ...[00001082][00211e7f][00211e83] 55 push ebp
> >> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
> >> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >> Infinite Loop Detected Simulation Stopped
> >>
> >> On the basis of this exact same utterly moronic reasoning because H
> >> *can't* do a correct and complete emulation of its input, H cannot
> >> possibly determine that _Infinite_Loop() never halts.
> >
> > Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
> You just said that H(P,P) cannot correctly predict that the correct and
> complete x86 emulation of its input would never reach the "ret"
> instruction of P without a compete x86 emulation of its input. I just
> proved that is a very stupid thing to say.

On 6/22/22 10:18 PM, olcott wrote:
> On 6/22/2022 8:45 PM, Richard Damon wrote:
>> On 6/22/22 9:41 PM, olcott wrote:
>>> On 6/22/2022 8:36 PM, Richard Damon wrote:
>>>> On 6/22/22 9:29 PM, olcott wrote:
>>>>> On 6/22/2022 8:14 PM, Richard Damon wrote:
>>>>>> On 6/22/22 8:55 PM, olcott wrote:
>>>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>>>>>>
>>>>>>>>> First you agree that my words are perfectly correct within
>>>>>>>>> their specified context
>>>>>>>>
>>>>>>>> Since you haven't actualy defined you context, and imply that it
>>>>>>>> is the halting problem, where they can not be correct, that is
>>>>>>>> not possible.
>>>>>>>>>
>>>>>>> First you agree that these words are 100% correct within the
>>>>>>> context of software engineering totally ignoring the context of
>>>>>>> the halting problem.
>>>>>>>
>>>>>>> #include <stdint.h>
>>>>>>> #define u32 uint32_t
>>>>>>>
>>>>>>> #include <stdint.h>
>>>>>>> typedef void (*ptr)();
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    if (H(x, x))
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [000010d2](01)  55              push ebp
>>>>>>> [000010d3](02)  8bec            mov ebp,esp
>>>>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>>>>> [000010d8](01)  50              push eax
>>>>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>> [000010dc](01)  51              push ecx
>>>>>>> [000010dd](05)  e820feffff      call 00000f02
>>>>>>> [000010e2](03)  83c408          add esp,+08
>>>>>>> [000010e5](02)  85c0            test eax,eax
>>>>>>> [000010e7](02)  7402            jz 000010eb
>>>>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>>>>> [000010eb](01)  5d              pop ebp
>>>>>>> [000010ec](01)  c3              ret
>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>
>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>> that the complete and correct x86 emulation of the input to
>>>>>>> H(P,P) by H would never reach the "ret" instruction of P because
>>>>>>> both H and P would remain stuck in infinitely recursive emulation.
>>>>>>>
>>>>>>
>>>>>> So, if H actually is a program that does a COMPLETE and correct
>>>>>> x86 emulation of its input, then YES, as I have said many time
>>>>>> before, this combination is non-halting.
>>>>>>
>>>>>> The fact that you need to keep going back to this, and seem to
>>>>>> just be refusing to accept the conditions under which you have
>>>>>> proved it just shows the problems with your thought process.
>>>>>>
>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>> steps.
>>>>>>
>>>>>> Except that NOW H isn't the H we were just talking about, so you
>>>>>> are just proving that you are either lying or an idiot.
>>>>>>
>>>>>> Remember, the first analysis had the CONDITION on it that H did a
>>>>>> COMPLETE and correct x86 emulation.
>>>>>>
>>>>>> Once you remove that property form H, that conclusion no long
>>>>>> holds and you are shown to be a lying idiot.
>>>>>>
>>>>>>>
>>>>>>> typedef struct Decoded
>>>>>>> {
>>>>>>>    u32 Address;
>>>>>>>    u32 ESP;          // Current value of ESP
>>>>>>>    u32 TOS;          // Current value of Top of Stack
>>>>>>>    u32 NumBytes;
>>>>>>>    u32 Simplified_Opcode;
>>>>>>>    u32 Decode_Target;
>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>
>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>   address   address   data      code       language
>>>>>>>   ========  ========  ========  =========  =============
>>>>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>
>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>> u32 H(u32 P, u32 I)
>>>>>>> {
>>>>>>> HERE:
>>>>>>>    u32 End_Of_Code;
>>>>>>>    u32 Address_of_H;              // 2022-06-17
>>>>>>>    u32 code_end                  = get_code_end(P);
>>>>>>>    Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>    Registers*  master_state      = (Registers*)
>>>>>>> Allocate(sizeof(Registers));
>>>>>>>    Registers*  slave_state       = (Registers*)
>>>>>>> Allocate(sizeof(Registers));
>>>>>>>    u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>>>    u32  execution_trace =
>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 1000);
>>>>>>>
>>>>>>>    __asm lea eax, HERE             // 2022-06-18
>>>>>>>    __asm sub eax, 6                // 2022-06-18
>>>>>>>    __asm mov Address_of_H, eax     // 2022-06-18
>>>>>>>    __asm mov eax, END_OF_CODE
>>>>>>>    __asm mov End_Of_Code, eax
>>>>>>>
>>>>>>>    Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>    Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>    Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>>>> execution_trace);
>>>>>>>    if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>> &master_state,
>>>>>>>                       &slave_state, &slave_stack, Address_of_H,
>>>>>>> P, I))
>>>>>>>        goto END_OF_CODE;
>>>>>>>    return 0;  // Does not halt
>>>>>>> END_OF_CODE:
>>>>>>>    return 1; // Input has normally terminated
>>>>>>> }
>>>>>>>
>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>> infinitely recursive emulation.
>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> (b) is NOT a correct rule. Thos has been pointed out before, and
>>>>>> you have ignored it.
>>>>>>
>>>>> That you don't understand what I mean does not mean that it is an
>>>>> incorrect rule.
>>>>>
>>>>> Here is an example where P does have instruction that could
>>>>> possibly escape this otherwise infinitely recursive emulation:
>>>>>
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>> static count = 0;
>>>>>    count++;
>>>>>    if count > 3)
>>>>>      return;
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>
>>>> FALLACY of proof by example. I never said that (b) isn't sometimes
>>>> true, just it isn't an always true condition. You fail at elementary
>>>> logic.
>>>
>>> Try and find a valid counter-example. Every attempt at rebuttal that
>>> is not a valid counter-example is one form of deception or another.
>>>
>>>
>>
>> P(P)
>
> That is not any example of (b), thus another mere strawman deception.
>

On 6/22/2022 9:22 PM, Richard Damon wrote:
> On 6/22/22 10:15 PM, olcott wrote:
>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every sufficiently competent software engineer can
>>>>>>>>>>>>>>>> easily verify
>>>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input
>>>>>>>>>>>>>>>> to H(P,P)
>>>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P
>>>>>>>>>>>>>>>> because both H
>>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If H does correctly determine that this is the case in a
>>>>>>>>>>>>>>>> finite
>>>>>>>>>>>>>>>> number of steps then H could reject its input on this
>>>>>>>>>>>>>>>> basis. Here
>>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite
>>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02
>>>>>>>>>>>>>>>> // call H
>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating
>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state,
>>>>>>>>>>>>>>>> slave_stack);
>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H,
>>>>>>>>>>>>>>>> P, I))
>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>>>>>>>>> easily
>>>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was
>>>>>>>>>>>>>>>> called with.
>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this
>>>>>>>>>>>>>>>> otherwise
>>>>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>>>>>>>>>> invoked.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Technically competent software engineers may not know
>>>>>>>>>>>>>>>> this computer
>>>>>>>>>>>>>>>> science:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs
>>>>>>>>>>>>>>>> to an
>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual
>>>>>>>>>>>>>>>> behavior that is
>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages
>>>>>>>>>>>>>>>> and Automata.
>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided
>>>>>>>>>>>>>>> correctly.
>>>>>>>>>>>>>>> QED.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You and Richard are insufficiently technically competent
>>>>>>>>>>>>>> at software
>>>>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A software engineer must be an expert in: the C
>>>>>>>>>>>>>> programming language,
>>>>>>>>>>>>>> the x86 programming language, exactly how C translates
>>>>>>>>>>>>>> into x86 and
>>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86
>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>> language level. No knowledge of the halting problem is
>>>>>>>>>>>>>> required.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++
>>>>>>>>>>>>> experience; I also
>>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog
>>>>>>>>>>>>> Z80A CPU
>>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite
>>>>>>>>>>>>> recursion;
>>>>>>>>>>>>> the problem is that you cannot recognize the fact that the
>>>>>>>>>>>>> infinite
>>>>>>>>>>>>> recursion only manifests as part of your invalid
>>>>>>>>>>>>> simulation-based
>>>>>>>>>>>>> omnishambles:
>>>>>>>>>>>> If you are competent then you already know this is true and
>>>>>>>>>>>> lie about it:
>>>>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>>>>> verify that
>>>>>>>>>>>> the complete and correct x86 emulation of the input to
>>>>>>>>>>>> H(Px,Px) by H
>>>>>>>>>>>> would never reach the "ret" instruction of P because both H
>>>>>>>>>>>> and P would
>>>>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>>>>
>>>>>>>>>>> H (if it was constructed correctly) is a computation, and a
>>>>>>>>>>> computation *always* gives the same output for a given input.
>>>>>>>>>>> So it doesn't make sense to say what it "would" do. It either
>>>>>>>>>>> does or does not perform a complete and correct emulation.
>>>>>>>>>>> And because H contains code to abort, and does abort, it does
>>>>>>>>>>> not do a complete emulation.
>>>>>>>>>>>
>>>>>>>>>>> So the input must be given to a UTM, which by definition does
>>>>>>>>>>> a correct and complete simulation, to see what the actual
>>>>>>>>>>> behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>>>>
>>>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>>>> verify that
>>>>>>>>>> the complete and correct x86 emulation of the input to
>>>>>>>>>> H(Px,Px) by H
>>>>>>>>>> would never reach the "ret" instruction of Px because both H
>>>>>>>>>> and Px
>>>>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>>>>
>>>>>>>>> So you just repeated what you said instead of explaining why
>>>>>>>>> I'm wrong. In other words you provided no rebuttal, which can
>>>>>>>>> only be taken to mean that you have none.
>>>>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>>>>> provided an infallible one to that cannot possibly be correctly
>>>>>>>> refuted
>>>>>>>> you simply dodged it. That is a smart move for a dishonest
>>>>>>>> person that
>>>>>>>> is only interested in rebuttal.
>>>>>>>>
>>>>>>>> I dare you to go back to the prior post and find any error in my
>>>>>>>> airtight correct reasoning. Another dodge will be construed as a
>>>>>>>> tacit
>>>>>>>> admission of defeat.
>>>>>>>
>>>>>>> As stated before H (or more accurately Ha) does not perform a
>>>>>>> complete and correct emulation because it aborts. So by
>>>>>>> definition it cannot be complete.
>>>>>> I never claimed that H(P,P) performs a complete and correct
>>>>>> emulation of
>>>>>> its input so your rebuttal is the strawman deception.
>>>>>>
>>>>>> I claimed that H(P,P) correctly predicts that its complete and
>>>>>> correct
>>>>>> x86 emulation of its input would never reach the "ret" instruction
>>>>>> of P.
>>>>>
>>>>> But since H, or more accurately Ha, *can't* do a correct and
>>>>> complete emulation of its input, your point is moot.
>>>> _Infinite_Loop()
>>>> [00001082](01) 55 push ebp
>>>> [00001083](02) 8bec mov ebp,esp
>>>> [00001085](02) ebfe jmp 00001085
>>>> [00001087](01) 5d pop ebp
>>>> [00001088](01) c3 ret
>>>> Size in bytes:(0007) [00001088]
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
>>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>> Infinite Loop Detected Simulation Stopped
>>>>
>>>> On the basis of this exact same utterly moronic reasoning because H
>>>> *can't* do a correct and complete emulation of its input, H cannot
>>>> possibly determine that _Infinite_Loop() never halts.
>>>
>>> Now who's using the strawman error?  Just because H can determine
>>> that _Infinite_Loop does not halt doesn't mean that it gets other
>>> cases right.  B
>>
>> You just said that H(P,P) cannot correctly predict that the correct
>> and complete x86 emulation of its input would never reach the "ret"
>> instruction of P without a compete x86 emulation of its input. I just
>> proved that is a very stupid thing to say.
>>
>
> No, that isn't what he said. Just shows you can't read.
>
> He said that an H that aborts its simulation can't do a Complete and
> Correct emulation of its input.

On 6/22/2022 9:23 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>>>>>>>>>> [000010ec](01) c3 ret
>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
>>>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
>>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
>>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> typedef struct Decoded
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> u32 Address;
>>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>>>>>>>>>> u32 NumBytes;
>>>>>>>>>>>>>>>> u32 Simplified_Opcode;
>>>>>>>>>>>>>>>> u32 Decode_Target;
>>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
>>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
>>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
>>>>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>>>>>>>>>>> infinitely recursive emulation.
>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>>>>>>>> science:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>>>>>>>>>>>>> QED.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A software engineer must be an expert in: the C programming language,
>>>>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
>>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
>>>>>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>>>>>> omnishambles:
>>>>>>>>>>>> If you are competent then you already know this is true and lie about it:
>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
>>>>>>>>>>>> remain stuck in infinitely recursive emulation.
>>>>>>>>>>>
>>>>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>>>>>>>
>>>>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>>>>
>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px
>>>>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>>>>
>>>>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>>>>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
>>>>>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>>>>>> is only interested in rebuttal.
>>>>>>>>
>>>>>>>> I dare you to go back to the prior post and find any error in my
>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>>>>>> admission of defeat.
>>>>>>>
>>>>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
>>>>>> I never claimed that H(P,P) performs a complete and correct emulation of
>>>>>> its input so your rebuttal is the strawman deception.
>>>>>>
>>>>>> I claimed that H(P,P) correctly predicts that its complete and correct
>>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
>>>>>
>>>>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
>>>> _Infinite_Loop()
>>>> [00001082](01) 55 push ebp
>>>> [00001083](02) 8bec mov ebp,esp
>>>> [00001085](02) ebfe jmp 00001085
>>>> [00001087](01) 5d pop ebp
>>>> [00001088](01) c3 ret
>>>> Size in bytes:(0007) [00001088]
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
>>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>> Infinite Loop Detected Simulation Stopped
>>>>
>>>> On the basis of this exact same utterly moronic reasoning because H
>>>> *can't* do a correct and complete emulation of its input, H cannot
>>>> possibly determine that _Infinite_Loop() never halts.
>>>
>>> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
>> You just said that H(P,P) cannot correctly predict that the correct and
>> complete x86 emulation of its input would never reach the "ret"
>> instruction of P without a compete x86 emulation of its input. I just
>> proved that is a very stupid thing to say.
>
> You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,P), would do. And it fails to do that.

On Wednesday, June 22, 2022 at 10:46:14 PM UTC-4, olcott wrote:
> On 6/22/2022 9:23 PM, Dennis Bush wrote:
> > On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
> >> On 6/22/2022 8:44 PM, Dennis Bush wrote:
> >>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
> >>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
> >>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
> >>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
> >>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>> #define u32 uint32_t
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _P()
> >>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
> >>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>> [000010d8](01) 50 push eax
> >>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
> >>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp
> >>>>>>>>>>>>>>>> [000010ec](01) c3 ret
> >>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify
> >>>>>>>>>>>>>>>> that the complete and correct x86 emulation of the input to H(P,P)
> >>>>>>>>>>>>>>>> by H would never reach the "ret" instruction of P because both H
> >>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If H does correctly determine that this is the case in a finite
> >>>>>>>>>>>>>>>> number of steps then H could reject its input on this basis. Here
> >>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
> >>>>>>>>>>>>>>>> steps.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> typedef struct Decoded
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> u32 Address;
> >>>>>>>>>>>>>>>> u32 ESP; // Current value of ESP
> >>>>>>>>>>>>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>>>>>>>>>>>> u32 NumBytes;
> >>>>>>>>>>>>>>>> u32 Simplified_Opcode;
> >>>>>>>>>>>>>>>> u32 Decode_Target;
> >>>>>>>>>>>>>>>> } Decoded_Line_Of_Code;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> machine stack stack machine assembly
> >>>>>>>>>>>>>>>> address address data code language
> >>>>>>>>>>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>>>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> >>>>>>>>>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax // push P
> >>>>>>>>>>>>>>>> [000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
> >>>>>>>>>>>>>>>> [000010dc][00211e82][000010d2] 51 push ecx // push P
> >>>>>>>>>>>>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02 // call H
> >>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
> >>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> HERE:
> >>>>>>>>>>>>>>>> u32 End_Of_Code;
> >>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
> >>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> >>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
> >>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
> >>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
> >>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
> >>>>>>>>>>>>>>>> u32 execution_trace =
> >>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>>>>>>>>>>>> * 1000);
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
> >>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
> >>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
> >>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",
> >>>>>>>>>>>>>>>> execution_trace);
> >>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
> >>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>>>>>>>>>>>> goto END_OF_CODE;
> >>>>>>>>>>>>>>>> return 0; // Does not halt
> >>>>>>>>>>>>>>>> END_OF_CODE:
> >>>>>>>>>>>>>>>> return 1; // Input has normally terminated
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily
> >>>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:
> >>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
> >>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
> >>>>>>>>>>>>>>>> infinitely recursive emulation.
> >>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Technically competent software engineers may not know this computer
> >>>>>>>>>>>>>>>> science:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
> >>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> >>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> void Px(u32 x)
> >>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>>>>>>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>>>>>>>>>>>> Input_Halts = 0
> >>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>>>>>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>>>>>>>>>>>> Number of Instructions Executed(16120)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been decided correctly.
> >>>>>>>>>>>>>>> QED.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You and Richard are insufficiently technically competent at software
> >>>>>>>>>>>>>> engineering not meeting these specs:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> A software engineer must be an expert in: the C programming language,
> >>>>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
> >>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly
> >>>>>>>>>>>>>> language level. No knowledge of the halting problem is required.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
> >>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
> >>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
> >>>>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
> >>>>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
> >>>>>>>>>>>>> omnishambles:
> >>>>>>>>>>>> If you are competent then you already know this is true and lie about it:
> >>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>>>>>>>> would never reach the "ret" instruction of P because both H and P would
> >>>>>>>>>>>> remain stuck in infinitely recursive emulation.
> >>>>>>>>>>>
> >>>>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
> >>>>>>>>>>>
> >>>>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
> >>>>>>>>>>
> >>>>>>>>>> Every sufficiently competent software engineer can easily verify that
> >>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
> >>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px
> >>>>>>>>>> would remain stuck in infinitely recursive emulation.
> >>>>>>>>>
> >>>>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
> >>>>>>>> Your entire basis and all of assumptions was incorrect so when I
> >>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
> >>>>>>>> you simply dodged it. That is a smart move for a dishonest person that
> >>>>>>>> is only interested in rebuttal.
> >>>>>>>>
> >>>>>>>> I dare you to go back to the prior post and find any error in my
> >>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
> >>>>>>>> admission of defeat.
> >>>>>>>
> >>>>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
> >>>>>> I never claimed that H(P,P) performs a complete and correct emulation of
> >>>>>> its input so your rebuttal is the strawman deception.
> >>>>>>
> >>>>>> I claimed that H(P,P) correctly predicts that its complete and correct
> >>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
> >>>>>
> >>>>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
> >>>> _Infinite_Loop()
> >>>> [00001082](01) 55 push ebp
> >>>> [00001083](02) 8bec mov ebp,esp
> >>>> [00001085](02) ebfe jmp 00001085
> >>>> [00001087](01) 5d pop ebp
> >>>> [00001088](01) c3 ret
> >>>> Size in bytes:(0007) [00001088]
> >>>>
> >>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
> >>>> ...[00001082][00211e7f][00211e83] 55 push ebp
> >>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
> >>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
> >>>> Infinite Loop Detected Simulation Stopped
> >>>>
> >>>> On the basis of this exact same utterly moronic reasoning because H
> >>>> *can't* do a correct and complete emulation of its input, H cannot
> >>>> possibly determine that _Infinite_Loop() never halts.
> >>>
> >>> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B
> >> You just said that H(P,P) cannot correctly predict that the correct and
> >> complete x86 emulation of its input would never reach the "ret"
> >> instruction of P without a compete x86 emulation of its input. I just
> >> proved that is a very stupid thing to say.
> >
> > You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,P), would do. And it fails to do that.
> There are no UTM's in software engineering thus yet another strawman
> deception.