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

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

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

I already fully addressed that in my reply to you yesterday. P(P) has a
dependency relationship on the return value of H(P,P) that the correctly
emulated input to H(P,P) does not have. This changes their behavior
relative to each other.

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

So, Since the behavior of P(P) depends on H, when you change the behavor
of H, you have invaldated anything you have learned about P.

Thus changing H from doing a pure complete and correct emulation of its
input to one that Halt decides it an no longer does a complete emulation
of it, you now have a DIFFERENT P, even though you didn't touch the
source code of the C function P.

The CORRECTLY emulated input to H(P,P), being the representation of the
computation P(P) has exactly that same dependency.

Rememember, P has been defined to be the Linz "impossible program",
which is DEFINED to ask H about itself applied to its input, so if
H(P,P) doesn't refer to P(P), then your P isn't the required function.

FAIL.

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

The provably correct execution trace proves that the complete and
correct x86 emulation of the input to H(P,P) by H would never reach the
"ret" instruction (final state) of P, thus never halts. It is also
proven that H does determine this in a finite number of states.

The provably correct execution trace of P(P) proves that the it halts.

Because it is a fact that the actual input to H(P,P) has actual behavior
that never halts then H must report on this behavior and cannot report
on any other behavior.

If you need to verify that you have a white dog in your living room
checking for a black cat in you kitchen is the wrong criteria.

If you need to verify that an input to a halt decider reaches its final
state it must be the actual behavior of this actual input. P(P) is
provably not the actual behavior of the actual input on the basis of the
ordinary semantics of the x86 language as shown in the two provably
correct execution traces.

To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.

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

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

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

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

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

int main()
{ P(P);
}

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

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

To what exact extent do you have this mandatory prerequisite knowledge?

To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.

The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This
file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.

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

No, it doesn't because you don't seem to understand what correct x86
emulation MEANS.

Correct x86 emulation of a call instruction means the emulation now
continues at the x86 instruction at the target of the call, and thus the
correct x86 emualtion of the call H needs to be followed by the
emulation of the actual x86 assembly code of H. PERIOD.

What you are doing ISN'T x86 emulation at all, so all you are doing is
showing you are a liar.

Now, maybe part of the problem is that H isn't a halt decider and the
input 'P' isn't actually a description of the computation of P to be
decided on, so the 'behavior' of that input isn't the same as P(P) but
then you are just shown to be lying that you are working on the halting
problem and have defined H and P per the theorem you are claiming to be
working on.

Note, to actually define the input as a representation of the
computation P. it needs to include the x86 assembly of H as part of it,
so the fact that you say it doesn't just says your emulator is not
actually doing a correct emulation of its input at all.
>
> The provably correct execution trace of P(P) proves that the it halts.
>
> Because it is a fact that the actual input to H(P,P) has actual behavior
> that never halts then H must report on this behavior and cannot report
> on any other behavior.
>

On 6/24/2022 11:09 AM, Malcolm McLean wrote:
> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>>> ever before.
>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>>
>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>>
>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>>
>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>
>>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>>> has rather far-reaching consequences.
>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>>> what's going on.
>>>>>>>>
>>>>>>> I'm a scientists, not a mathematician.
>>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>>> body temperature, and so on.
>>>>>>>
>>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>>
>>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>>
>>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>>> energy must be incorrect?
>>>>>>>
>>>>>>> The third is what PO is doing.
>>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>> with any established facts in anything he is doing.
>>>>>>
>>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>
>>>>> So something odd is going on there that needs an explanation.
>>>>
>>>> I already fully addressed that in my reply to you yesterday. P(P) has a
>>>> dependency relationship on the return value of H(P,P) that the correctly
>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>> relative to each other.
>>>>
>>> I can see an alternative explanation. I was going to say "it is obvious" but
>>> no-one else has stepped in to point it out. Maybe because it's too obvious
>>> and they want to give other posters a chance.
>> To what exact extent do you have this mandatory prerequisite knowledge?
>> To fully understand this code a software engineer must be an expert in:
>> the C programming language, the x86 programming language, exactly how C
>> translates into x86 and the ability to recognize infinite recursion at
>> the x86 assembly language level.
>> The ordinary semantics of standard C and the conventional x86 language
>> are the entire semantics required to conclusively prove that H(P,P) does
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction of P.
>> The halt decider and its input are written in C compiled with a
>> Microsoft C compiler that generates a standard COFF object file. This
>> file is the input to the x86utm operating system that runs on both
>> Microsoft Windows and Linux.
>>
> I'm a C programmer and I have done machine code programming, though not
> with the x86 chip. But I'd dispute your requirements.

THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
DISAGREEMENT IS INHERENTLY INCORRECT.

From a purely software engineering perspective H is correctly defined
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it
is proven that H does do this correctly in a finite number of steps.

> To re-tread the analogy,
> our measurements show that tigers use more energy than they take in.
> Now you could construct an very complicated explanation for that using
> advanced quantum mechanics and other concepts. And you do need to have
> a rudimentary understanding of physics to see where the difficulty lies.

> But you don't need more than the rudimentary understanding to suggest the
> alternative explanation, and to realise that it is overwhelmingly more likely.

It seems that you may be saying that it is OK to disbelieve verified
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.

On 6/24/22 12:32 PM, olcott wrote:
> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
>> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>> Linz and others were aware that: A halt decider must
>>>>>>>>>>>>> compute the mapping
>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis
>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>>>>> unaware of
>>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or
>>>>>>>>>>>>>> H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>> halt decider H
>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that
>>>>>>>>>>>> H is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>> That "the
>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to
>>>>>>>>>>>> a simulating
>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>> these inputs"?
>>>>>>>>>>>
>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>
>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>> You've
>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>>>> explanation
>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>> There is only one explanation. What you call the "dry-run" is
>>>>>>>>> not that
>>>>>>>>> same as the P(P). We've known this since the "line 15 commented
>>>>>>>>> out"
>>>>>>>>> days. There are two computations -- one that is not stopped and
>>>>>>>>> one
>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the
>>>>>>>>> input to
>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that
>>>>>>>>> hide
>>>>>>>>> what's going on.
>>>>>>>>>
>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>> The example I always use is that you are doing an energy budget
>>>>>>>> for tigers.
>>>>>>>> You work how much they use on running about, lactating,
>>>>>>>> maintaining their
>>>>>>>> body temperature, and so on.
>>>>>>>>
>>>>>>>> Now let's say that you find that all results are within a few
>>>>>>>> percentage points
>>>>>>>> of a similar budget done for lions. You'd instantly accept this
>>>>>>>> data.
>>>>>>>>
>>>>>>>> Now let's say that the results are wildly different from a
>>>>>>>> previous budget done
>>>>>>>> for lions. You wouldn't just accept that data. You'd check.
>>>>>>>> You'd want to
>>>>>>>> understand the reasons tigers spend far less energy on movement
>>>>>>>> than lions.
>>>>>>>>
>>>>>>>> Now let's say that the result show that tigers use more energy
>>>>>>>> than they
>>>>>>>> take in food. Would you instantly conclude that the law of
>>>>>>>> conservation of
>>>>>>>> energy must be incorrect?
>>>>>>>>
>>>>>>>> The third is what PO is doing.
>>>>>>> I have no idea what parts of this analogy map to the current
>>>>>>> situation.
>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>> with any established facts in anything he is doing.
>>>>>>>
>>>>>> He's dry-run P(P) and established that it doesn't halt. He's
>>>>>> invoked H on it
>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>
>>>>>> So something odd is going on there that needs an explanation.
>>>>>
>>>>> I already fully addressed that in my reply to you yesterday. P(P)
>>>>> has a
>>>>> dependency relationship on the return value of H(P,P) that the
>>>>> correctly
>>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>>> relative to each other.
>>>>>
>>>> I can see an alternative explanation. I was going to say "it is
>>>> obvious" but
>>>> no-one else has stepped in to point it out. Maybe because it's too
>>>> obvious
>>>> and they want to give other posters a chance.
>>> To what exact extent do you have this mandatory prerequisite knowledge?
>>> To fully understand this code a software engineer must be an expert in:
>>> the C programming language, the x86 programming language, exactly how C
>>> translates into x86 and the ability to recognize infinite recursion at
>>> the x86 assembly language level.
>>> The ordinary semantics of standard C and the conventional x86 language
>>> are the entire semantics required to conclusively prove that H(P,P) does
>>> correctly determine that its correct and complete x86 emulation of its
>>> input would never reach the "ret" instruction of P.
>>> The halt decider and its input are written in C compiled with a
>>> Microsoft C compiler that generates a standard COFF object file. This
>>> file is the input to the x86utm operating system that runs on both
>>> Microsoft Windows and Linux.
>>>
>> I'm a C programmer and I have done machine code programming, though not
>> with the x86 chip. But I'd dispute your requirements.
>
>
> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
> DISAGREEMENT IS INHERENTLY INCORRECT.
>
> From a purely software engineering perspective H is correctly defined
> to correctly determine that its correct and complete x86 emulation of
> its input would never reach the "ret" instruction of this input and it
> is proven that H does do this correctly in a finite number of steps.

On 6/24/2022 11:32 AM, olcott wrote:
> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
>> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>> Linz and others were aware that: A halt decider must
>>>>>>>>>>>>> compute the mapping
>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis
>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>>>>> unaware of
>>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or
>>>>>>>>>>>>>> H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>> halt decider H
>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that
>>>>>>>>>>>> H is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>> That "the
>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to
>>>>>>>>>>>> a simulating
>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>> these inputs"?
>>>>>>>>>>>
>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>
>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>> You've
>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>>>> explanation
>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>> There is only one explanation. What you call the "dry-run" is
>>>>>>>>> not that
>>>>>>>>> same as the P(P). We've known this since the "line 15 commented
>>>>>>>>> out"
>>>>>>>>> days. There are two computations -- one that is not stopped and
>>>>>>>>> one
>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the
>>>>>>>>> input to
>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that
>>>>>>>>> hide
>>>>>>>>> what's going on.
>>>>>>>>>
>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>> The example I always use is that you are doing an energy budget
>>>>>>>> for tigers.
>>>>>>>> You work how much they use on running about, lactating,
>>>>>>>> maintaining their
>>>>>>>> body temperature, and so on.
>>>>>>>>
>>>>>>>> Now let's say that you find that all results are within a few
>>>>>>>> percentage points
>>>>>>>> of a similar budget done for lions. You'd instantly accept this
>>>>>>>> data.
>>>>>>>>
>>>>>>>> Now let's say that the results are wildly different from a
>>>>>>>> previous budget done
>>>>>>>> for lions. You wouldn't just accept that data. You'd check.
>>>>>>>> You'd want to
>>>>>>>> understand the reasons tigers spend far less energy on movement
>>>>>>>> than lions.
>>>>>>>>
>>>>>>>> Now let's say that the result show that tigers use more energy
>>>>>>>> than they
>>>>>>>> take in food. Would you instantly conclude that the law of
>>>>>>>> conservation of
>>>>>>>> energy must be incorrect?
>>>>>>>>
>>>>>>>> The third is what PO is doing.
>>>>>>> I have no idea what parts of this analogy map to the current
>>>>>>> situation.
>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>> with any established facts in anything he is doing.
>>>>>>>
>>>>>> He's dry-run P(P) and established that it doesn't halt. He's
>>>>>> invoked H on it
>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>
>>>>>> So something odd is going on there that needs an explanation.
>>>>>
>>>>> I already fully addressed that in my reply to you yesterday. P(P)
>>>>> has a
>>>>> dependency relationship on the return value of H(P,P) that the
>>>>> correctly
>>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>>> relative to each other.
>>>>>
>>>> I can see an alternative explanation. I was going to say "it is
>>>> obvious" but
>>>> no-one else has stepped in to point it out. Maybe because it's too
>>>> obvious
>>>> and they want to give other posters a chance.
>>> To what exact extent do you have this mandatory prerequisite knowledge?
>>> To fully understand this code a software engineer must be an expert in:
>>> the C programming language, the x86 programming language, exactly how C
>>> translates into x86 and the ability to recognize infinite recursion at
>>> the x86 assembly language level.
>>> The ordinary semantics of standard C and the conventional x86 language
>>> are the entire semantics required to conclusively prove that H(P,P) does
>>> correctly determine that its correct and complete x86 emulation of its
>>> input would never reach the "ret" instruction of P.
>>> The halt decider and its input are written in C compiled with a
>>> Microsoft C compiler that generates a standard COFF object file. This
>>> file is the input to the x86utm operating system that runs on both
>>> Microsoft Windows and Linux.
>>>
>> I'm a C programmer and I have done machine code programming, though not
>> with the x86 chip. But I'd dispute your requirements.
>
>
> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
> DISAGREEMENT IS INHERENTLY INCORRECT.
>
> From a purely software engineering perspective H is correctly defined
> to correctly determine that its correct and complete x86 emulation of
> its input would never reach the "ret" instruction of this input and it
> is proven that H does do this correctly in a finite number of steps.
>

On 6/24/2022 12:29 PM, Malcolm McLean wrote:
> On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote:
>> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
>>> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>>>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>>>>
>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>
>>>>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>>>>> what's going on.
>>>>>>>>>>
>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>>>>> body temperature, and so on.
>>>>>>>>>
>>>>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>>>>
>>>>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>>>>
>>>>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>>>>> energy must be incorrect?
>>>>>>>>>
>>>>>>>>> The third is what PO is doing.
>>>>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>
>>>>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
>>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>>
>>>>>>> So something odd is going on there that needs an explanation.
>>>>>>
>>>>>> I already fully addressed that in my reply to you yesterday. P(P) has a
>>>>>> dependency relationship on the return value of H(P,P) that the correctly
>>>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>>>> relative to each other.
>>>>>>
>>>>> I can see an alternative explanation. I was going to say "it is obvious" but
>>>>> no-one else has stepped in to point it out. Maybe because it's too obvious
>>>>> and they want to give other posters a chance.
>>>> To what exact extent do you have this mandatory prerequisite knowledge?
>>>> To fully understand this code a software engineer must be an expert in:
>>>> the C programming language, the x86 programming language, exactly how C
>>>> translates into x86 and the ability to recognize infinite recursion at
>>>> the x86 assembly language level.
>>>> The ordinary semantics of standard C and the conventional x86 language
>>>> are the entire semantics required to conclusively prove that H(P,P) does
>>>> correctly determine that its correct and complete x86 emulation of its
>>>> input would never reach the "ret" instruction of P.
>>>> The halt decider and its input are written in C compiled with a
>>>> Microsoft C compiler that generates a standard COFF object file. This
>>>> file is the input to the x86utm operating system that runs on both
>>>> Microsoft Windows and Linux.
>>>>
>>> I'm a C programmer and I have done machine code programming, though not
>>> with the x86 chip. But I'd dispute your requirements.
>> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
>> DISAGREEMENT IS INHERENTLY INCORRECT.
>>
>> From a purely software engineering perspective H is correctly defined
>> to correctly determine that its correct and complete x86 emulation of
>> its input would never reach the "ret" instruction of this input and it
>> is proven that H does do this correctly in a finite number of steps.
>>> To re-tread the analogy,
>>> our measurements show that tigers use more energy than they take in.
>>> Now you could construct an very complicated explanation for that using
>>> advanced quantum mechanics and other concepts. And you do need to have
>>> a rudimentary understanding of physics to see where the difficulty lies.
>>
>>> But you don't need more than the rudimentary understanding to suggest the
>>> alternative explanation, and to realise that it is overwhelmingly more likely.
>> It seems that you may be saying that it is OK to disbelieve verified
>> facts some of the time. I vehemently disagree and this position could
>> cause both the end of Democracy in the USA and the extinction of
>> humanity in the world through lack of climate change action.
>>
>> Ordinary software engineering conclusively proves that all of my claims
>> that I just stated are easily verified as factually correct.
>>
>> Anyone that disagrees with claims that are verified as factually correct
>> is either insufficiently technically competent or less than totally
>> honest. Someone that refuses to acknowledge that claims are correct when
>> they know that these claims are correct is less than totally honest.
>>
> Let's say we do our measurements on tigers. They come back
> average calorie intake (prey) 2000 calories.
> average outgoings
> stored fat 100 calories
> metabolism (body temperature) 1500 calories
> movement 500 calories
> lactation 200 calories.
>
> these are averaged over a long period.
>
> Now what is your conclusion?

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

On 6/24/22 12:52 PM, olcott wrote:
> On 6/24/2022 11:32 AM, olcott wrote:
>> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
>>> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>>>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>> Linz and others were aware that: A halt decider must
>>>>>>>>>>>>>> compute the mapping
>>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis
>>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>>> the same as the direct execution of these inputs. They
>>>>>>>>>>>>>> were unaware of
>>>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight,
>>>>>>>>>>>>>>> or H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>>> halt decider H
>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume
>>>>>>>>>>>>> that H is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>>> That "the
>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs
>>>>>>>>>>>>> to a simulating
>>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>>> these inputs"?
>>>>>>>>>>>>
>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>
>>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>>> You've
>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>>>>> explanation
>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>> There is only one explanation. What you call the "dry-run" is
>>>>>>>>>> not that
>>>>>>>>>> same as the P(P). We've known this since the "line 15
>>>>>>>>>> commented out"
>>>>>>>>>> days. There are two computations -- one that is not stopped
>>>>>>>>>> and one
>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the
>>>>>>>>>> input to
>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that
>>>>>>>>>> hide
>>>>>>>>>> what's going on.
>>>>>>>>>>
>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>> The example I always use is that you are doing an energy budget
>>>>>>>>> for tigers.
>>>>>>>>> You work how much they use on running about, lactating,
>>>>>>>>> maintaining their
>>>>>>>>> body temperature, and so on.
>>>>>>>>>
>>>>>>>>> Now let's say that you find that all results are within a few
>>>>>>>>> percentage points
>>>>>>>>> of a similar budget done for lions. You'd instantly accept this
>>>>>>>>> data.
>>>>>>>>>
>>>>>>>>> Now let's say that the results are wildly different from a
>>>>>>>>> previous budget done
>>>>>>>>> for lions. You wouldn't just accept that data. You'd check.
>>>>>>>>> You'd want to
>>>>>>>>> understand the reasons tigers spend far less energy on movement
>>>>>>>>> than lions.
>>>>>>>>>
>>>>>>>>> Now let's say that the result show that tigers use more energy
>>>>>>>>> than they
>>>>>>>>> take in food. Would you instantly conclude that the law of
>>>>>>>>> conservation of
>>>>>>>>> energy must be incorrect?
>>>>>>>>>
>>>>>>>>> The third is what PO is doing.
>>>>>>>> I have no idea what parts of this analogy map to the current
>>>>>>>> situation.
>>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>
>>>>>>> He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>> invoked H on it
>>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>>
>>>>>>> So something odd is going on there that needs an explanation.
>>>>>>
>>>>>> I already fully addressed that in my reply to you yesterday. P(P)
>>>>>> has a
>>>>>> dependency relationship on the return value of H(P,P) that the
>>>>>> correctly
>>>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>>>> relative to each other.
>>>>>>
>>>>> I can see an alternative explanation. I was going to say "it is
>>>>> obvious" but
>>>>> no-one else has stepped in to point it out. Maybe because it's too
>>>>> obvious
>>>>> and they want to give other posters a chance.
>>>> To what exact extent do you have this mandatory prerequisite knowledge?
>>>> To fully understand this code a software engineer must be an expert in:
>>>> the C programming language, the x86 programming language, exactly how C
>>>> translates into x86 and the ability to recognize infinite recursion at
>>>> the x86 assembly language level.
>>>> The ordinary semantics of standard C and the conventional x86 language
>>>> are the entire semantics required to conclusively prove that H(P,P)
>>>> does
>>>> correctly determine that its correct and complete x86 emulation of its
>>>> input would never reach the "ret" instruction of P.
>>>> The halt decider and its input are written in C compiled with a
>>>> Microsoft C compiler that generates a standard COFF object file. This
>>>> file is the input to the x86utm operating system that runs on both
>>>> Microsoft Windows and Linux.
>>>>
>>> I'm a C programmer and I have done machine code programming, though not
>>> with the x86 chip. But I'd dispute your requirements.
>>
>>
>> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
>> DISAGREEMENT IS INHERENTLY INCORRECT.
>>
>>  From a purely software engineering perspective H is correctly defined
>> to correctly determine that its correct and complete x86 emulation of
>> its input would never reach the "ret" instruction of this input and it
>> is proven that H does do this correctly in a finite number of steps.
>>
>
> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
> DISAGREEMENT IS INHERENTLY INCORRECT.

On 6/24/22 1:42 PM, olcott wrote:
> On 6/24/2022 12:29 PM, Malcolm McLean wrote:
>> On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote:
>>> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
>>>> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>>>>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>>>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse
>>>>>>>>>> wrote:
>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>>> Linz and others were aware that: A halt decider must
>>>>>>>>>>>>>>> compute the mapping
>>>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis
>>>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>>>> the same as the direct execution of these inputs. They
>>>>>>>>>>>>>>> were unaware of
>>>>>>>>>>>>>>> this because no one previously fully examined a
>>>>>>>>>>>>>>> simulating halt decider
>>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight,
>>>>>>>>>>>>>>>> or H is wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>>>> halt decider H
>>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume
>>>>>>>>>>>>>> that H is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>>>> That "the
>>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs
>>>>>>>>>>>>>> to a simulating
>>>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>>>> these inputs"?
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>>
>>>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>>>> You've
>>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>>>>>> explanation
>>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>>> There is only one explanation. What you call the "dry-run" is
>>>>>>>>>>> not that
>>>>>>>>>>> same as the P(P). We've known this since the "line 15
>>>>>>>>>>> commented out"
>>>>>>>>>>> days. There are two computations -- one that is not stopped
>>>>>>>>>>> and one
>>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the
>>>>>>>>>>> input to
>>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words
>>>>>>>>>>> that hide
>>>>>>>>>>> what's going on.
>>>>>>>>>>>
>>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>>> The example I always use is that you are doing an energy
>>>>>>>>>> budget for tigers.
>>>>>>>>>> You work how much they use on running about, lactating,
>>>>>>>>>> maintaining their
>>>>>>>>>> body temperature, and so on.
>>>>>>>>>>
>>>>>>>>>> Now let's say that you find that all results are within a few
>>>>>>>>>> percentage points
>>>>>>>>>> of a similar budget done for lions. You'd instantly accept
>>>>>>>>>> this data.
>>>>>>>>>>
>>>>>>>>>> Now let's say that the results are wildly different from a
>>>>>>>>>> previous budget done
>>>>>>>>>> for lions. You wouldn't just accept that data. You'd check.
>>>>>>>>>> You'd want to
>>>>>>>>>> understand the reasons tigers spend far less energy on
>>>>>>>>>> movement than lions.
>>>>>>>>>>
>>>>>>>>>> Now let's say that the result show that tigers use more energy
>>>>>>>>>> than they
>>>>>>>>>> take in food. Would you instantly conclude that the law of
>>>>>>>>>> conservation of
>>>>>>>>>> energy must be incorrect?
>>>>>>>>>>
>>>>>>>>>> The third is what PO is doing.
>>>>>>>>> I have no idea what parts of this analogy map to the current
>>>>>>>>> situation.
>>>>>>>>> PO has no contradictory results about anything. There's no
>>>>>>>>> conflict
>>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>>
>>>>>>>> He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>>> invoked H on it
>>>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>>>
>>>>>>>> So something odd is going on there that needs an explanation.
>>>>>>>
>>>>>>> I already fully addressed that in my reply to you yesterday. P(P)
>>>>>>> has a
>>>>>>> dependency relationship on the return value of H(P,P) that the
>>>>>>> correctly
>>>>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>>>>> relative to each other.
>>>>>>>
>>>>>> I can see an alternative explanation. I was going to say "it is
>>>>>> obvious" but
>>>>>> no-one else has stepped in to point it out. Maybe because it's too
>>>>>> obvious
>>>>>> and they want to give other posters a chance.
>>>>> To what exact extent do you have this mandatory prerequisite
>>>>> knowledge?
>>>>> To fully understand this code a software engineer must be an expert
>>>>> in:
>>>>> the C programming language, the x86 programming language, exactly
>>>>> how C
>>>>> translates into x86 and the ability to recognize infinite recursion at
>>>>> the x86 assembly language level.
>>>>> The ordinary semantics of standard C and the conventional x86 language
>>>>> are the entire semantics required to conclusively prove that H(P,P)
>>>>> does
>>>>> correctly determine that its correct and complete x86 emulation of its
>>>>> input would never reach the "ret" instruction of P.
>>>>> The halt decider and its input are written in C compiled with a
>>>>> Microsoft C compiler that generates a standard COFF object file. This
>>>>> file is the input to the x86utm operating system that runs on both
>>>>> Microsoft Windows and Linux.
>>>>>
>>>> I'm a C programmer and I have done machine code programming, though not
>>>> with the x86 chip. But I'd dispute your requirements.
>>> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
>>> DISAGREEMENT IS INHERENTLY INCORRECT.
>>>
>>>  From a purely software engineering perspective H is correctly defined
>>> to correctly determine that its correct and complete x86 emulation of
>>> its input would never reach the "ret" instruction of this input and it
>>> is proven that H does do this correctly in a finite number of steps.
>>>> To re-tread the analogy,
>>>> our measurements show that tigers use more energy than they take in.
>>>> Now you could construct an very complicated explanation for that using
>>>> advanced quantum mechanics and other concepts. And you do need to have
>>>> a rudimentary understanding of physics to see where the difficulty
>>>> lies.
>>>
>>>> But you don't need more than the rudimentary understanding to
>>>> suggest the
>>>> alternative explanation, and to realise that it is overwhelmingly
>>>> more likely.
>>> It seems that you may be saying that it is OK to disbelieve verified
>>> facts some of the time. I vehemently disagree and this position could
>>> cause both the end of Democracy in the USA and the extinction of
>>> humanity in the world through lack of climate change action.
>>>
>>> Ordinary software engineering conclusively proves that all of my claims
>>> that I just stated are easily verified as factually correct.
>>>
>>> Anyone that disagrees with claims that are verified as factually correct
>>> is either insufficiently technically competent or less than totally
>>> honest. Someone that refuses to acknowledge that claims are correct when
>>> they know that these claims are correct is less than totally honest.
>>>
>> Let's say we do our measurements on tigers. They come back
>> average calorie intake (prey) 2000 calories.
>> average outgoings
>>            stored fat 100 calories
>>            metabolism (body temperature) 1500 calories
>>            movement 500 calories
>>            lactation    200 calories.
>>
>> these are averaged over a long period.
>>
>> Now what is your conclusion?
>
> The measurements are inaccurate as can occur with all empirical science
> that relies on physical observation. It is also the case the all
> empirical science utterly relies on a possibly false fundamental
> assumption that is discussed at length as the problem of induction.
> https://en.wikipedia.org/wiki/Problem_of_induction
>
> On the other hand when we look at the analytic side of the analytic /
> synthetic distinction:
> https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction
>
> We can verify that an expression of language is totally true entirely on
> the basis of its meaning. This proves that your analogy is not apt.
>
> From a purely software engineering perspective H(P,P) is required to to
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction of this input and H must
> do this in a finite number of steps.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
>
>>>
>>> I believe that you are as honest as you can be and the issue is that you
>>> have a lack of sufficient understanding.
>>>
>> See if you can work out the tiger example first.
>
>

On 6/24/2022 2:34 PM, Malcolm McLean wrote:
> On Friday, 24 June 2022 at 18:42:36 UTC+1, olcott wrote:
>> On 6/24/2022 12:29 PM, Malcolm McLean wrote:
>>> On Friday, 24 June 2022 at 17:32:24 UTC+1, olcott wrote:
>>>> On 6/24/2022 11:09 AM, Malcolm McLean wrote:
>>>>> On Friday, 24 June 2022 at 16:50:10 UTC+1, olcott wrote:
>>>>>> On 6/24/2022 8:34 AM, Malcolm McLean wrote:
>>>>>>> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:
>>>>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>>>>>>> what's going on.
>>>>>>>>>>>>
>>>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>>>>>>> body temperature, and so on.
>>>>>>>>>>>
>>>>>>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>>>>>>
>>>>>>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>>>>>>
>>>>>>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>>>>>>> energy must be incorrect?
>>>>>>>>>>>
>>>>>>>>>>> The third is what PO is doing.
>>>>>>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>>>
>>>>>>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
>>>>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>>>>
>>>>>>>>> So something odd is going on there that needs an explanation.
>>>>>>>>
>>>>>>>> I already fully addressed that in my reply to you yesterday. P(P) has a
>>>>>>>> dependency relationship on the return value of H(P,P) that the correctly
>>>>>>>> emulated input to H(P,P) does not have. This changes their behavior
>>>>>>>> relative to each other.
>>>>>>>>
>>>>>>> I can see an alternative explanation. I was going to say "it is obvious" but
>>>>>>> no-one else has stepped in to point it out. Maybe because it's too obvious
>>>>>>> and they want to give other posters a chance.
>>>>>> To what exact extent do you have this mandatory prerequisite knowledge?
>>>>>> To fully understand this code a software engineer must be an expert in:
>>>>>> the C programming language, the x86 programming language, exactly how C
>>>>>> translates into x86 and the ability to recognize infinite recursion at
>>>>>> the x86 assembly language level.
>>>>>> The ordinary semantics of standard C and the conventional x86 language
>>>>>> are the entire semantics required to conclusively prove that H(P,P) does
>>>>>> correctly determine that its correct and complete x86 emulation of its
>>>>>> input would never reach the "ret" instruction of P.
>>>>>> The halt decider and its input are written in C compiled with a
>>>>>> Microsoft C compiler that generates a standard COFF object file. This
>>>>>> file is the input to the x86utm operating system that runs on both
>>>>>> Microsoft Windows and Linux.
>>>>>>
>>>>> I'm a C programmer and I have done machine code programming, though not
>>>>> with the x86 chip. But I'd dispute your requirements.
>>>> THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
>>>> DISAGREEMENT IS INHERENTLY INCORRECT.
>>>>
>>>> From a purely software engineering perspective H is correctly defined
>>>> to correctly determine that its correct and complete x86 emulation of
>>>> its input would never reach the "ret" instruction of this input and it
>>>> is proven that H does do this correctly in a finite number of steps.
>>>>> To re-tread the analogy,
>>>>> our measurements show that tigers use more energy than they take in.
>>>>> Now you could construct an very complicated explanation for that using
>>>>> advanced quantum mechanics and other concepts. And you do need to have
>>>>> a rudimentary understanding of physics to see where the difficulty lies.
>>>>
>>>>> But you don't need more than the rudimentary understanding to suggest the
>>>>> alternative explanation, and to realise that it is overwhelmingly more likely.
>>>> It seems that you may be saying that it is OK to disbelieve verified
>>>> facts some of the time. I vehemently disagree and this position could
>>>> cause both the end of Democracy in the USA and the extinction of
>>>> humanity in the world through lack of climate change action.
>>>>
>>>> Ordinary software engineering conclusively proves that all of my claims
>>>> that I just stated are easily verified as factually correct.
>>>>
>>>> Anyone that disagrees with claims that are verified as factually correct
>>>> is either insufficiently technically competent or less than totally
>>>> honest. Someone that refuses to acknowledge that claims are correct when
>>>> they know that these claims are correct is less than totally honest.
>>>>
>>> Let's say we do our measurements on tigers. They come back
>>> average calorie intake (prey) 2000 calories.
>>> average outgoings
>>> stored fat 100 calories
>>> metabolism (body temperature) 1500 calories
>>> movement 500 calories
>>> lactation 200 calories.
>>>
>>> these are averaged over a long period.
>>>
>>> Now what is your conclusion?
>> The measurements are inaccurate as can occur with all empirical science
>> that relies on physical observation. It is also the case the all
>> empirical science utterly relies on a possibly false fundamental
>> assumption that is discussed at length as the problem of induction.
>> https://en.wikipedia.org/wiki/Problem_of_induction
>>
> Exactly. You've got it. Either the measurements are inaccurate, or the
> theory that energy is conserved is wrong.
>> On the other hand when we look at the analytic side of the analytic /
>> synthetic distinction:
>> https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction
>>
>> We can verify that an expression of language is totally true entirely on
>> the basis of its meaning. This proves that your analogy is not apt.
>>
> I'm not sure about this.
>>
>> From a purely software engineering perspective H(P,P) is required to to
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction of this input and H must
>> do this in a finite number of steps.
>> The ordinary semantics of standard C and the conventional x86 language
>> are the entire semantics required to conclusively prove that H(P,P) does
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction (final state) of this
>> input thus never halts.
>>
> So you've dry-run P(P) and determined that it doesn't halt. Just as our
> hypothetical ecologists measured the tigers' energy budget.
> What is the obvious conclusion?

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

On 6/24/2022 3:25 PM, Malcolm McLean wrote:
> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>> ever before.
>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>
>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>
>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>
>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>
>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>
>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>> has rather far-reaching consequences.
>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>> what's going on.
>>>>>>
>>>>> I'm a scientists, not a mathematician.
>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>> You work how much they use on running about, lactating, maintaining their
>>>>> body temperature, and so on.
>>>>>
>>>>> Now let's say that you find that all results are within a few percentage points
>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>
>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>
>>>>> Now let's say that the result show that tigers use more energy than they
>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>> energy must be incorrect?
>>>>>
>>>>> The third is what PO is doing.
>>>> I have no idea what parts of this analogy map to the current situation.
>>>> PO has no contradictory results about anything. There's no conflict
>>>> with any established facts in anything he is doing.
>>>>
>>> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>
>>> So something odd is going on there that needs an explanation.
>> Then I don't know what you mean by "dry-run" and what needs an
>> explanation (for me) is your description of what he's doing. Nothing in
>> what PO is doing needs to be explained as far as I can see.
>>
> "Dry run" means that a human programmer looks at the code, and determines
> what it does, without actually executing it.
> It's a very important technique, because it's not always practical or even
> possible to run a debugger. Even where a debugger is available, often
> dry-running will reveal bugs in a fraction of the time.
> In this case, PO has dry run P(P). That is, he has looked at the source, and
> worked out what it will do. Which is to run an infinite sequence of nested
> emulations. So it won't halt. H(P,P) also reports "non-halting". So this is
> powerful evidence that H is correct.

Great!

> However when he actually executes P(P) on hardware, it terminates.
> Something isn't right.

None-the-less when everyone in the entire universe disagrees with a
verified fact then they are all necessarily incorrect.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

> PO's explanation is that P(P) has different correct behaviour when run and
> when emulated by H.

It is very easily proven as an established fact that the correctly
emulated input to H(P,P) would never halt and P(P) halts.

> I can think of an obvious alternative explanation which is much simpler and
> much less far-reaching in its implications. However despite a lot of coaxing,
> no-one else seems to have arrived at it.

I think that most of my reviewers are only interested in rebuttal at the
expense of an actual honest dialogue. You are certainly the exception to
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 6/24/22 4:35 PM, olcott wrote:
> On 6/24/2022 3:25 PM, Malcolm McLean wrote:
>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>> Linz and others were aware that: A halt decider must compute
>>>>>>>>>>> the mapping
>>>>>>>>>>> from its inputs to an accept or reject state on the basis of
>>>>>>>>>>> the actual
>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>> behavior that
>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>> decider is not
>>>>>>>>>>> the same as the direct execution of these inputs. They were
>>>>>>>>>>> unaware of
>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>> halt decider
>>>>>>>>>>> ever before.
>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>
>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H
>>>>>>>>>>>> is wrong.
>>>>>>>>>>>
>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt
>>>>>>>>>> decider H
>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H
>>>>>>>>>> is correct.
>>>>>>>>>>
>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>> That "the
>>>>>>>>>> actual behaviour that is actually specified by the inputs to a
>>>>>>>>>> simulating
>>>>>>>>>> halt decider is not the same as the direct execution of these
>>>>>>>>>> inputs"?
>>>>>>>>>
>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>
>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>> explanation
>>>>>>>> has rather far-reaching consequences.
>>>>>>> There is only one explanation. What you call the "dry-run" is not
>>>>>>> that
>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>> what's going on.
>>>>>>>
>>>>>> I'm a scientists, not a mathematician.
>>>>>> The example I always use is that you are doing an energy budget
>>>>>> for tigers.
>>>>>> You work how much they use on running about, lactating,
>>>>>> maintaining their
>>>>>> body temperature, and so on.
>>>>>>
>>>>>> Now let's say that you find that all results are within a few
>>>>>> percentage points
>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>
>>>>>> Now let's say that the results are wildly different from a
>>>>>> previous budget done
>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd
>>>>>> want to
>>>>>> understand the reasons tigers spend far less energy on movement
>>>>>> than lions.
>>>>>>
>>>>>> Now let's say that the result show that tigers use more energy
>>>>>> than they
>>>>>> take in food. Would you instantly conclude that the law of
>>>>>> conservation of
>>>>>> energy must be incorrect?
>>>>>>
>>>>>> The third is what PO is doing.
>>>>> I have no idea what parts of this analogy map to the current
>>>>> situation.
>>>>> PO has no contradictory results about anything. There's no conflict
>>>>> with any established facts in anything he is doing.
>>>>>
>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked
>>>> H on it
>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>
>>>> So something odd is going on there that needs an explanation.
>>> Then I don't know what you mean by "dry-run" and what needs an
>>> explanation (for me) is your description of what he's doing. Nothing in
>>> what PO is doing needs to be explained as far as I can see.
>>>
>> "Dry run" means that a human programmer looks at the code, and determines
>> what it does, without actually executing it.
>> It's a very important technique, because it's not always practical or
>> even
>> possible to run a debugger. Even where a debugger is available, often
>> dry-running will reveal bugs in a fraction of the time.
>> In this case, PO has dry run P(P). That is, he has looked at the
>> source, and
>> worked out what it will do. Which is to run an infinite sequence of
>> nested
>> emulations. So it won't halt. H(P,P) also reports "non-halting". So
>> this is
>> powerful evidence  that H is correct.
>
> Great!
>

Except, of course, that the "Dry-run" didn't evalute H as what H
actually ends up being, but by what H was specifed to be, that is a
comptation that completely em

>> However when he actually executes P(P) on hardware, it terminates.
>> Something isn't right.
>
> None-the-less when everyone in the entire universe disagrees with a
> verified fact then they are all necessarily incorrect.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
>> PO's explanation is that P(P) has different correct behaviour when run
>> and
>> when emulated by H.
>
> It is very easily proven as an established fact that the correctly
> emulated input to H(P,P) would never halt and P(P) halts.

On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>> ever before.
>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>
>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>
>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>
>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>
>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>
>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>> has rather far-reaching consequences.
>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>> what's going on.
>>>>>>>
>>>>>> I'm a scientists, not a mathematician.
>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>> body temperature, and so on.
>>>>>>
>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>
>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>
>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>> energy must be incorrect?
>>>>>>
>>>>>> The third is what PO is doing.
>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>> PO has no contradictory results about anything. There's no conflict
>>>>> with any established facts in anything he is doing.
>>>>>
>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>
>>>> So something odd is going on there that needs an explanation.
>>> Then I don't know what you mean by "dry-run" and what needs an
>>> explanation (for me) is your description of what he's doing. Nothing in
>>> what PO is doing needs to be explained as far as I can see.
>>>
>> "Dry run" means that a human programmer looks at the code, and determines
>> what it does, without actually executing it.
>
> OK. So what value does it have in this case? Do you think PO is
> competent to "dry run" any code at all?
>
> Going back, now, to what you think needs to be resolved:
>
> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>
> The obvious conclusion is that PO's dry run (if he has indeed done such
> a thing) is incorrect. Anyone who eyeballs some case and concludes that
> it does not do what it down when actually run has just made a mistake.
> Do you think it's interesting to find out what mistake PO has made when
> guessing what the code does? If so have fun trying to get the code from
> him...
>
> The more interesting (at least at one time) is fact that H is not
> correct since, by definition, H(X,Y) should report on the "halting" of
> the call X(Y).
>
>> It's a very important technique, because it's not always practical or even
>> possible to run a debugger. Even where a debugger is available, often
>> dry-running will reveal bugs in a fraction of the time.
>
> In this case, we have the undisputed fact that P(P) halts, so there's
> really no value in a "dry run" from a debugging perspective.
>
>> In this case, PO has dry run P(P).
>
> And, if that is indeed what he's done (and I don't think it is) he knows
> he's made some mistake in his "dry run".
>
>> That is, he has looked at the source, and
>> worked out what it will do.
>
> But, I hope you agree, he's made some mistake or he's been lying when re
> reports that P(P) halts.
>
>> Which is to run an infinite sequence of nested
>> emulations. So it won't halt.
>
> The execution of P(P) does not represent an infinite sequence of nested
> simulations. We know that because P(P) halts.
>
>> H(P,P) also reports "non-halting". So this is
>> powerful evidence that H is correct.
>
> Eh? How is some code eyeballing more compelling evidence than the 100%
> undisputed fact that P(P) halts? How is the opinion of someone who
> can't write a parity checking TM powerful evidence of anything?
>
>> However when he actually executes P(P) on hardware, it terminates.
>> Something isn't right.
>
> Yes.
>
>> PO's explanation is that P(P) has different correct behaviour when run and
>> when emulated by H.
>
> That can't be an explanation of anything because, according to you, he
> is wrong about the dry run of P(P) and an actual run of P(P). Both the
> dry run and the actual run must take account of the fact that H is
> (partially) emulating P(P).
>
>> I can think of an obvious alternative explanation which is much
>> simpler and much less far-reaching in its implications. However
>> despite a lot of coaxing, no-one else seems to have arrived at it.
>
> There is nothing here with any far-reaching implications and since I've
> never shared your explanation, I'm not going to look for an alternative.
>
> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
> relying on sophistry. H "aborts" so P never reaches its "ret"
> instruction. That's why P(P) and "the simulation of the inputs to
> H(P,P)" are different. 18 years of work for what? An H that, on the
> basis of his own words, obviously gets the wrong answer.
>

On 6/24/2022 5:23 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> You say that "H(P,P) is required to to correctly determine that its
>> correct and complete x86 emulation of its input would never reach the
>> "ret" instruction of this input".
>
> Can I just check that you know this is not what H is supposed to do? PO
> has been searching for some from of words that can stir up enough mud
> that the fact that H is wrong can be to some extent obscured. He seems
> to have hit pay dirt with this latest phrasing.
>
> Everyone seem happy to talk to PO on his own terms (and that's fine --
> it's what he posts for), but in the C-function version of the problem,
> H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he
> stopped talking about this problem which he knows in not decidable.
>

It is common knowledge (in computer science) that a halt decider must
compute the mapping from actual its inputs to an accept or reject state
on the basis of the actual behavior that is actually specified by its
actual inputs.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY.

--
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/24/2022 6:58 PM, dklei...@gmail.com wrote:
> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>>>
>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>
>>>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>>>> what's going on.
>>>>>>>>>
>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>>>> body temperature, and so on.
>>>>>>>>
>>>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>>>
>>>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>>>
>>>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>>>> energy must be incorrect?
>>>>>>>>
>>>>>>>> The third is what PO is doing.
>>>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>> with any established facts in anything he is doing.
>>>>>>>
>>>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>
>>>>>> So something odd is going on there that needs an explanation.
>>>>> Then I don't know what you mean by "dry-run" and what needs an
>>>>> explanation (for me) is your description of what he's doing. Nothing in
>>>>> what PO is doing needs to be explained as far as I can see.
>>>>>
>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>> what it does, without actually executing it.
>>>
>>> OK. So what value does it have in this case? Do you think PO is
>>> competent to "dry run" any code at all?
>>>
>>> Going back, now, to what you think needs to be resolved:
>>>
>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>>
>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>> a thing) is incorrect. Anyone who eyeballs some case and concludes that
>>> it does not do what it down when actually run has just made a mistake.
>>> Do you think it's interesting to find out what mistake PO has made when
>>> guessing what the code does? If so have fun trying to get the code from
>>> him...
>>>
>>> The more interesting (at least at one time) is fact that H is not
>>> correct since, by definition, H(X,Y) should report on the "halting" of
>>> the call X(Y).
>>>
>>>> It's a very important technique, because it's not always practical or even
>>>> possible to run a debugger. Even where a debugger is available, often
>>>> dry-running will reveal bugs in a fraction of the time.
>>>
>>> In this case, we have the undisputed fact that P(P) halts, so there's
>>> really no value in a "dry run" from a debugging perspective.
>>>
>>>> In this case, PO has dry run P(P).
>>>
>>> And, if that is indeed what he's done (and I don't think it is) he knows
>>> he's made some mistake in his "dry run".
>>>
>>>> That is, he has looked at the source, and
>>>> worked out what it will do.
>>>
>>> But, I hope you agree, he's made some mistake or he's been lying when re
>>> reports that P(P) halts.
>>>
>>>> Which is to run an infinite sequence of nested
>>>> emulations. So it won't halt.
>>>
>>> The execution of P(P) does not represent an infinite sequence of nested
>>> simulations. We know that because P(P) halts.
>>>
>>>> H(P,P) also reports "non-halting". So this is
>>>> powerful evidence that H is correct.
>>>
>>> Eh? How is some code eyeballing more compelling evidence than the 100%
>>> undisputed fact that P(P) halts? How is the opinion of someone who
>>> can't write a parity checking TM powerful evidence of anything?
>>>
>>>> However when he actually executes P(P) on hardware, it terminates.
>>>> Something isn't right.
>>>
>>> Yes.
>>>
>>>> PO's explanation is that P(P) has different correct behaviour when run and
>>>> when emulated by H.
>>>
>>> That can't be an explanation of anything because, according to you, he
>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the
>>> dry run and the actual run must take account of the fact that H is
>>> (partially) emulating P(P).
>>>
>>>> I can think of an obvious alternative explanation which is much
>>>> simpler and much less far-reaching in its implications. However
>>>> despite a lot of coaxing, no-one else seems to have arrived at it.
>>>
>>> There is nothing here with any far-reaching implications and since I've
>>> never shared your explanation, I'm not going to look for an alternative.
>>>
>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
>>> relying on sophistry. H "aborts" so P never reaches its "ret"
>>> instruction. That's why P(P) and "the simulation of the inputs to
>>> H(P,P)" are different. 18 years of work for what? An H that, on the
>>> basis of his own words, obviously gets the wrong answer.
>>>
>> The ordinary semantics of standard C and the conventional x86 language
>> are the entire semantics required to conclusively prove that H(P,P) does
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction (final state) of this
>> input thus never halts.
>> That your understanding of the semantics of the x86 language is
>> insufficient to directly confirm this is less than no rebuttal at all.
>
> I assume the semantics of C are defined by the 1989 Standard. The
> semantics of x86 assembly language are described (not actually
> authoritatively defined) in other documents. The mapping of C onto
> the assembly language is far from unique (every compiler could be
> different) PO appears to using a version of Microsoft's C# compiler.
>

On 6/24/22 8:12 PM, olcott wrote:
> On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
>> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
>>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P)
>>>>>>>>>>>>>>> returns 0, so H
>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P)
>>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>> Linz and others were aware that: A halt decider must
>>>>>>>>>>>>>> compute the mapping
>>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis
>>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>>> Linz and others made the false assumption that the actual
>>>>>>>>>>>>>> behavior that
>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt
>>>>>>>>>>>>>> decider is not
>>>>>>>>>>>>>> the same as the direct execution of these inputs. They
>>>>>>>>>>>>>> were unaware of
>>>>>>>>>>>>>> this because no one previously fully examined a simulating
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight,
>>>>>>>>>>>>>>> or H is wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the
>>>>>>>>>>>>> halt decider H
>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume
>>>>>>>>>>>>> that H is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude?
>>>>>>>>>>>>> That "the
>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs
>>>>>>>>>>>>> to a simulating
>>>>>>>>>>>>> halt decider is not the same as the direct execution of
>>>>>>>>>>>>> these inputs"?
>>>>>>>>>>>>
>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>
>>>>>>>>>>> That's your conclusion from your observations and reasoning.
>>>>>>>>>>> You've
>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>> explanation is the one you've given but, as I said, that
>>>>>>>>>>> explanation
>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>> There is only one explanation. What you call the "dry-run" is
>>>>>>>>>> not that
>>>>>>>>>> same as the P(P). We've known this since the "line 15
>>>>>>>>>> commented out"
>>>>>>>>>> days. There are two computations -- one that is not stopped
>>>>>>>>>> and one
>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the
>>>>>>>>>> input to
>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that
>>>>>>>>>> hide
>>>>>>>>>> what's going on.
>>>>>>>>>>
>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>> The example I always use is that you are doing an energy budget
>>>>>>>>> for tigers.
>>>>>>>>> You work how much they use on running about, lactating,
>>>>>>>>> maintaining their
>>>>>>>>> body temperature, and so on.
>>>>>>>>>
>>>>>>>>> Now let's say that you find that all results are within a few
>>>>>>>>> percentage points
>>>>>>>>> of a similar budget done for lions. You'd instantly accept this
>>>>>>>>> data.
>>>>>>>>>
>>>>>>>>> Now let's say that the results are wildly different from a
>>>>>>>>> previous budget done
>>>>>>>>> for lions. You wouldn't just accept that data. You'd check.
>>>>>>>>> You'd want to
>>>>>>>>> understand the reasons tigers spend far less energy on movement
>>>>>>>>> than lions.
>>>>>>>>>
>>>>>>>>> Now let's say that the result show that tigers use more energy
>>>>>>>>> than they
>>>>>>>>> take in food. Would you instantly conclude that the law of
>>>>>>>>> conservation of
>>>>>>>>> energy must be incorrect?
>>>>>>>>>
>>>>>>>>> The third is what PO is doing.
>>>>>>>> I have no idea what parts of this analogy map to the current
>>>>>>>> situation.
>>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>
>>>>>>> He's dry-run P(P) and established that it doesn't halt. He's
>>>>>>> invoked H on it
>>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>>
>>>>>>> So something odd is going on there that needs an explanation.
>>>>>> Then I don't know what you mean by "dry-run" and what needs an
>>>>>> explanation (for me) is your description of what he's doing.
>>>>>> Nothing in
>>>>>> what PO is doing needs to be explained as far as I can see.
>>>>>>
>>>>> "Dry run" means that a human programmer looks at the code, and
>>>>> determines
>>>>> what it does, without actually executing it.
>>>>
>>>> OK. So what value does it have in this case? Do you think PO is
>>>> competent to "dry run" any code at all?
>>>>
>>>> Going back, now, to what you think needs to be resolved:
>>>>
>>>> | He's dry-run P(P) and established that it doesn't halt. He's
>>>> invoked H
>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>
>>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>>> a thing) is incorrect. Anyone who eyeballs some case and concludes that
>>>> it does not do what it down when actually run has just made a mistake.
>>>> Do you think it's interesting to find out what mistake PO has made when
>>>> guessing what the code does? If so have fun trying to get the code from
>>>> him...
>>>>
>>>> The more interesting (at least at one time) is fact that H is not
>>>> correct since, by definition, H(X,Y) should report on the "halting" of
>>>> the call X(Y).
>>>>
>>>>> It's a very important technique, because it's not always practical
>>>>> or even
>>>>> possible to run a debugger. Even where a debugger is available, often
>>>>> dry-running will reveal bugs in a fraction of the time.
>>>>
>>>> In this case, we have the undisputed fact that P(P) halts, so there's
>>>> really no value in a "dry run" from a debugging perspective.
>>>>
>>>>> In this case, PO has dry run P(P).
>>>>
>>>> And, if that is indeed what he's done (and I don't think it is) he
>>>> knows
>>>> he's made some mistake in his "dry run".
>>>>
>>>>> That is, he has looked at the source, and
>>>>> worked out what it will do.
>>>>
>>>> But, I hope you agree, he's made some mistake or he's been lying
>>>> when re
>>>> reports that P(P) halts.
>>>>
>>>>> Which is to run an infinite sequence of nested
>>>>> emulations. So it won't halt.
>>>>
>>>> The execution of P(P) does not represent an infinite sequence of nested
>>>> simulations. We know that because P(P) halts.
>>>>
>>>>> H(P,P) also reports "non-halting". So this is
>>>>> powerful evidence that H is correct.
>>>>
>>>> Eh? How is some code eyeballing more compelling evidence than the 100%
>>>> undisputed fact that P(P) halts? How is the opinion of someone who
>>>> can't write a parity checking TM powerful evidence of anything?
>>>>
>>>>> However when he actually executes P(P) on hardware, it terminates.
>>>>> Something isn't right.
>>>>
>>>> Yes.
>>>>
>>>>> PO's explanation is that P(P) has different correct behaviour when
>>>>> run and
>>>>> when emulated by H.
>>>>
>>>> That can't be an explanation of anything because, according to you, he
>>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the
>>>> dry run and the actual run must take account of the fact that H is
>>>> (partially) emulating P(P).
>>>>
>>>>> I can think of an obvious alternative explanation which is much
>>>>> simpler and much less far-reaching in its implications. However
>>>>> despite a lot of coaxing, no-one else seems to have arrived at it.
>>>>
>>>> There is nothing here with any far-reaching implications and since I've
>>>> never shared your explanation, I'm not going to look for an
>>>> alternative.
>>>>
>>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
>>>> relying on sophistry. H "aborts" so P never reaches its "ret"
>>>> instruction. That's why P(P) and "the simulation of the inputs to
>>>> H(P,P)" are different. 18 years of work for what? An H that, on the
>>>> basis of his own words, obviously gets the wrong answer.
>>>>
>>> The ordinary semantics of standard C and the conventional x86 language
>>> are the entire semantics required to conclusively prove that H(P,P) does
>>> correctly determine that its correct and complete x86 emulation of its
>>> input would never reach the "ret" instruction (final state) of this
>>> input thus never halts.
>>> That your understanding of the semantics of the x86 language is
>>> insufficient to directly confirm this is less than no rebuttal at all.
>>
>> I assume the semantics of C are defined by the 1989 Standard. The
>> semantics of x86 assembly language are described (not actually
>> authoritatively defined) in other documents. The mapping of C onto
>> the assembly language is far from unique (every compiler could be
>> different) PO appears to using a version of Microsoft's C# compiler.
>>
>
> The COFF object file generated by most any Microsoft C compiler.
> I used Visual Studio 2017 Community Edition.
>
> x86 Instruction Set Reference: https://c9x.me/x86/
>
>> Then we must define how a Turing machine is emulated by a C
>> program. All that is needed of C is the struct  concept and
>> assignment. In that case using C seems unadvisable.
>
> No we don't need this at all. We only need to know that a C function
> that is a pure function of its inputs is Turing equivalent.
>
> https://en.wikipedia.org/wiki/Pure_function
>
> By not using C my five page halt decider becomes hundreds of thousands
> of indecipherable pages of TM description.
>

On 6/24/22 6:58 PM, olcott wrote:
> On 6/24/2022 5:23 PM, Ben Bacarisse wrote:
>> Paul N <gw7rib@aol.com> writes:
>>
>>> You say that "H(P,P) is required to to correctly determine that its
>>> correct and complete x86 emulation of its input would never reach the
>>> "ret" instruction of this input".
>>
>> Can I just check that you know this is not what H is supposed to do?  PO
>> has been searching for some from of words that can stir up enough mud
>> that the fact that H is wrong can be to some extent obscured.  He seems
>> to have hit pay dirt with this latest phrasing.
>>
>> Everyone seem happy to talk to PO on his own terms (and that's fine --
>> it's what he posts for), but in the C-function version of the problem,
>> H(X,Y) != 0 if and only if X(Y) "halts".  I lost interest when he
>> stopped talking about this problem which he knows in not decidable.
>>
>
> It is common knowledge (in computer science) that a halt decider must
> compute the mapping from actual its inputs to an accept or reject state
> on the basis of the actual behavior that is actually specified by its
> actual inputs.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
> THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY.
>

Wrong. If H(P,P) does the correct and complete x86 emulation of its
input, i9t never gives an answer for H(P,P).

Maybe in your mind it makes the dertemination but not return it, but
that isn't the defintion of a decider determinng.

If H(P,P) does make a determination about its simulation of H(P,P) being
non-halting, it does so based on unsound logic, as your logic has it
presume that H DOES a complete and correct emulation, but if it makes
such a determination and returns the non-halting answer, it never did a
complete and correct emulation, so the premise it based its logic on is
refuted.

On 6/24/2022 11:01 PM, Malcolm McLean wrote:
> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> "Dry run" means that a human programmer looks at the code, and determines
>>> what it does, without actually executing it.
>>
>> Going back, now, to what you think needs to be resolved:
>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>> The obvious conclusion is that PO's dry run (if he has indeed done such
>> a thing) is incorrect.
>>
> Exactly.
> We do our little energy budget on tigers, and find that tigers spend more energy
> than they take in. Well potentially this is dynamite. One explanation is that the
> law of conservation of energy is wrong.
> Except, before we countenance that explanation, we need to rule out a much
> simpler explanation. Which is that our measurements are wrong.
>
> Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running
> it, and then actually run P(P) and obtained a different result. He also found that H
> agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive
> and far-reaching in its implications. The behaviour of code when run is different
> from the correct behaviour of the code when simulated. If that's true, then it has
> similar implications for computer science that disproving the conservation law
> has for physics.
>
> But the obvious explanation is that the dry-run was incorrect. Lots of people have
> suggested why it is incorrect. But they can't actually see the code. PO needs to
> understand that no-one will accept the complicated, far-reaching explanation,
> until the simple explanation has been ruled out.

I already proved that the dry run is correct.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 6/24/2022 11:50 PM, dklei...@gmail.com wrote:
> On Friday, June 24, 2022 at 5:12:57 PM UTC-7, olcott wrote:
>> On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:
>>> On Friday, June 24, 2022 at 3:25:59 PM UTC-7, olcott wrote:
>>>> On 6/24/2022 5:16 PM, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>>>>>>> DEFINITION of the behavior of H(P,P),
>>>>>>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>>>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>>>>>>> behavior that is actually specified by these inputs.
>>>>>>>>>>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>>>>>>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>>>>>>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>>>>>>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>>>>>>>>>>> ever before.
>>>>>>>>>>>>>>>> especially if that is what P calls
>>>>>>>>>>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>>>>>>>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>>>>>>>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>>>>>>>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is an actual immutable verified fact.
>>>>>>>>>>>>>
>>>>>>>>>>>> That's your conclusion from your observations and reasoning. You've
>>>>>>>>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>>>>>>>>>>> reports "non-halting". You've run P(P), and it halts. So one
>>>>>>>>>>>> explanation is the one you've given but, as I said, that explanation
>>>>>>>>>>>> has rather far-reaching consequences.
>>>>>>>>>>> There is only one explanation. What you call the "dry-run" is not that
>>>>>>>>>>> same as the P(P). We've known this since the "line 15 commented out"
>>>>>>>>>>> days. There are two computations -- one that is not stopped and one
>>>>>>>>>>> that is, the "dry-run" and the run, the "simulation of the input to
>>>>>>>>>>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>>>>>>>>>>> what's going on.
>>>>>>>>>>>
>>>>>>>>>> I'm a scientists, not a mathematician.
>>>>>>>>>> The example I always use is that you are doing an energy budget for tigers.
>>>>>>>>>> You work how much they use on running about, lactating, maintaining their
>>>>>>>>>> body temperature, and so on.
>>>>>>>>>>
>>>>>>>>>> Now let's say that you find that all results are within a few percentage points
>>>>>>>>>> of a similar budget done for lions. You'd instantly accept this data.
>>>>>>>>>>
>>>>>>>>>> Now let's say that the results are wildly different from a previous budget done
>>>>>>>>>> for lions. You wouldn't just accept that data. You'd check. You'd want to
>>>>>>>>>> understand the reasons tigers spend far less energy on movement than lions.
>>>>>>>>>>
>>>>>>>>>> Now let's say that the result show that tigers use more energy than they
>>>>>>>>>> take in food. Would you instantly conclude that the law of conservation of
>>>>>>>>>> energy must be incorrect?
>>>>>>>>>>
>>>>>>>>>> The third is what PO is doing.
>>>>>>>>> I have no idea what parts of this analogy map to the current situation.
>>>>>>>>> PO has no contradictory results about anything. There's no conflict
>>>>>>>>> with any established facts in anything he is doing.
>>>>>>>>>
>>>>>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
>>>>>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>>>>
>>>>>>>> So something odd is going on there that needs an explanation.
>>>>>>> Then I don't know what you mean by "dry-run" and what needs an
>>>>>>> explanation (for me) is your description of what he's doing. Nothing in
>>>>>>> what PO is doing needs to be explained as far as I can see.
>>>>>>>
>>>>>> "Dry run" means that a human programmer looks at the code, and determines
>>>>>> what it does, without actually executing it.
>>>>>
>>>>> OK. So what value does it have in this case? Do you think PO is
>>>>> competent to "dry run" any code at all?
>>>>>
>>>>> Going back, now, to what you think needs to be resolved:
>>>>>
>>>>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>>>>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>>
>>>>> The obvious conclusion is that PO's dry run (if he has indeed done such
>>>>> a thing) is incorrect. Anyone who eyeballs some case and concludes that
>>>>> it does not do what it down when actually run has just made a mistake.
>>>>> Do you think it's interesting to find out what mistake PO has made when
>>>>> guessing what the code does? If so have fun trying to get the code from
>>>>> him...
>>>>>
>>>>> The more interesting (at least at one time) is fact that H is not
>>>>> correct since, by definition, H(X,Y) should report on the "halting" of
>>>>> the call X(Y).
>>>>>
>>>>>> It's a very important technique, because it's not always practical or even
>>>>>> possible to run a debugger. Even where a debugger is available, often
>>>>>> dry-running will reveal bugs in a fraction of the time.
>>>>>
>>>>> In this case, we have the undisputed fact that P(P) halts, so there's
>>>>> really no value in a "dry run" from a debugging perspective.
>>>>>
>>>>>> In this case, PO has dry run P(P).
>>>>>
>>>>> And, if that is indeed what he's done (and I don't think it is) he knows
>>>>> he's made some mistake in his "dry run".
>>>>>
>>>>>> That is, he has looked at the source, and
>>>>>> worked out what it will do.
>>>>>
>>>>> But, I hope you agree, he's made some mistake or he's been lying when re
>>>>> reports that P(P) halts.
>>>>>
>>>>>> Which is to run an infinite sequence of nested
>>>>>> emulations. So it won't halt.
>>>>>
>>>>> The execution of P(P) does not represent an infinite sequence of nested
>>>>> simulations. We know that because P(P) halts.
>>>>>
>>>>>> H(P,P) also reports "non-halting". So this is
>>>>>> powerful evidence that H is correct.
>>>>>
>>>>> Eh? How is some code eyeballing more compelling evidence than the 100%
>>>>> undisputed fact that P(P) halts? How is the opinion of someone who
>>>>> can't write a parity checking TM powerful evidence of anything?
>>>>>
>>>>>> However when he actually executes P(P) on hardware, it terminates.
>>>>>> Something isn't right.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> PO's explanation is that P(P) has different correct behaviour when run and
>>>>>> when emulated by H.
>>>>>
>>>>> That can't be an explanation of anything because, according to you, he
>>>>> is wrong about the dry run of P(P) and an actual run of P(P). Both the
>>>>> dry run and the actual run must take account of the fact that H is
>>>>> (partially) emulating P(P).
>>>>>
>>>>>> I can think of an obvious alternative explanation which is much
>>>>>> simpler and much less far-reaching in its implications. However
>>>>>> despite a lot of coaxing, no-one else seems to have arrived at it.
>>>>>
>>>>> There is nothing here with any far-reaching implications and since I've
>>>>> never shared your explanation, I'm not going to look for an alternative.
>>>>>
>>>>> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
>>>>> relying on sophistry. H "aborts" so P never reaches its "ret"
>>>>> instruction. That's why P(P) and "the simulation of the inputs to
>>>>> H(P,P)" are different. 18 years of work for what? An H that, on the
>>>>> basis of his own words, obviously gets the wrong answer.
>>>>>
>>>> The ordinary semantics of standard C and the conventional x86 language
>>>> are the entire semantics required to conclusively prove that H(P,P) does
>>>> correctly determine that its correct and complete x86 emulation of its
>>>> input would never reach the "ret" instruction (final state) of this
>>>> input thus never halts.
>>>> That your understanding of the semantics of the x86 language is
>>>> insufficient to directly confirm this is less than no rebuttal at all.
>>>
>>> I assume the semantics of C are defined by the 1989 Standard. The
>>> semantics of x86 assembly language are described (not actually
>>> authoritatively defined) in other documents. The mapping of C onto
>>> the assembly language is far from unique (every compiler could be
>>> different) PO appears to using a version of Microsoft's C# compiler.
>>>
>> The COFF object file generated by most any Microsoft C compiler.
>> I used Visual Studio 2017 Community Edition.
>>
>> x86 Instruction Set Reference: https://c9x.me/x86/
>>> Then we must define how a Turing machine is emulated by a C
>>> program. All that is needed of C is the struct concept and
>>> assignment. In that case using C seems unadvisable.
>>>
>> No we don't need this at all. We only need to know that a C function
>> that is a pure function of its inputs is Turing equivalent.
>>
>> https://en.wikipedia.org/wiki/Pure_function
>
> You are jumping too far in one step. What I am asking is equivalent to:
> Given a Turing Machine how do its steps map into C and thence into x86?
> No C functions are involved.
>