On 6/22/2022 5:10 PM, Jeff Barnett wrote:
> On 6/22/2022 12:10 PM, olcott wrote:
>> On 6/22/2022 12:11 PM, Jeff Barnett wrote:
>>> On 6/21/2022 8:38 PM, olcott wrote:
>>>
>>> <SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
>>>
>>> Peter, you must first identify a competent Software Engineer to do
>>> said verification. There are two problems: The first is that no
>>> competent SE would verify your claims whether or not you shared your
>>> crap code with them. You don't certify a black box from the outside
>>> because there are too many simple errors that wont be caught.
>
>> My words are perfectly clear and correct thus leaving the only
>> possible rebuttal of changing the words and forming a rebuttal on the
>> basis of these changed words.
> Your words are not clear even to you. Are you really that stupid? Your
> not a Software Engineer, Computer Scientist, or a Programmer of even
> modest skills. Sorry. Your accomplishments here on USENET or on the job
> are of so trite a nature that no one of any accomplishments in these
> areas can allow you pollute newsgroup after newsgroup with the same
> repetitive dribble. I think you have invented the "E" version of the
> good old "cluster fuck". (That's one innovation you can put on your
> resume.)
>
>> Every sufficiently competent software engineer can easily verify that
>> the complete and correct x86 emulation of the input to H(P,P) by H
>> would never reach the "ret" instruction of P because both H and P
>> would remain stuck in infinitely recursive emulation.
>
> And that's the point. You are neither a competent Software Engineer nor
> one who can judge competence. Remember all those employers who told you
> the same thing.
>
>> After 100 reviewers in a dozen forums over a period of one year:
>> On 6/14/2022 6:47 AM, Paul N wrote:
>>  > Yes, it is clear to us humans watching
>>  > it that the program is repeating itself.
>>  > Thus we can appreciate that it will never
>>  > reach the final "ret" - indeed, it won't
>>  > even get to the infinite loop identified above.
>>
>> If H can determine that this is the case in a finite number of steps
>> then H could correctly reject its input on this basis.
>
> Let's give Paul N a little credit but not much; notice that he doesn't
> even understand the point of the exercise which is that the *same
> function* must be used for both inner and outer purposes.
>
>> Sufficiently competent software engineers will agree that if you
>> cannot verify that the above reasoning is valid forms sufficient proof
>> that you are not a sufficiently competent software engineer as defined
>> below:
>
> Ass backwards as usual.
>
>> A software engineer must be an expert in: the C programming language,
>> the x86 programming language, exactly how C translates into x86 and
>> the ability to recognize infinite recursion at the x86 assembly
>> language level. No knowledge of the halting problem is required.
>
> That's really a shame for you since you have little knowledge or
> competence in anything above. Strangely you need knowledge of the
> halting problem to judge whether you have a legit counter example. So as
> to what you "need knowledge of", you are once again ass backward.
>
>>> The second is that you have nominated yourself as a competent SE. NOT!!!
>>
>> Clueless wonders always use ad hominem personal attacks as their basis
>> of rebuttal because that is all that they have.
>
> Mine isn't an ad hominem attack: It is based not only on my perception
> of your nonsense but 100's of others pointing out glaring repetitive
> errors. You on the other hand repeated nonsense, most of it off topic,
> and then claim that someone else's competence is lacking.
>
> Let's close by paraphrasing Schopenhauer to describe you Peter:
>
> "Ignorance induces errors no one else could duplicate;
>  Ignorance + stupidity and ambition induce errors no one could foresee."

All that you have ever provided as rebuttal is some combination of mere
rhetoric that mostly nothing more than pure ad hominem personal attacks.
I known that you have good technical reasoning, yet you have never shown
any of it in any critique of my work.

No one can possibly provide any correct rebuttal to this because it is a
semantic tautology: proven totally true entirely on the basis of the
meaning of its words:

#include <stdint.h>
#define u32 uint32_t

#include <stdint.h>
typedef void (*ptr)();

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

int main()
{ Output("Input_Halts = ", H(P, P));
}

_P()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]

Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px
would remain stuck in infinitely recursive emulation.

When we assume this non-halting criteria and H does correctly apply this
criteria in a finite number of steps then H(Px,Px) does correctly
determine that its input never halts.

The above proves itself totally true entirely on the basis of the
meaning of its words: AKA it is self-evident truth.

In epistemology (theory of knowledge), a self-evident proposition is a
proposition that is known to be true by understanding its meaning
without proof, and/or by ordinary human reason.
https://en.wikipedia.org/wiki/Self-evidence

--
Copyright 2022 Pete Olcott

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

On 6/22/2022 5:10 PM, Jeff Barnett wrote:
> On 6/22/2022 12:10 PM, olcott wrote:
>> On 6/22/2022 12:11 PM, Jeff Barnett wrote:
>>> On 6/21/2022 8:38 PM, olcott wrote:
>>>
>>> <SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
>>>
>>> Peter, you must first identify a competent Software Engineer to do
>>> said verification. There are two problems: The first is that no
>>> competent SE would verify your claims whether or not you shared your
>>> crap code with them. You don't certify a black box from the outside
>>> because there are too many simple errors that wont be caught.
>
>> My words are perfectly clear and correct thus leaving the only
>> possible rebuttal of changing the words and forming a rebuttal on the
>> basis of these changed words.
> Your words are not clear even to you. Are you really that stupid? Your
> not a Software Engineer, Computer Scientist, or a Programmer of even
> modest skills. Sorry. Your accomplishments here on USENET or on the job
> are of so trite a nature that no one of any accomplishments in these
> areas can allow you pollute newsgroup after newsgroup with the same
> repetitive dribble. I think you have invented the "E" version of the
> good old "cluster fuck". (That's one innovation you can put on your
> resume.)
>
>> Every sufficiently competent software engineer can easily verify that
>> the complete and correct x86 emulation of the input to H(P,P) by H
>> would never reach the "ret" instruction of P because both H and P
>> would remain stuck in infinitely recursive emulation.
>
> And that's the point. You are neither a competent Software Engineer nor
> one who can judge competence. Remember all those employers who told you
> the same thing.
>
>> After 100 reviewers in a dozen forums over a period of one year:
>> On 6/14/2022 6:47 AM, Paul N wrote:
>>  > Yes, it is clear to us humans watching
>>  > it that the program is repeating itself.
>>  > Thus we can appreciate that it will never
>>  > reach the final "ret" - indeed, it won't
>>  > even get to the infinite loop identified above.
>>
>> If H can determine that this is the case in a finite number of steps
>> then H could correctly reject its input on this basis.
>
> Let's give Paul N a little credit but not much; notice that he doesn't
> even understand the point of the exercise which is that the *same
> function* must be used for both inner and outer purposes.

You dishonestly snipped the part that proves that he does know this.

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

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

> On 6/22/2022 4:49 PM, Mr Flibble wrote:
> > On Wed, 22 Jun 2022 16:41:43 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/22/2022 4:20 PM, Mr Flibble wrote:
> >>> On Wed, 22 Jun 2022 15:27:01 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
> >>>>> On Tue, 21 Jun 2022 21:38:56 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> #include <stdint.h>
> >>>>>> #define u32 uint32_t
> >>>>>>
> >>>>>> #include <stdint.h>
> >>>>>> typedef void (*ptr)();
> >>>>>>
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>> }
> >>>>>>
> >>>>>> _P()
> >>>>>> [000010d2](01) 55 push ebp
> >>>>>> [000010d3](02) 8bec mov ebp,esp
> >>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [000010d8](01) 50 push eax
> >>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [000010dc](01) 51 push ecx
> >>>>>> [000010dd](05) e820feffff call 00000f02
> >>>>>> [000010e2](03) 83c408 add esp,+08
> >>>>>> [000010e5](02) 85c0 test eax,eax
> >>>>>> [000010e7](02) 7402 jz 000010eb
> >>>>>> [000010e9](02) ebfe jmp 000010e9
> >>>>>> [000010eb](01) 5d pop ebp
> >>>>>> [000010ec](01) c3 ret
> >>>>>> Size in bytes:(0027) [000010ec]
> >>>>>>
> >>>>>> Every sufficiently competent software engineer can easily
> >>>>>> verify that the complete and correct x86 emulation of the
> >>>>>> input to H(P,P) by H would never reach the "ret" instruction
> >>>>>> of P because both H and P would remain stuck in infinitely
> >>>>>> recursive emulation.
> >>>>>>
> >>>>>> If H does correctly determine that this is the case in a finite
> >>>>>> number of steps then H could reject its input on this basis.
> >>>>>> Here are the details of exactly how H does this in a finite
> >>>>>> number of steps.
> >>>>>>
> >>>>>> typedef struct Decoded
> >>>>>> {
> >>>>>> u32 Address;
> >>>>>> u32 ESP; // Current value of ESP
> >>>>>> u32 TOS; // Current value of Top of Stack
> >>>>>> u32 NumBytes;
> >>>>>> u32 Simplified_Opcode;
> >>>>>> u32 Decode_Target;
> >>>>>> } Decoded_Line_Of_Code;
> >>>>>>
> >>>>>> machine stack stack machine assembly
> >>>>>> address address data code language
> >>>>>> ======== ======== ======== ========= ============> >>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
> >>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
> >>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
> >>>>>> [000010d8][00211e86][000010d2] 50 push eax //
> >>>>>> push P [000010d9][00211e86][000010d2] 8b4d08 mov
> >>>>>> ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push
> >>>>>> ecx // push P [000010dd][00211e7e][000010e2] e820feffff
> >>>>>> call 00000f02 // call H Infinitely Recursive Simulation
> >>>>>> Detected Simulation Stopped
> >>>>>>
> >>>>>> // actual fully operational code in the x86utm operating system
> >>>>>> u32 H(u32 P, u32 I)
> >>>>>> {
> >>>>>> HERE:
> >>>>>> u32 End_Of_Code;
> >>>>>> u32 Address_of_H; // 2022-06-17
> >>>>>> u32 code_end = get_code_end(P);
> >>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
> >>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
> >>>>>> Registers* master_state = (Registers*)
> >>>>>> Allocate(sizeof(Registers));
> >>>>>> Registers* slave_state = (Registers*)
> >>>>>> Allocate(sizeof(Registers));
> >>>>>> u32* slave_stack = Allocate(0x10000); //
> >>>>>> 64k; u32 execution_trace > >>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
> >>>>>> * 1000);
> >>>>>>
> >>>>>> __asm lea eax, HERE // 2022-06-18
> >>>>>> __asm sub eax, 6 // 2022-06-18
> >>>>>> __asm mov Address_of_H, eax // 2022-06-18
> >>>>>> __asm mov eax, END_OF_CODE
> >>>>>> __asm mov End_Of_Code, eax
> >>>>>>
> >>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
> >>>>>> Init_slave_state(P, I, End_Of_Code, slave_state,
> >>>>>> slave_stack); Output("\nBegin Simulation Execution Trace
> >>>>>> Stored at:", execution_trace);
> >>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
> >>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
> >>>>>> goto END_OF_CODE;
> >>>>>> return 0; // Does not halt
> >>>>>> END_OF_CODE:
> >>>>>> return 1; // Input has normally terminated
> >>>>>> }
> >>>>>>
> >>>>>> H knows its own machine address and on this basis it can easily
> >>>>>> examine its stored execution_trace of P and determine:
> >>>>>> (a) P is calling H with the same arguments that H was called
> >>>>>> with. (b) No instructions in P could possibly escape this
> >>>>>> otherwise infinitely recursive emulation.
> >>>>>> (c) H aborts its emulation of P before its call to H is
> >>>>>> invoked.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Technically competent software engineers may not know this
> >>>>>> computer science:
> >>>>>>
> >>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>> accept or reject state on the basis of the actual behavior that
> >>>>>> is actually specified by these inputs.
> >>>>>>
> >>>>>> computation that halts … the Turing machine will halt whenever
> >>>>>> it enters a final state. (Linz:1990:234)
> >>>>>>
> >>>>>> The "ret" instruction of P is its final state.
> >>>>>>
> >>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
> >>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>>>
> >>>>>
> >>>>> void Px(u32 x)
> >>>>> {
> >>>>> H(x, x);
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>> }
> >>>>>
> >>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>> Input_Halts = 0
> >>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>> Number of Instructions Executed(16120)
> >>>>>
> >>>>> It gets the answer wrong, i.e. input has not been decided
> >>>>> correctly. QED.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> You and Richard are insufficiently technically competent at
> >>>> software engineering not meeting these specs:
> >>>>
> >>>> A software engineer must be an expert in: the C programming
> >>>> language, the x86 programming language, exactly how C translates
> >>>> into x86 and the ability to recognize infinite recursion at the
> >>>> x86 assembly language level. No knowledge of the halting problem
> >>>> is required.
> >>>
> >>> I cannot speak for Richard but I have 30+ years C++ experience; I
> >>> also have C and x86 assembly experience (I once wrote a Zilog Z80A
> >>> CPU emulator in 80286 assembly) and I can recognize an infinite
> >>> recursion; the problem is that you cannot recognize the fact that
> >>> the infinite recursion only manifests as part of your invalid
> >>> simulation-based omnishambles:
> >>
> >> If you are competent then you already know this is true and lie
> >> about it:
> >>
> >> Every sufficiently competent software engineer can easily verify
> >> that the complete and correct x86 emulation of the input to
> >> H(Px,Px) by H would never reach the "ret" instruction of P because
> >> both H and P would remain stuck in infinitely recursive emulation.
> >>
> >> Otherwise you are incompetent.
> >>
> >>> the recursion simply isn't there for a "valid" halt
> >>> decider, that being a halt decider that can return an answer in
> >>> finite time to ALL invokers: H needs to return an answer to Px to
> >>> be considered a valid halt decider.
> >>>
> >>> /Flibble
> >
> > Why did you ignore the second part? Again:
> >
> > The problem is that you cannot recognize the fact that the infinite
> > recursion only manifests as part of your invalid simulation-based
>
> It is easily provably correct. That you lack the technical competence
> to verify that the x86 emulated behavior of the x86 emulation of the
> input to H(P,P) by H precisely matches the behavior specified by P is
> far less than no rebuttal at all.

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.

Inputs are just strings, and as such don't have behaviors in and of
themselves.

If the behavior the decider sees doesn't match the behavior of the
machine the input is supposed to represent, then either the decider is
misdefined and is generating the wrong behavior, or the input wasn't
constructed properly.

In H(P,P) vs P(P), you have provided both the H and the input
representation, so if the input doesn't represent P(P), it is YOUR mistake.

If H can't be given an input to represents P(P), then H is defective and
not a counter example. If P giving H the wrong parameters, then you P is
defined wrong and not a counter example.

In short, sonce P(P) Halts when H(P,P) returns 0, then H(P,P) returning
0 is NOT a counter example to the halting problem. If somehow you want
to call it a correct answer, it is to the wrong question so doesn't
actually provide the counter example you claim.

You repeating this claim over and over just shows that you have no
understand of what you are talking about.

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.

On 6/22/22 1:58 PM, olcott wrote:
>
> My words are perfectly clear and correct thus leaving the only possible
> rebuttal of changing the words and forming a rebuttal on the basis of
> these changed words.

No, they aren't because they don't match the definitons of the problem
you claim to be working on.

Start with wrong definitions, and NOTHING that follows is valid. or correct.

H applied to M, x needs to accept this input if M applied to x reaches a
final state in a finite number of steps and reject this input if M
applied to x will NEVER, after an unbounded number of steps, reach a
final state.

Since when P applied to P uses H applied to P, P and then does the
opposite gets the reject answer from H it Halts, then H applied to P,P
rejecting this input can't be correct.

PERIOD.

DEFINITION.

The fact that you try to twist the requirements and definitions to try
to show something else, just proves that you are either dishonest or
ignorant.

You will NEVER be right, because your ideas are just WRONG.

On 6/22/2022 6:01 PM, Mr Flibble wrote:
> On Wed, 22 Jun 2022 16:58:24 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/22/2022 4:49 PM, Mr Flibble wrote:
>>> On Wed, 22 Jun 2022 16:41:43 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:
>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> #include <stdint.h>
>>>>>>>> #define u32 uint32_t
>>>>>>>>
>>>>>>>> #include <stdint.h>
>>>>>>>> typedef void (*ptr)();
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>> [000010d3](02) 8bec mov ebp,esp
>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [000010d8](01) 50 push eax
>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>> [000010eb](01) 5d pop ebp
>>>>>>>> [000010ec](01) c3 ret
>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>
>>>>>>>> Every sufficiently competent software engineer can easily
>>>>>>>> verify that the complete and correct x86 emulation of the
>>>>>>>> input to H(P,P) by H would never reach the "ret" instruction
>>>>>>>> of P because both H and P would remain stuck in infinitely
>>>>>>>> recursive emulation.
>>>>>>>>
>>>>>>>> If H does correctly determine that this is the case in a finite
>>>>>>>> number of steps then H could reject its input on this basis.
>>>>>>>> Here are the details of exactly how H does this in a finite
>>>>>>>> number of steps.
>>>>>>>>
>>>>>>>> typedef struct Decoded
>>>>>>>> {
>>>>>>>> u32 Address;
>>>>>>>> u32 ESP; // Current value of ESP
>>>>>>>> u32 TOS; // Current value of Top of Stack
>>>>>>>> u32 NumBytes;
>>>>>>>> u32 Simplified_Opcode;
>>>>>>>> u32 Decode_Target;
>>>>>>>> } Decoded_Line_Of_Code;
>>>>>>>>
>>>>>>>> machine stack stack machine assembly
>>>>>>>> address address data code language
>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>> [000010d2][00211e8a][00211e8e] 55 push ebp
>>>>>>>> [000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
>>>>>>>> [000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
>>>>>>>> [000010d8][00211e86][000010d2] 50 push eax //
>>>>>>>> push P [000010d9][00211e86][000010d2] 8b4d08 mov
>>>>>>>> ecx,[ebp+08] [000010dc][00211e82][000010d2] 51 push
>>>>>>>> ecx // push P [000010dd][00211e7e][000010e2] e820feffff
>>>>>>>> call 00000f02 // call H Infinitely Recursive Simulation
>>>>>>>> Detected Simulation Stopped
>>>>>>>>
>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>> {
>>>>>>>> HERE:
>>>>>>>> u32 End_Of_Code;
>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>> u32* slave_stack = Allocate(0x10000); //
>>>>>>>> 64k; u32 execution_trace =
>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>> * 1000);
>>>>>>>>
>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>
>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state,
>>>>>>>> slave_stack); Output("\nBegin Simulation Execution Trace
>>>>>>>> Stored at:", execution_trace);
>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>> goto END_OF_CODE;
>>>>>>>> return 0; // Does not halt
>>>>>>>> END_OF_CODE:
>>>>>>>> return 1; // Input has normally terminated
>>>>>>>> }
>>>>>>>>
>>>>>>>> H knows its own machine address and on this basis it can easily
>>>>>>>> examine its stored execution_trace of P and determine:
>>>>>>>> (a) P is calling H with the same arguments that H was called
>>>>>>>> with. (b) No instructions in P could possibly escape this
>>>>>>>> otherwise infinitely recursive emulation.
>>>>>>>> (c) H aborts its emulation of P before its call to H is
>>>>>>>> invoked.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Technically competent software engineers may not know this
>>>>>>>> computer science:
>>>>>>>>
>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>> accept or reject state on the basis of the actual behavior that
>>>>>>>> is actually specified by these inputs.
>>>>>>>>
>>>>>>>> computation that halts … the Turing machine will halt whenever
>>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>>
>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>
>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>
>>>>>>>
>>>>>>> void Px(u32 x)
>>>>>>> {
>>>>>>> H(x, x);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>> }
>>>>>>>
>>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>>> Input_Halts = 0
>>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>>> Number of Instructions Executed(16120)
>>>>>>>
>>>>>>> It gets the answer wrong, i.e. input has not been decided
>>>>>>> correctly. QED.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> You and Richard are insufficiently technically competent at
>>>>>> software engineering not meeting these specs:
>>>>>>
>>>>>> A software engineer must be an expert in: the C programming
>>>>>> language, the x86 programming language, exactly how C translates
>>>>>> into x86 and the ability to recognize infinite recursion at the
>>>>>> x86 assembly language level. No knowledge of the halting problem
>>>>>> is required.
>>>>>
>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I
>>>>> also have C and x86 assembly experience (I once wrote a Zilog Z80A
>>>>> CPU emulator in 80286 assembly) and I can recognize an infinite
>>>>> recursion; the problem is that you cannot recognize the fact that
>>>>> the infinite recursion only manifests as part of your invalid
>>>>> simulation-based omnishambles:
>>>>
>>>> If you are competent then you already know this is true and lie
>>>> about it:
>>>>
>>>> Every sufficiently competent software engineer can easily verify
>>>> that the complete and correct x86 emulation of the input to
>>>> H(Px,Px) by H would never reach the "ret" instruction of P because
>>>> both H and P would remain stuck in infinitely recursive emulation.
>>>>
>>>> Otherwise you are incompetent.
>>>>
>>>>> the recursion simply isn't there for a "valid" halt
>>>>> decider, that being a halt decider that can return an answer in
>>>>> finite time to ALL invokers: H needs to return an answer to Px to
>>>>> be considered a valid halt decider.
>>>>>
>>>>> /Flibble
>>>
>>> Why did you ignore the second part? Again:
>>>
>>> The problem is that you cannot recognize the fact that the infinite
>>> recursion only manifests as part of your invalid simulation-based
>>
>> It is easily provably correct. That you lack the technical competence
>> to verify that the x86 emulated behavior of the x86 emulation of the
>> input to H(P,P) by H precisely matches the behavior specified by P is
>> far less than no rebuttal at all.
>
> Your H doesn't return a value to its invoker, Px in this case, so isn't
> a valid halt decider.

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.

People that actually understand these things deeply on the basis of all
of the deep connected meanings will agree. People that understand these
things only by the rote memorization of what textbooks say may get
confused.

This is computer science that I wrote that is verifiably correct and
clarifies the misconceptions of what a halt decider must do:

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. Copyright Olcott 2021

--
Copyright 2022 Pete Olcott

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

On 6/22/2022 6:11 PM, Richard Damon wrote:
> On 6/22/22 1:58 PM, olcott wrote:
>>
>> My words are perfectly clear and correct thus leaving the only
>> possible rebuttal of changing the words and forming a rebuttal on the
>> basis of these changed words.
>
> No, they aren't because they don't match the definitons of the problem
> you claim to be working on.

That is an entirely separate issue that cannot possibly be correctly
addressed until after my words are totally agreed to in the precise
context that they are specified.

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

DEFINITIONS, you know.

>
> People that actually understand these things deeply on the basis of all
> of the deep connected meanings will agree. People that understand these
> things only by the rote memorization of what textbooks say may get
> confused.
>
> This is computer science that I wrote that is verifiably correct and
> clarifies the misconceptions of what a halt decider must do:
>
> 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. Copyright Olcott 2021
>

Which isn't correct unless that actual behavior matches that defined by
the definition of an ACTUAL Halt Decider, which is the behavior of the
machine the input represents.

You don't get to change definitions.

Note, you also don't get to copyright definitions, just your artistic
representation of them.

I guess due to your degree of artistic license you take with
definitions, you might be able to claim copyright on your versions.

After all, they are a work of fiction. (maybe just semi-fiction).

On 6/22/22 8:00 PM, olcott wrote:
> On 6/22/2022 6:11 PM, Richard Damon wrote:
>> On 6/22/22 1:58 PM, olcott wrote:
>>>
>>> My words are perfectly clear and correct thus leaving the only
>>> possible rebuttal of changing the words and forming a rebuttal on the
>>> basis of these changed words.
>>
>> No, they aren't because they don't match the definitons of the problem
>> you claim to be working on.
>
> That is an entirely separate issue that cannot possibly be correctly
> addressed until after my words are totally agreed to in the precise
> context that they are specified.
>

If you start with the wrong definitions, why do people need (or even
want to) agree with them.

Your whole argument STARTS with a misunderstanding of the basic terms,
therefore the full thing is just garbage.

I wll note, that when you get ready to try to publish, the FIRST thing
that the publisher is going to want to see is your list of refences for
where you get your basics from.

The fact that they are just your own misunderstanding of the
fundamentals means you are going to get a foot into the door.

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.

--
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 4:27 PM, olcott wrote:
> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>> On Tue, 21 Jun 2022 21:38:56 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>>     if (H(x, x))
>>>       HERE: goto HERE;
>>>     return;
>>> }
>>>
>>> int main()
>>> {
>>>     Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [000010d2](01)  55              push ebp
>>> [000010d3](02)  8bec            mov ebp,esp
>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>> [000010d8](01)  50              push eax
>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>> [000010dc](01)  51              push ecx
>>> [000010dd](05)  e820feffff      call 00000f02
>>> [000010e2](03)  83c408          add esp,+08
>>> [000010e5](02)  85c0            test eax,eax
>>> [000010e7](02)  7402            jz 000010eb
>>> [000010e9](02)  ebfe            jmp 000010e9
>>> [000010eb](01)  5d              pop ebp
>>> [000010ec](01)  c3              ret
>>> Size in bytes:(0027) [000010ec]
>>>
>>> Every sufficiently competent software engineer can easily verify that
>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>> would never reach the "ret" instruction of P because both H and P
>>> would remain stuck in infinitely recursive emulation.
>>>
>>> If H does correctly determine that this is the case in a finite
>>> number of steps then H could reject its input on this basis. Here are
>>> the details of exactly how H does this in a finite number of steps.
>>>
>>> typedef struct Decoded
>>> {
>>>     u32 Address;
>>>     u32 ESP;          // Current value of ESP
>>>     u32 TOS;          // Current value of Top of Stack
>>>     u32 NumBytes;
>>>     u32 Simplified_Opcode;
>>>     u32 Decode_Target;
>>> } Decoded_Line_Of_Code;
>>>
>>>    machine   stack     stack     machine    assembly
>>>    address   address   data      code       language
>>>    ========  ========  ========  =========  =============
>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> // actual fully operational code in the x86utm operating system
>>> u32 H(u32 P, u32 I)
>>> {
>>> HERE:
>>>     u32 End_Of_Code;
>>>     u32 Address_of_H;              // 2022-06-17
>>>     u32 code_end                  = get_code_end(P);
>>>     Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>     Registers*  master_state      = (Registers*)
>>> Allocate(sizeof(Registers));
>>>     Registers*  slave_state       = (Registers*)
>>> Allocate(sizeof(Registers));
>>>     u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>     u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>> * 1000);
>>>
>>>     __asm lea eax, HERE             // 2022-06-18
>>>     __asm sub eax, 6                // 2022-06-18
>>>     __asm mov Address_of_H, eax     // 2022-06-18
>>>     __asm mov eax, END_OF_CODE
>>>     __asm mov End_Of_Code, eax
>>>
>>>     Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>     Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>     Output("\nBegin Simulation   Execution Trace Stored at:",
>>> execution_trace);
>>>     if (Decide_Halting(&execution_trace, &decoded, code_end,
>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>         goto END_OF_CODE;
>>>     return 0;  // Does not halt
>>> END_OF_CODE:
>>>     return 1; // Input has normally terminated
>>> }
>>>
>>> H knows its own machine address and on this basis it can easily
>>> examine its stored execution_trace of P and determine:
>>> (a) P is calling H with the same arguments that H was called with.
>>> (b) No instructions in P could possibly escape this otherwise
>>> infinitely recursive emulation.
>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>
>>>
>>>
>>>
>>> Technically competent software engineers may not know this computer
>>> science:
>>>
>>> A halt decider must compute the mapping from its inputs to an accept
>>> or reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> The "ret" instruction of P is its final state.
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>
>>
>> void Px(u32 x)
>> {
>>     H(x, x);
>>     return;
>> }
>>
>> int main()
>> {
>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>> }
>>
>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>> ...[000013eb][00102353][00000000] 50              push eax
>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>> Input_Halts = 0
>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>> ...[000013fc][0010235f][00000004] c3              ret
>> Number of Instructions Executed(16120)
>>
>> It gets the answer wrong, i.e. input has not been decided correctly.
>> QED.
>>
>> /Flibble
>>
>
> You and Richard are insufficiently technically competent at software
> engineering not meeting these specs:
>
> A software engineer must be an expert in: the C programming language,
> the x86 programming language, exactly how C translates into x86 and the
> ability to recognize infinite recursion at the x86 assembly language
> level. No knowledge of the halting problem is required.
>
>

Except that I am probably at least as much of an expert on those fields
as you are. My one problem is that I do have knowledge of the halting
problem, that seems to make me resistant to your lies.

You might have more experiance with x86, but only because I work on a
number of different architectures, but your argument really isn't x86
specific, that is just the case you are working in.

(I was producing 'production' assembly routines 50 years ago, so I have
seen a number of different types of machines)

On 6/22/2022 7:25 PM, Richard Damon wrote:
> On 6/22/22 8:00 PM, olcott wrote:
>> On 6/22/2022 6:11 PM, Richard Damon wrote:
>>> On 6/22/22 1:58 PM, olcott wrote:
>>>>
>>>> My words are perfectly clear and correct thus leaving the only
>>>> possible rebuttal of changing the words and forming a rebuttal on
>>>> the basis of these changed words.
>>>
>>> No, they aren't because they don't match the definitons of the
>>> problem you claim to be working on.
>>
>> That is an entirely separate issue that cannot possibly be correctly
>> addressed until after my words are totally agreed to in the precise
>> context that they are specified.
>>
>
> If you start with the wrong definitions, why do people need (or even
> want to) agree with them.
>

First you agree that my words are perfectly correct within their
specified context then after this we can proceed with your objection
that they do not meet the definitions.

It is required that we have incremental closure on sub-points or full
closure will be impossible to achieve.

--
Copyright 2022 Pete Olcott

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

On 6/22/2022 7:32 PM, Richard Damon wrote:
> On 6/22/22 4:27 PM, olcott wrote:
>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> void P(ptr x)
>>>> {
>>>>     if (H(x, x))
>>>>       HERE: goto HERE;
>>>>     return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> _P()
>>>> [000010d2](01)  55              push ebp
>>>> [000010d3](02)  8bec            mov ebp,esp
>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>> [000010d8](01)  50              push eax
>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>> [000010dc](01)  51              push ecx
>>>> [000010dd](05)  e820feffff      call 00000f02
>>>> [000010e2](03)  83c408          add esp,+08
>>>> [000010e5](02)  85c0            test eax,eax
>>>> [000010e7](02)  7402            jz 000010eb
>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>> [000010eb](01)  5d              pop ebp
>>>> [000010ec](01)  c3              ret
>>>> Size in bytes:(0027) [000010ec]
>>>>
>>>> Every sufficiently competent software engineer can easily verify that
>>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>>> would never reach the "ret" instruction of P because both H and P
>>>> would remain stuck in infinitely recursive emulation.
>>>>
>>>> If H does correctly determine that this is the case in a finite
>>>> number of steps then H could reject its input on this basis. Here are
>>>> the details of exactly how H does this in a finite number of steps.
>>>>
>>>> typedef struct Decoded
>>>> {
>>>>     u32 Address;
>>>>     u32 ESP;          // Current value of ESP
>>>>     u32 TOS;          // Current value of Top of Stack
>>>>     u32 NumBytes;
>>>>     u32 Simplified_Opcode;
>>>>     u32 Decode_Target;
>>>> } Decoded_Line_Of_Code;
>>>>
>>>>    machine   stack     stack     machine    assembly
>>>>    address   address   data      code       language
>>>>    ========  ========  ========  =========  =============
>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> // actual fully operational code in the x86utm operating system
>>>> u32 H(u32 P, u32 I)
>>>> {
>>>> HERE:
>>>>     u32 End_Of_Code;
>>>>     u32 Address_of_H;              // 2022-06-17
>>>>     u32 code_end                  = get_code_end(P);
>>>>     Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>     Registers*  master_state      = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>     Registers*  slave_state       = (Registers*)
>>>> Allocate(sizeof(Registers));
>>>>     u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>     u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>> * 1000);
>>>>
>>>>     __asm lea eax, HERE             // 2022-06-18
>>>>     __asm sub eax, 6                // 2022-06-18
>>>>     __asm mov Address_of_H, eax     // 2022-06-18
>>>>     __asm mov eax, END_OF_CODE
>>>>     __asm mov End_Of_Code, eax
>>>>
>>>>     Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>     Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>     Output("\nBegin Simulation   Execution Trace Stored at:",
>>>> execution_trace);
>>>>     if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>         goto END_OF_CODE;
>>>>     return 0;  // Does not halt
>>>> END_OF_CODE:
>>>>     return 1; // Input has normally terminated
>>>> }
>>>>
>>>> H knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of P and determine:
>>>> (a) P is calling H with the same arguments that H was called with.
>>>> (b) No instructions in P could possibly escape this otherwise
>>>> infinitely recursive emulation.
>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>
>>>>
>>>>
>>>>
>>>> Technically competent software engineers may not know this computer
>>>> science:
>>>>
>>>> A halt decider must compute the mapping from its inputs to an accept
>>>> or reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>>
>>>> computation that halts … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> The "ret" instruction of P is its final state.
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>
>>>
>>> void Px(u32 x)
>>> {
>>>     H(x, x);
>>>     return;
>>> }
>>>
>>> int main()
>>> {
>>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>> }
>>>
>>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>>> ...[000013eb][00102353][00000000] 50              push eax
>>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>>> Input_Halts = 0
>>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>>> ...[000013fc][0010235f][00000004] c3              ret
>>> Number of Instructions Executed(16120)
>>>
>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>> QED.
>>>
>>> /Flibble
>>>
>>
>> You and Richard are insufficiently technically competent at software
>> engineering not meeting these specs:
>>
>> A software engineer must be an expert in: the C programming language,
>> the x86 programming language, exactly how C translates into x86 and
>> the ability to recognize infinite recursion at the x86 assembly
>> language level. No knowledge of the halting problem is required.
>>
>>
>
> Except that I am probably at least as much of an expert on those fields
> as you are. My one problem is that I do have knowledge of the halting
> problem, that seems to make me resistant to your lies.
>
> You might have more experiance with x86, but only because I work on a
> number of different architectures, but your argument really isn't x86
> specific, that is just the case you are working in.
>
> (I was producing 'production' assembly routines 50 years ago, so I have
> seen a number of different types of machines)

On 6/22/22 8:37 PM, olcott wrote:
> On 6/22/2022 7:32 PM, Richard Damon wrote:
>> On 6/22/22 4:27 PM, olcott wrote:
>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [000010d2](01)  55              push ebp
>>>>> [000010d3](02)  8bec            mov ebp,esp
>>>>> [000010d5](03)  8b4508          mov eax,[ebp+08]
>>>>> [000010d8](01)  50              push eax
>>>>> [000010d9](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [000010dc](01)  51              push ecx
>>>>> [000010dd](05)  e820feffff      call 00000f02
>>>>> [000010e2](03)  83c408          add esp,+08
>>>>> [000010e5](02)  85c0            test eax,eax
>>>>> [000010e7](02)  7402            jz 000010eb
>>>>> [000010e9](02)  ebfe            jmp 000010e9
>>>>> [000010eb](01)  5d              pop ebp
>>>>> [000010ec](01)  c3              ret
>>>>> Size in bytes:(0027) [000010ec]
>>>>>
>>>>> Every sufficiently competent software engineer can easily verify that
>>>>> the complete and correct x86 emulation of the input to H(P,P) by H
>>>>> would never reach the "ret" instruction of P because both H and P
>>>>> would remain stuck in infinitely recursive emulation.
>>>>>
>>>>> If H does correctly determine that this is the case in a finite
>>>>> number of steps then H could reject its input on this basis. Here are
>>>>> the details of exactly how H does this in a finite number of steps.
>>>>>
>>>>> typedef struct Decoded
>>>>> {
>>>>>     u32 Address;
>>>>>     u32 ESP;          // Current value of ESP
>>>>>     u32 TOS;          // Current value of Top of Stack
>>>>>     u32 NumBytes;
>>>>>     u32 Simplified_Opcode;
>>>>>     u32 Decode_Target;
>>>>> } Decoded_Line_Of_Code;
>>>>>
>>>>>    machine   stack     stack     machine    assembly
>>>>>    address   address   data      code       language
>>>>>    ========  ========  ========  =========  =============
>>>>> [000010d2][00211e8a][00211e8e] 55         push ebp
>>>>> [000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
>>>>> [000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
>>>>> [000010d8][00211e86][000010d2] 50         push eax        // push P
>>>>> [000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
>>>>> [000010dc][00211e82][000010d2] 51         push ecx        // push P
>>>>> [000010dd][00211e7e][000010e2] e820feffff call 00000f02   // call H
>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> // actual fully operational code in the x86utm operating system
>>>>> u32 H(u32 P, u32 I)
>>>>> {
>>>>> HERE:
>>>>>     u32 End_Of_Code;
>>>>>     u32 Address_of_H;              // 2022-06-17
>>>>>     u32 code_end                  = get_code_end(P);
>>>>>     Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>     Registers*  master_state      = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>     Registers*  slave_state       = (Registers*)
>>>>> Allocate(sizeof(Registers));
>>>>>     u32*        slave_stack       = Allocate(0x10000); // 64k;
>>>>>     u32  execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>> * 1000);
>>>>>
>>>>>     __asm lea eax, HERE             // 2022-06-18
>>>>>     __asm sub eax, 6                // 2022-06-18
>>>>>     __asm mov Address_of_H, eax     // 2022-06-18
>>>>>     __asm mov eax, END_OF_CODE
>>>>>     __asm mov End_Of_Code, eax
>>>>>
>>>>>     Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>     Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
>>>>>     Output("\nBegin Simulation   Execution Trace Stored at:",
>>>>> execution_trace);
>>>>>     if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>         goto END_OF_CODE;
>>>>>     return 0;  // Does not halt
>>>>> END_OF_CODE:
>>>>>     return 1; // Input has normally terminated
>>>>> }
>>>>>
>>>>> H knows its own machine address and on this basis it can easily
>>>>> examine its stored execution_trace of P and determine:
>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>> infinitely recursive emulation.
>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Technically competent software engineers may not know this computer
>>>>> science:
>>>>>
>>>>> A halt decider must compute the mapping from its inputs to an accept
>>>>> or reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>>
>>>>> computation that halts … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> The "ret" instruction of P is its final state.
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>
>>>>
>>>> void Px(u32 x)
>>>> {
>>>>     H(x, x);
>>>>     return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>> }
>>>>
>>>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>>>> ...[000013eb][00102353][00000000] 50              push eax
>>>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>>>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>>>> Input_Halts = 0
>>>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>>>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>>>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>>>> ...[000013fc][0010235f][00000004] c3              ret
>>>> Number of Instructions Executed(16120)
>>>>
>>>> It gets the answer wrong, i.e. input has not been decided correctly.
>>>> QED.
>>>>
>>>> /Flibble
>>>>
>>>
>>> You and Richard are insufficiently technically competent at software
>>> engineering not meeting these specs:
>>>
>>> A software engineer must be an expert in: the C programming language,
>>> the x86 programming language, exactly how C translates into x86 and
>>> the ability to recognize infinite recursion at the x86 assembly
>>> language level. No knowledge of the halting problem is required.
>>>
>>>
>>
>> Except that I am probably at least as much of an expert on those
>> fields as you are. My one problem is that I do have knowledge of the
>> halting problem, that seems to make me resistant to your lies.
>>
>> You might have more experiance with x86, but only because I work on a
>> number of different architectures, but your argument really isn't x86
>> specific, that is just the case you are working in.
>>
>> (I was producing 'production' assembly routines 50 years ago, so I
>> have seen a number of different types of machines)
>
> First you agree that my words are perfectly correct within their
> specified context

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. You know state the established basis in the field that
you start your argument from, and the step by step logic to get to that
answer.

Be prepared to give sources for your claimed "established basises".

Since for the Halting Problem, it is definitional, this will be hard to do.

It may well be that YOUR H shows a different behavior, but that just
shows it isn't actually a Halt Decider.

Remember the Definition:

H applied to M, w must accept if M applied to x halts in a finite number
of steps, and reject if M applied to x will not halt even when taken to
an unbounded number of steps.

DEFINITION.

H^ / P is DEFINED in the Linz proof to be asking H about P applied to
its own input.

Thus if P uses H applied to P, P, then for P to have been built
correctly, that input must refer to P applied to P.

Thus if P(P) isn't what H(P,P) is actually asking about, then either H
or P has been not defined correctly.

YOU FAIL.

You can't claim conformance to the requirements of the proof you are
countering and have H(P,P) not be looking at the behavor of P(P).

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

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.

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.

--
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 8:34 PM, olcott wrote:
> On 6/22/2022 7:25 PM, Richard Damon wrote:
>> On 6/22/22 8:00 PM, olcott wrote:
>>> On 6/22/2022 6:11 PM, Richard Damon wrote:
>>>> On 6/22/22 1:58 PM, olcott wrote:
>>>>>
>>>>> My words are perfectly clear and correct thus leaving the only
>>>>> possible rebuttal of changing the words and forming a rebuttal on
>>>>> the basis of these changed words.
>>>>
>>>> No, they aren't because they don't match the definitons of the
>>>> problem you claim to be working on.
>>>
>>> That is an entirely separate issue that cannot possibly be correctly
>>> addressed until after my words are totally agreed to in the precise
>>> context that they are specified.
>>>
>>
>> If you start with the wrong definitions, why do people need (or even
>> want to) agree with them.
>>
>
> First you agree that my words are perfectly correct within their
> specified context then after this we can proceed with your objection
> that they do not meet the definitions.
>
> It is required that we have incremental closure on sub-points or full
> closure will be impossible to achieve.
>
>

I will not agree that Falshoods are correct.

IF you make that a precondition, you might as well give up.

The Journal reviews will not accept that either.

You need to break down your first points to show that they actually are
correct. This will require you to CLEARLY define your terms in terms of
what the standard theory uses.

You are hamstringing yourself by moving away from the simplicity of
Turing Macines into stored program machines, as you are going to first
need to show that you can actually properly express the problem in that
space.

Note, the "C Function" P that you show, by itself, is not something that
Computation Theory talks much about, as it doesn't express a complete
algorithm without a PROPER definition of H.

You clearly don't know the field well enough to provide that, since you
haven't yet.

An ACTUAL source code of H, and everything it calls, would be such a
definition, PROVIDED that code obeys the requriements of being a
computation (which is close to, but not identical to, a 'Pure Function'
that you have been talking about).

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

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.

Your repeating it, without showing a source that claims it, or some
proof that it is correct, just proves that you are mentally incapable of
doing the task.

FAIL.

You appear to have gaslighted yourself into believing you own lies, or
are just a blatant patholgical liar.

If this is the best you have, you need to just give up and accept that
you are NEVER going to be able to establish your false claims to any
level of acceptance.

You might be able to fool a few people, but they are almost certainly
going to realize their error and snap out of it.

Hopefull, some day, you will to.

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.