On 6/25/2022 2:24 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>> instruction. An emulation that runs forever, when P(P) does not, is
>> not a correct emulation.
>
> You have missed the magic words. We know a few things for certain about
> PO's ever-so-secret code. One is that whatever it is the latest mantra
> means "the correct simulation of the input to H(P,P)" is not the same as
> the correct simulation of P(P). Why? Well PO is explicitly not talking
> about an H that answers the halting problem, as translated into the
> language of C functions returning.
>
> He hasn't been talking about that for years, but in the past he was too
> clear. He used to say things like "P(P) only halts because..." as if
> the reason excused the wrong answer. He used to say that P(P) halts but
> it would not halt is H didn't stop it (famously "if line 15 were
> commented out"). All was too obvious.
>
> The latest wording is proving more effective at sucking people down the
> rabbit hole.
>

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.

It is provable that the behavior of the correct and complete x86
emulation of the input to H(P,P) never halts and the direct execution of
P(P) halts. H is required to decide on the basis of the former and not
allowed to decide on the basis of the latter unless it is the same as
the former.

These behaviors only diverge when H and P are defined to have this
pathological relationship to each other:

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

None of the textbook authors were aware that these behaviors could
possibly diverge because they never fully considered the effect of a
simulating halt decider applied to the halting problem counter-examples.

--
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/25/2022 2:33 PM, Paul N wrote:
> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>> Paul N <gw7...@aol.com> writes:
>>
>>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>>> instruction. An emulation that runs forever, when P(P) does not, is
>>> not a correct emulation.
>> You have missed the magic words. We know a few things for certain about
>> PO's ever-so-secret code. One is that whatever it is the latest mantra
>> means "the correct simulation of the input to H(P,P)" is not the same as
>> the correct simulation of P(P). Why? Well PO is explicitly not talking
>> about an H that answers the halting problem, as translated into the
>> language of C functions returning.
>>
>> He hasn't been talking about that for years, but in the past he was too
>> clear. He used to say things like "P(P) only halts because..." as if
>> the reason excused the wrong answer. He used to say that P(P) halts but
>> it would not halt is H didn't stop it (famously "if line 15 were
>> commented out"). All was too obvious.
>>
>> The latest wording is proving more effective at sucking people down the
>> rabbit hole.
>
> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>
>>> The correct and complete emulation of the input to H(P,P) has halting
>>> behavior that is provably different than the the direct execution of P(P).
>
>>> "Common sense" tells you that they must be the same empirical proof
>>> proves that they are not the same.
>

Empirical proof is a term that is weaker than the actual proof:

Someone that very recently coached me on how to write formal
mathematical proofs of my claim indicated that I must specify the
precise semantics that I am referencing:

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 predict that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

This same proof shows that P(P) halts.

When we specify the precise semantics the proof gains much more than
mere "empirical" mathematical rigor.

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

int main()
{ P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020

[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]

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

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

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

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

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

--
Copyright 2022 Pete Olcott

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

On 6/25/22 3:15 PM, olcott wrote:
> On 6/25/2022 1:58 PM, Paul N wrote:
>> On Saturday, June 25, 2022 at 6:52:33 PM UTC+1, olcott wrote:
>>> On 6/25/2022 12:21 PM, Paul N wrote:
>>>> On Saturday, June 25, 2022 at 5:29:33 PM UTC+1, olcott wrote:
>>>>> On 6/25/2022 11:19 AM, Paul N wrote:
>>>>>> On Saturday, June 25, 2022 at 3:10:50 PM UTC+1, olcott wrote:
>>>>>>> On 6/25/2022 6:56 AM, Paul N wrote:
>>>>>>>> On Friday, June 24, 2022 at 9:27:27 PM UTC+1, olcott wrote:
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>> Thanks for continuing to review this.
>>>>>>>>>
>>>>>>>>> No assumptions two years of software development derived fully
>>>>>>>>> operational software that conclusively proves this.
>>>>>>>>
>>>>>>>> It might help people's understanding if we had a few more
>>>>>>>> examples. Suppose, in addition to the normal P and H, we have
>>>>>>>> two more functions as follows:
>>>>>>>>
>>>>>>>> void Q(void)
>>>>>>>> {
>>>>>>>> if (H(P, P))
>>>>>>>> H2: goto H2;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> void R(void)
>>>>>>>> {
>>>>>>>> H(P, P);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Will Q return? Will R return?
>>>>>>>>
>>>>>>> Yes they both return.
>>>>>>> void Q(void)
>>>>>>> {
>>>>>>> if (H(P, P))
>>>>>>> H2: goto H2;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> void R(void)
>>>>>>> {
>>>>>>> H(P, P);
>>>>>>> return;
>>>>>>> }
>>>>>>> _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]
>>>>>>>
>>>>>>> _Q()
>>>>>>> [00001210](01) 55 push ebp
>>>>>>> [00001211](02) 8bec mov ebp,esp
>>>>>>> [00001213](05) 68f0110000 push 000011f0
>>>>>>> [00001218](05) 68f0110000 push 000011f0
>>>>>>> [0000121d](05) e8fefdffff call 00001020
>>>>>>> [00001222](03) 83c408 add esp,+08
>>>>>>> [00001225](02) 85c0 test eax,eax
>>>>>>> [00001227](02) 7402 jz 0000122b
>>>>>>> [00001229](02) ebfe jmp 00001229
>>>>>>> [0000122b](01) 5d pop ebp
>>>>>>> [0000122c](01) c3 ret
>>>>>>> Size in bytes:(0029) [0000122c]
>>>>>>>
>>>>>>> _main()
>>>>>>> [00001250](01) 55 push ebp
>>>>>>> [00001251](02) 8bec mov ebp,esp
>>>>>>> [00001253](05) e8b8ffffff call 00001210
>>>>>>> [00001258](02) 33c0 xor eax,eax
>>>>>>> [0000125a](01) 5d pop ebp
>>>>>>> [0000125b](01) c3 ret
>>>>>>> Size in bytes:(0012) [0000125b]
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> ...[00001250][00102048][00000000] 55 push ebp
>>>>>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
>>>>>>> ...[00001253][00102044][00001258] e8b8ffffff call 00001210
>>>>>>> ...[00001210][00102040][00102048] 55 push ebp
>>>>>>> ...[00001211][00102040][00102048] 8bec mov ebp,esp
>>>>>>> ...[00001213][0010203c][000011f0] 68f0110000 push 000011f0
>>>>>>> ...[00001218][00102038][000011f0] 68f0110000 push 000011f0
>>>>>>> ...[0000121d][00102034][00001222] e8fefdffff call 00001020
>>>>>>>
>>>>>>> Begin Simulation Execution Trace Stored at:2120fc
>>>>>>> Address_of_H:1020
>>>>>>> ...[000011f0][002120e8][002120ec] 55 push ebp
>>>>>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
>>>>>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
>>>>>>> ...[000011f6][002120e4][000011f0] 50 push eax
>>>>>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>> ...[000011fa][002120e0][000011f0] 51 push ecx
>>>>>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>> ...[00001222][00102040][00102048] 83c408 add esp,+08
>>>>>>> ...[00001225][00102040][00102048] 85c0 test eax,eax
>>>>>>> ...[00001227][00102040][00102048] 7402 jz 0000122b
>>>>>>> ...[0000122b][00102044][00001258] 5d pop ebp
>>>>>>> ...[0000122c][00102048][00000000] c3 ret
>>>>>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
>>>>>>> ...[0000125a][0010204c][00100000] 5d pop ebp
>>>>>>> ...[0000125b][00102050][00000000] c3 ret
>>>>>>> Number of Instructions Executed(874)
>>>>>>>
>>>>>>> Above is:
>>>>>>> int main()
>>>>>>> {
>>>>>>> Q();
>>>>>>> //R();
>>>>>>> }
>>>>>>>
>>>>>>> ---
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> ...[00001250][00102048][00000000] 55 push ebp
>>>>>>> ...[00001251][00102048][00000000] 8bec mov ebp,esp
>>>>>>> ...[00001253][00102044][00001258] e8d8ffffff call 00001230
>>>>>>> ...[00001230][00102040][00102048] 55 push ebp
>>>>>>> ...[00001231][00102040][00102048] 8bec mov ebp,esp
>>>>>>> ...[00001233][0010203c][000011f0] 68f0110000 push 000011f0
>>>>>>> ...[00001238][00102038][000011f0] 68f0110000 push 000011f0
>>>>>>> ...[0000123d][00102034][00001242] e8defdffff call 00001020
>>>>>>>
>>>>>>> Begin Simulation Execution Trace Stored at:2120fc
>>>>>>> Address_of_H:1020
>>>>>>> ...[000011f0][002120e8][002120ec] 55 push ebp
>>>>>>> ...[000011f1][002120e8][002120ec] 8bec mov ebp,esp
>>>>>>> ...[000011f3][002120e8][002120ec] 8b4508 mov eax,[ebp+08]
>>>>>>> ...[000011f6][002120e4][000011f0] 50 push eax
>>>>>>> ...[000011f7][002120e4][000011f0] 8b4d08 mov ecx,[ebp+08]
>>>>>>> ...[000011fa][002120e0][000011f0] 51 push ecx
>>>>>>> ...[000011fb][002120dc][00001200] e820feffff call 00001020
>>>>>>> Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>> ...[00001242][00102040][00102048] 83c408 add esp,+08
>>>>>>> ...[00001245][00102044][00001258] 5d pop ebp
>>>>>>> ...[00001246][00102048][00000000] c3 ret
>>>>>>> ...[00001258][00102048][00000000] 33c0 xor eax,eax
>>>>>>> ...[0000125a][0010204c][00100000] 5d pop ebp
>>>>>>> ...[0000125b][00102050][00000000] c3 ret
>>>>>>> Number of Instructions Executed(872)
>>>>>>>
>>>>>>> Above is:
>>>>>>> int main()
>>>>>>> {
>>>>>>> //Q();
>>>>>>> R();
>>>>>>> }
>>>>>>
>>>>>> Right, so we're getting somewhere. Can you explain why Q()
>>>>>> returns, and P(P) doesn't, when they both do the same thing in the
>>>>>> same way?
>>>>> int main()
>>>>> {
>>>>> P(P);
>>>>> }
>>>>>
>>>>> does return.
>>>>>
>>>>> The correct and complete x86 emulation of its input by H(P,P)
>>>>> would never reach the "ret" instruction of P because both H and
>>>>> P would remain stuck in infinitely nested emulation.
>>>>
>>>> These last two statements of yours are a contradiction.
>>>>
>>>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>>>> instruction. An emulation that runs forever, when P(P) does not, is
>>>> not a correct emulation.
>>>
>>> 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 predict*
>>> that its correct and complete x86 emulation of its input would never
>>> reach the "ret" instruction (final state) of this input thus never
>>> halts.
>>> The correct and complete x86 emulation of its input by H would never
>>> reach the "ret" instruction of P because both H and P would remain stuck
>>> in infinitely nested emulation.
>>>
>>> I need reviewers like you so that I can *fine tune* my words.
>>
>> If you are saying that P(P) returns, but that a correct and complete
>> x86 emulation of P(P) does not, then I think you are going to have to
>> change either "correct" or "emulation" to some very different word.
>>
>
> The correct and complete emulation of the input to H(P,P) has halting
> behavior that is provably different than the the direct execution of P(P).

On 6/25/22 3:49 PM, olcott wrote:
> On 6/25/2022 2:33 PM, Paul N wrote:
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>>> Paul N <gw7...@aol.com> writes:
>>>
>>>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>>>> instruction. An emulation that runs forever, when P(P) does not, is
>>>> not a correct emulation.
>>> You have missed the magic words. We know a few things for certain about
>>> PO's ever-so-secret code. One is that whatever it is the latest mantra
>>> means "the correct simulation of the input to H(P,P)" is not the same as
>>> the correct simulation of P(P). Why? Well PO is explicitly not talking
>>> about an H that answers the halting problem, as translated into the
>>> language of C functions returning.
>>>
>>> He hasn't been talking about that for years, but in the past he was too
>>> clear. He used to say things like "P(P) only halts because..." as if
>>> the reason excused the wrong answer. He used to say that P(P) halts but
>>> it would not halt is H didn't stop it (famously "if line 15 were
>>> commented out"). All was too obvious.
>>>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>>
>>>> "Common sense" tells you that they must be the same empirical proof
>>>> proves that they are not the same.
>>
>
> Empirical proof is a term that is weaker than the actual proof:
>
> Someone that very recently coached me on how to write formal
> mathematical proofs of my claim indicated that I must specify the
> precise semantics that I am referencing:
>
> 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 predict that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>

But, but this definition, H needs to be a CORRECT emulation of its
input, which means that the emulation of H(P,P) needs to match the
bahavior of an actual call to H(P,P).

Since the conclusion of this argument is that H(P,P) is correctly
returning 0, then for the emulation to actaully be correct, it needs to
match that behavior.

This mean that it CAN NOT appear that H(P,P) never returns in the
correct emulation of the input, but MUST appear as a returning of 0.

> This same proof shows that P(P) halts.
>
> When we specify the precise semantics the proof gains much more than
> mere "empirical" mathematical rigor.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000011f0](01)  55              push ebp
> [000011f1](02)  8bec            mov ebp,esp
> [000011f3](03)  8b4508          mov eax,[ebp+08]
> [000011f6](01)  50              push eax
> [000011f7](03)  8b4d08          mov ecx,[ebp+08]
> [000011fa](01)  51              push ecx
> [000011fb](05)  e820feffff      call 00001020
>
> [00001200](03)  83c408          add esp,+08
> [00001203](02)  85c0            test eax,eax
> [00001205](02)  7402            jz 00001209
> [00001207](02)  ebfe            jmp 00001207
> [00001209](01)  5d              pop ebp
> [0000120a](01)  c3              ret
> Size in bytes:(0027) [0000120a]
>
> _main()
> [00001210](01)  55              push ebp
> [00001211](02)  8bec            mov ebp,esp
> [00001213](05)  68f0110000      push 000011f0
> [00001218](05)  e8d3ffffff      call 000011f0
> [0000121d](03)  83c404          add esp,+04
> [00001220](02)  33c0            xor eax,eax
> [00001222](01)  5d              pop ebp
> [00001223](01)  c3              ret
> Size in bytes:(0020) [00001223]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001210][00101fba][00000000] 55         push ebp
> [00001211][00101fba][00000000] 8bec       mov ebp,esp
> [00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
> [00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
> [000011f0][00101fae][00101fba] 55         push ebp      // enter executed P
> [000011f1][00101fae][00101fba] 8bec       mov ebp,esp
> [000011f3][00101fae][00101fba] 8b4508     mov eax,[ebp+08]
> [000011f6][00101faa][000011f0] 50         push eax      // push P
> [000011f7][00101faa][000011f0] 8b4d08     mov ecx,[ebp+08]
> [000011fa][00101fa6][000011f0] 51         push ecx      // push P
> [000011fb][00101fa2][00001200] e820feffff call 00001020 // call H
>
> Begin Simulation   Execution Trace Stored at:21206e
> Address_of_H:1020
> [000011f0][0021205a][0021205e] 55         push ebp      // enter emulated P
> [000011f1][0021205a][0021205e] 8bec       mov ebp,esp
> [000011f3][0021205a][0021205e] 8b4508     mov eax,[ebp+08]
> [000011f6][00212056][000011f0] 50         push eax      // push P
> [000011f7][00212056][000011f0] 8b4d08     mov ecx,[ebp+08]
> [000011fa][00212052][000011f0] 51         push ecx      // push P
> [000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.

and (b) is proved incorrect from the definition of correctly emulating
an actual call of H(P,P), which is known to return 0 for this case.

> (c) H aborts its emulation of P before its call to H is emulated.

but based on a FALSE assumption about what that emulation would do.

You (b) can ONLY be established based on an assumption that H actually
does a complete and correct emulation, which is broken by the actual
fact that it will abort it simulation.
>
> [00001200][00101fae][00101fba] 83c408     add esp,+08   // return to
> executed P
> [00001203][00101fae][00101fba] 85c0       test eax,eax
> [00001205][00101fae][00101fba] 7402       jz 00001209
> [00001209][00101fb2][0000121d] 5d         pop ebp
> [0000120a][00101fb6][000011f0] c3         ret           // return from
> executed P
> [0000121d][00101fba][00000000] 83c404     add esp,+04
> [00001220][00101fba][00000000] 33c0       xor eax,eax
> [00001222][00101fbe][00100000] 5d         pop ebp
> [00001223][00101fc2][00000000] c3         ret           // ret from main
> Number of Instructions Executed(878) / 67 = 13 pages
>
>

On 6/25/22 3:39 PM, olcott wrote:
> On 6/25/2022 2:24 PM, Ben Bacarisse wrote:
>> Paul N <gw7rib@aol.com> writes:
>>
>>> If P(P) returns, then a CORRECT emulation of it will reach the ret
>>> instruction. An emulation that runs forever, when P(P) does not, is
>>> not a correct emulation.
>>
>> You have missed the magic words.  We know a few things for certain about
>> PO's ever-so-secret code.  One is that whatever it is the latest mantra
>> means "the correct simulation of the input to H(P,P)" is not the same as
>> the correct simulation of P(P).  Why?  Well PO is explicitly not talking
>> about an H that answers the halting problem, as translated into the
>> language of C functions returning.
>>
>> He hasn't been talking about that for years, but in the past he was too
>> clear.  He used to say things like "P(P) only halts because..." as if
>> the reason excused the wrong answer.  He used to say that P(P) halts but
>> it would not halt is H didn't stop it (famously "if line 15 were
>> commented out").  All was too obvious.
>>
>> The latest wording is proving more effective at sucking people down the
>> rabbit hole.
>>
>
> 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.
>
> It is provable that the behavior of the correct and complete x86
> emulation of the input to H(P,P) never halts and the direct execution of
> P(P) halts. H is required to decide on the basis of the former and not
> allowed to decide on the basis of the latter unless it is the same as
> the former.

Which means that P isn't the "impossible program" required by the proof.

P needs to ask H about itself applied to its input.

If H(P,P) isn't that for P(P), then either P isn't defined right to ask
H the proper question, of H isn't interpreeting its input correctly.

Either way, you LIE that you are doing things according to the proof.

>
> These behaviors only diverge when H and P are defined to have this
> pathological relationship to each other:
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> None of the textbook authors were aware that these behaviors could
> possibly diverge because they never fully considered the effect of a
> simulating halt decider applied to the halting problem counter-examples.
>

Because they CAN'T and have H and P meet their actual requirements.

DEFINITION.

If H(P,P) doesn't look at the behavior of P(P), then P should call H
with that sequence, but whatever it needs to do to represent that.

If H can't have an input that represents P(P), then that shows that H
can't correctly decide that problem, and thus fails to be the needed
decider.

Remember, the requriement is to find an H that can decide on all MACHINE
/ INPUT combinations, NOT all "inputs" that can be given to it.

On Sat, 25 Jun 2022 14:39:29 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 2:24 PM, Ben Bacarisse wrote:
> > Paul N <gw7rib@aol.com> writes:
> >
> >> If P(P) returns, then a CORRECT emulation of it will reach the ret
> >> instruction. An emulation that runs forever, when P(P) does not, is
> >> not a correct emulation.
> >
> > You have missed the magic words. We know a few things for certain
> > about PO's ever-so-secret code. One is that whatever it is the
> > latest mantra means "the correct simulation of the input to H(P,P)"
> > is not the same as the correct simulation of P(P). Why? Well PO
> > is explicitly not talking about an H that answers the halting
> > problem, as translated into the language of C functions returning.
> >
> > He hasn't been talking about that for years, but in the past he was
> > too clear. He used to say things like "P(P) only halts because..."
> > as if the reason excused the wrong answer. He used to say that
> > P(P) halts but it would not halt is H didn't stop it (famously "if
> > line 15 were commented out"). All was too obvious.
> >
> > The latest wording is proving more effective at sucking people down
> > the rabbit hole.
> >
>
> 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.
>
> It is provable that the behavior of the correct and complete x86
> emulation of the input to H(P,P) never halts and the direct execution
> of P(P) halts. H is required to decide on the basis of the former and
> not allowed to decide on the basis of the latter unless it is the
> same as the former.

Richard Damon says:

Which means that P isn't the "impossible program" required by the proof.

P needs to ask H about itself applied to its input.

If H(P,P) isn't that for P(P), then either P isn't defined right to ask
H the proper question, of H isn't interpreeting (sic) its input
correctly.

Either way, you LIE that you are doing things according to the proof.

/Flibble

On 6/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

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

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

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

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

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

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:28 PM, Ben Bacarisse wrote:
> Paul N <gw7rib@aol.com> writes:
>
>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>
>>> The latest wording is proving more effective at sucking people down the
>>> rabbit hole.
>>
>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>
>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>> behavior that is provably different than the the direct execution of
>>>> P(P).
>
> Not to diminish the achievement of getting any clear statements from PO,
> but that's not new. I made a note on June 13th that he'd come clean
> about this:
>
> "Before my research no one was aware of the possibility that the
> correctly simulated input to H(P,P) could possibly have behavior that
> is different than the directly executed P(P)."
>

I still stand by that as most probably true.

(a) What I stand by as absolutely true is that the complete and correct
x86 emulation of the input to H(P,P) by H never reaches the "ret"
instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

The above two are proven to be verified facts entirely on the basis of
the semantics of the x86 language.

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

When we know that (a)(b) and (c) are true then it necessarily follows
that anyone saying that H must decide on the basis of the behavior of
P(P) is necessarily incorrect.

--
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/25/2022 6:55 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> 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.
>
> Obviously.
>
>> 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.
>
> He is just waffling. There is no conclusion, just a constant twisting
> and turning to find some why to persuade people that the wrong answer is
> the right one. He's being doing this for years with various degrees of
> obfuscation.
>
> H does not report the correct result for P(P) and PO is putting up
> anything he can think of to keep the discussion going. It should simply
> have stopped once he'd been clear that H(P,P) == 0 is correct "even
> though P(P) halts" but the traces and the verbiage is keeping people keen.
>
>> 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.
>
> When a student comes to me and says that her program to add 5 and 6
> gives 12, I don't, even for a moment, imagine that the laws of logic and
> mathematics are in doubt.
>
>> 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.
>
> For what it's worth, I don't think there is any "dry run" going on here
> at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
> knew (correctly) that H could spot what would happen if H did not
> "intervene". Everything since then -- the "it only halt because...",
> the "it wouldn't halt if line 15 were commented out" and the rather less
> explicitly stated "H_Hat does not get to its ret instruction because a
> non top-level H aborts" are just the various attempt at after-the-fact
> justification.
>
> I agree it's never quite so simple because PO is usually fractally
> wrong, so he's not correct about almost everything he says at almost
> every level. For example, at one level he now admits that a halt
> decider is impossible because H(X,Y) must report "on its input" and the
> call X(Y) is not an input! He did this to explain why H(P,P) is
> permitted to return 0 "even though P(P) halts", but it also makes it
> clear that what he one thought was that halting problem is not solvable.
>

(a) and (b) are proven to be verified facts entirely on the basis of the
semantics of the x86 language. (Most people here do not seem to "believe
in" the semantics of the x86 language otherwise they would have no basis
to disagree).

(a) The complete and correct x86 emulation of the input to H(P,P) by H
never reaches the "ret" instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

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.

P(P) is provably not the actual behavior of the actual input.

--
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 Sat, 25 Jun 2022 20:07:04 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >
> >> 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.
> >
> > Obviously.
> >
> >> 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.
> >
> > He is just waffling. There is no conclusion, just a constant
> > twisting and turning to find some why to persuade people that the
> > wrong answer is the right one. He's being doing this for years
> > with various degrees of obfuscation.
> >
> > H does not report the correct result for P(P) and PO is putting up
> > anything he can think of to keep the discussion going. It should
> > simply have stopped once he'd been clear that H(P,P) == 0 is
> > correct "even though P(P) halts" but the traces and the verbiage is
> > keeping people keen.
> >> 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.
> >
> > When a student comes to me and says that her program to add 5 and 6
> > gives 12, I don't, even for a moment, imagine that the laws of
> > logic and mathematics are in doubt.
> >
> >> 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.
> >
> > For what it's worth, I don't think there is any "dry run" going on
> > here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
> > because he knew (correctly) that H could spot what would happen if
> > H did not "intervene". Everything since then -- the "it only halt
> > because...", the "it wouldn't halt if line 15 were commented out"
> > and the rather less explicitly stated "H_Hat does not get to its
> > ret instruction because a non top-level H aborts" are just the
> > various attempt at after-the-fact justification.
> >
> > I agree it's never quite so simple because PO is usually fractally
> > wrong, so he's not correct about almost everything he says at almost
> > every level. For example, at one level he now admits that a halt
> > decider is impossible because H(X,Y) must report "on its input" and
> > the call X(Y) is not an input! He did this to explain why H(P,P) is
> > permitted to return 0 "even though P(P) halts", but it also makes it
> > clear that what he one thought was that halting problem is not
> > solvable.
>
> (a) and (b) are proven to be verified facts entirely on the basis of
> the semantics of the x86 language. (Most people here do not seem to
> "believe in" the semantics of the x86 language otherwise they would
> have no basis to disagree).
>
> (a) The complete and correct x86 emulation of the input to H(P,P) by
> H never reaches the "ret" instruction of P.
>
> (b) The direct execution of P(P) does reach its "ret" instruction.
>
> 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.
>
> P(P) is provably not the actual behavior of the actual input.
(a) is false as the reason the ret instruction is not reached is
incorrect: the ret instruction should not be reached due to the
infinite loop in P and not because you abort the simulation before the
infinite loop is reached. Your H is incorrect in its assumption that P
is pathological because it calls H.

/Flibble

On 6/25/2022 8:16 PM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 20:07:04 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> 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.
>>>
>>> Obviously.
>>>
>>>> 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.
>>>
>>> He is just waffling. There is no conclusion, just a constant
>>> twisting and turning to find some why to persuade people that the
>>> wrong answer is the right one. He's being doing this for years
>>> with various degrees of obfuscation.
>>>
>>> H does not report the correct result for P(P) and PO is putting up
>>> anything he can think of to keep the discussion going. It should
>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>> correct "even though P(P) halts" but the traces and the verbiage is
>>> keeping people keen.
>>>> 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.
>>>
>>> When a student comes to me and says that her program to add 5 and 6
>>> gives 12, I don't, even for a moment, imagine that the laws of
>>> logic and mathematics are in doubt.
>>>
>>>> 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.
>>>
>>> For what it's worth, I don't think there is any "dry run" going on
>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>> because he knew (correctly) that H could spot what would happen if
>>> H did not "intervene". Everything since then -- the "it only halt
>>> because...", the "it wouldn't halt if line 15 were commented out"
>>> and the rather less explicitly stated "H_Hat does not get to its
>>> ret instruction because a non top-level H aborts" are just the
>>> various attempt at after-the-fact justification.
>>>
>>> I agree it's never quite so simple because PO is usually fractally
>>> wrong, so he's not correct about almost everything he says at almost
>>> every level. For example, at one level he now admits that a halt
>>> decider is impossible because H(X,Y) must report "on its input" and
>>> the call X(Y) is not an input! He did this to explain why H(P,P) is
>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>> clear that what he one thought was that halting problem is not
>>> solvable.
>>
>> (a) and (b) are proven to be verified facts entirely on the basis of
>> the semantics of the x86 language. (Most people here do not seem to
>> "believe in" the semantics of the x86 language otherwise they would
>> have no basis to disagree).
>>
>> (a) The complete and correct x86 emulation of the input to H(P,P) by
>> H never reaches the "ret" instruction of P.
>>
>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>
>> 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.
>>
>> P(P) is provably not the actual behavior of the actual input.
>
> (a) is false as the reason the ret instruction is not reached is
> incorrect: the ret instruction should not be reached due to the
> infinite loop in P and not because you abort the simulation before the
> infinite loop is reached. Your H is incorrect in its assumption that P
> is pathological because it calls H.
>
> /Flibble
>

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

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

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

--
Copyright 2022 Pete Olcott

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

On 6/25/22 8:57 PM, olcott wrote:
> On 6/25/2022 6:28 PM, Ben Bacarisse wrote:
>> Paul N <gw7rib@aol.com> writes:
>>
>>> On Saturday, June 25, 2022 at 8:24:16 PM UTC+1, Ben Bacarisse wrote:
>>
>>>> The latest wording is proving more effective at sucking people down the
>>>> rabbit hole.
>>>
>>> Yes, perhaps I'm wasting my time here. I have got out of him now that:
>>>
>>>>> The correct and complete emulation of the input to H(P,P) has halting
>>>>> behavior that is provably different than the the direct execution of
>>>>> P(P).
>>
>> Not to diminish the achievement of getting any clear statements from PO,
>> but that's not new.  I made a note on June 13th that he'd come clean
>> about this:
>>
>>    "Before my research no one was aware of the possibility that the
>>    correctly simulated input to H(P,P) could possibly have behavior that
>>    is different than the directly executed P(P)."
>>
>
> I still stand by that as most probably true.

but it means that P wasn't built right. Remember P with the special
input given to it is supposed to ask H what P does when given that input.

If H(P,P) doesn't ask what P(P) does, (by that being the behavior of the
input to H(P,P)], then P calling H(P,P) says it was designed wrong, and
you need to change that call in P.

If you can't ask H that question, then H just plain fails, as H is
supposed to be able to be asked about ANY computation (Machine/Input
Combination), and not just what H allows its input to represent.

>
> (a) What I stand by as absolutely true is that the complete and correct
> x86 emulation of the input to H(P,P) by H never reaches the "ret"
> instruction of P.

But only if H actaully DOES a complete and correct x86 emulation of that
input. Which means it can't 'abort' its emulation, and thus can't answer
in finite time until you can show how to do an infinite emulation in
finite steos.

When H aborts its emulation and returns 0, then an actual complete and
correct emulation done by an independent emulator shows it will reach
teh ret instruction, just like P(P) does.

>
> (b) The direct execution of P(P) does reach its "ret" instruction.
>
> The above two are proven to be verified facts entirely on the basis of
> the semantics of the x86 language.
>
> (c) 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.
>

No, a Halt Decider must compute the Halting Mapping, from the
computation represented by its input based on the behavior of that
actual machine specified by its input.

> When we know that (a)(b) and (c) are true then it necessarily follows
> that anyone saying that H must decide on the basis of the behavior of
> P(P) is necessarily incorrect.
>

WHY? You have (c) somewhat backwards. The decider determines the way to
specify the input, but once you accept that the input actually specifies
that machine in question, the behavior of the actual machine is controlling.

Part of your problem is that you keep on trying to define an input that
doesn't actually fully specify the machine. Remember the Computation is
more than just the "C function", but includes all of the algorithms of
everything it calls. Thus by your x86 representation, you need to
include the x86 code of everything it calls.

On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> 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.
>
> Obviously.
>
>> 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.
>
> He is just waffling. There is no conclusion, just a constant twisting
> and turning to find some why to persuade people that the wrong answer is
> the right one. He's being doing this for years with various degrees of
> obfuscation.
>
> H does not report the correct result for P(P) and PO is putting up
> anything he can think of to keep the discussion going. It should simply
> have stopped once he'd been clear that H(P,P) == 0 is correct "even
> though P(P) halts" but the traces and the verbiage is keeping people keen.
>
>> 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.
>
> When a student comes to me and says that her program to add 5 and 6
> gives 12, I don't, even for a moment, imagine that the laws of logic and
> mathematics are in doubt.
>
>> 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.
>
> For what it's worth, I don't think there is any "dry run" going on here
> at all. PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
> knew (correctly) that H could spot what would happen if H did not
> "intervene". Everything since then -- the "it only halt because...",
> the "it wouldn't halt if line 15 were commented out" and the rather less
> explicitly stated "H_Hat does not get to its ret instruction because a
> non top-level H aborts" are just the various attempt at after-the-fact
> justification.
>
> I agree it's never quite so simple because PO is usually fractally
> wrong, so he's not correct about almost everything he says at almost
> every level. For example, at one level he now admits that a halt
> decider is impossible because H(X,Y) must report "on its input" and the
> call X(Y) is not an input! He did this to explain why H(P,P) is
> permitted to return 0 "even though P(P) halts", but it also makes it
> clear that what he one thought was that halting problem is not solvable.
>

YOU KNOW THAT THIS IS TRUE
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.

BECAUSE THIS IS PROVABLY TRUE
P(P) is provably not the actual behavior of the actual input.

YOU ARE THE ONE FUDGING WITH THE TRUTH

--
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 Sat, 25 Jun 2022 20:58:23 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >
> >> 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.
> >
> > Obviously.
> >
> >> 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.
> >
> > He is just waffling. There is no conclusion, just a constant
> > twisting and turning to find some why to persuade people that the
> > wrong answer is the right one. He's being doing this for years
> > with various degrees of obfuscation.
> >
> > H does not report the correct result for P(P) and PO is putting up
> > anything he can think of to keep the discussion going. It should
> > simply have stopped once he'd been clear that H(P,P) == 0 is
> > correct "even though P(P) halts" but the traces and the verbiage is
> > keeping people keen.
> >> 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.
> >
> > When a student comes to me and says that her program to add 5 and 6
> > gives 12, I don't, even for a moment, imagine that the laws of
> > logic and mathematics are in doubt.
> >
> >> 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.
> >
> > For what it's worth, I don't think there is any "dry run" going on
> > here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
> > because he knew (correctly) that H could spot what would happen if
> > H did not "intervene". Everything since then -- the "it only halt
> > because...", the "it wouldn't halt if line 15 were commented out"
> > and the rather less explicitly stated "H_Hat does not get to its
> > ret instruction because a non top-level H aborts" are just the
> > various attempt at after-the-fact justification.
> >
> > I agree it's never quite so simple because PO is usually fractally
> > wrong, so he's not correct about almost everything he says at almost
> > every level. For example, at one level he now admits that a halt
> > decider is impossible because H(X,Y) must report "on its input" and
> > the call X(Y) is not an input! He did this to explain why H(P,P) is
> > permitted to return 0 "even though P(P) halts", but it also makes it
> > clear that what he one thought was that halting problem is not
> > solvable.
>
> YOU KNOW THAT THIS IS TRUE
> 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.
>
> BECAUSE THIS IS PROVABLY TRUE
> P(P) is provably not the actual behavior of the actual input.
>
> YOU ARE THE ONE FUDGING WITH THE TRUTH
The issue is what constitutes a pathological input: the pathological
input at issue here are YOUR PATHOLOGICAL LIES, Olcott.

/Flibble

On 6/25/2022 9:03 PM, Mr Flibble wrote:
> On Sat, 25 Jun 2022 20:58:23 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> 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.
>>>
>>> Obviously.
>>>
>>>> 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.
>>>
>>> He is just waffling. There is no conclusion, just a constant
>>> twisting and turning to find some why to persuade people that the
>>> wrong answer is the right one. He's being doing this for years
>>> with various degrees of obfuscation.
>>>
>>> H does not report the correct result for P(P) and PO is putting up
>>> anything he can think of to keep the discussion going. It should
>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>> correct "even though P(P) halts" but the traces and the verbiage is
>>> keeping people keen.
>>>> 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.
>>>
>>> When a student comes to me and says that her program to add 5 and 6
>>> gives 12, I don't, even for a moment, imagine that the laws of
>>> logic and mathematics are in doubt.
>>>
>>>> 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.
>>>
>>> For what it's worth, I don't think there is any "dry run" going on
>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>> because he knew (correctly) that H could spot what would happen if
>>> H did not "intervene". Everything since then -- the "it only halt
>>> because...", the "it wouldn't halt if line 15 were commented out"
>>> and the rather less explicitly stated "H_Hat does not get to its
>>> ret instruction because a non top-level H aborts" are just the
>>> various attempt at after-the-fact justification.
>>>
>>> I agree it's never quite so simple because PO is usually fractally
>>> wrong, so he's not correct about almost everything he says at almost
>>> every level. For example, at one level he now admits that a halt
>>> decider is impossible because H(X,Y) must report "on its input" and
>>> the call X(Y) is not an input! He did this to explain why H(P,P) is
>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>> clear that what he one thought was that halting problem is not
>>> solvable.
>>
>> YOU KNOW THAT THIS IS TRUE
>> 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.
>>
>> BECAUSE THIS IS PROVABLY TRUE
>> P(P) is provably not the actual behavior of the actual input.
>>
>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>
> The issue is what constitutes a pathological input: the pathological
> input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
>
> /Flibble
>

Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the intuitive
notion of
algorithms, in the sense that a function is computable if there
exists an algorithm
that can do the job of the function, i.e. given an input of the
function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function

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

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

That you reject that the above proves that H and P have a pathological
relationship to each other seem to be your lack of technical competence
rather than dishonesty.

--
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/26/2022 5:14 AM, Malcolm McLean wrote:
> On Sunday, 26 June 2022 at 00:56:03 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> 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.
>> Obviously.
> If the tiger experimenters kick up a fuss about showing you their
> notebooks, when the notebooks are available and there's no logistical
> reason for the refusal, then you can dismiss the idea that they've disproved
> the law of conservation of energy out of hand. The two things, together,
> an impossible claim and a shifty, evasive attitude make up an overwhelming
> case against.

So basically you are utterly clueless that I conclusively proved that
the correct and complete x86 emulation of the input to H(P,P) by H would
never reach its "ret" instruction and the direct execution of P(P) does
reach it "ret" instruction.

You really really believe that I must be wrong yet simply lack the
technical skill to understand the proof that I am right.

I speak verified facts and you and Ben switch to mere rhetoric.

> If they are genuinely co-operative and try to help you, then of course it's
> different. It's still likely that the explanation is an error, but you keep an open
> mind and, if it turns out to be something simple, you try to be as diplomatic
> as possible.
>>
>> I agree it's never quite so simple because PO is usually fractally
>> wrong, so he's not correct about almost everything he says at almost
>> every level. For example, at one level he now admits that a halt
>> decider is impossible because H(X,Y) must report "on its input" and the
>> call X(Y) is not an input! He did this to explain why H(P,P) is
>> permitted to return 0 "even though P(P) halts", but it also makes it
>> clear that what he one thought was that halting problem is not solvable.
>>
> I think he's tied himself in knots trying to avoid the obvious. Which will happen
> if you try to insist that something is true, against all the evidence.

I stick with the verified facts to find the truth and others move toward
mere rhetoric because their purpose is rebuttal and not truth.

A mere lack of software engineering technical competence should result
in questions rather than dogmatic assertions.

--
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 Sun, 26 Jun 2022 05:31:53 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> > On Sat, 25 Jun 2022 20:58:23 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>
> >>>> 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.
> >>>
> >>> Obviously.
> >>>
> >>>> 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.
> >>>
> >>> He is just waffling. There is no conclusion, just a constant
> >>> twisting and turning to find some why to persuade people that the
> >>> wrong answer is the right one. He's being doing this for years
> >>> with various degrees of obfuscation.
> >>>
> >>> H does not report the correct result for P(P) and PO is putting up
> >>> anything he can think of to keep the discussion going. It should
> >>> simply have stopped once he'd been clear that H(P,P) == 0 is
> >>> correct "even though P(P) halts" but the traces and the verbiage
> >>> is keeping people keen.
> >>>> 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.
> >>>
> >>> When a student comes to me and says that her program to add 5 and
> >>> 6 gives 12, I don't, even for a moment, imagine that the laws of
> >>> logic and mathematics are in doubt.
> >>>
> >>>> 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.
> >>>
> >>> For what it's worth, I don't think there is any "dry run" going on
> >>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
> >>> because he knew (correctly) that H could spot what would happen if
> >>> H did not "intervene". Everything since then -- the "it only halt
> >>> because...", the "it wouldn't halt if line 15 were commented out"
> >>> and the rather less explicitly stated "H_Hat does not get to its
> >>> ret instruction because a non top-level H aborts" are just the
> >>> various attempt at after-the-fact justification.
> >>>
> >>> I agree it's never quite so simple because PO is usually fractally
> >>> wrong, so he's not correct about almost everything he says at
> >>> almost every level. For example, at one level he now admits that
> >>> a halt decider is impossible because H(X,Y) must report "on its
> >>> input" and the call X(Y) is not an input! He did this to explain
> >>> why H(P,P) is permitted to return 0 "even though P(P) halts", but
> >>> it also makes it clear that what he one thought was that halting
> >>> problem is not solvable.
> >>
> >> YOU KNOW THAT THIS IS TRUE
> >> 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.
> >>
> >> BECAUSE THIS IS PROVABLY TRUE
> >> P(P) is provably not the actual behavior of the actual input.
> >>
> >> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >
> > The issue is what constitutes a pathological input: the pathological
> > input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
> >
> > /Flibble
> >
>
> Computable functions are the basic objects of study in
> computability theory.
> Computable functions are the formalized analogue of the
> intuitive notion of
> algorithms, in the sense that a function is computable if there
> exists an algorithm
> that can do the job of the function, i.e. given an input of the
> function domain it
> can return the corresponding output.
> https://en.wikipedia.org/wiki/Computable_function
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> That you reject that the above proves that H and P have a
> pathological relationship to each other seem to be your lack of
> technical competence rather than dishonesty.
There is nothing wrong with my technical competence however yours *is*
suspect.

Nobody is denying that P is pathological input as its comes
from [Strachey, 1965]'s "Impossible Program"; the problem is you
are redefining what H means such that P no longer calls H as you prevent
that call which is equivalent to H behaving differently depending on
what is calling it: valid halt deciders don't do that. Your H is
erroneous and certainly *not* a pure function as you claim.

Your basic error (which you keep repeating) is your assumption that a
program that calls H is always pathological.

/Flibble

On 6/26/2022 6:15 AM, Mr Flibble wrote:
> On Sun, 26 Jun 2022 05:31:53 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
>>> On Sat, 25 Jun 2022 20:58:23 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Obviously.
>>>>>
>>>>>> 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.
>>>>>
>>>>> He is just waffling. There is no conclusion, just a constant
>>>>> twisting and turning to find some why to persuade people that the
>>>>> wrong answer is the right one. He's being doing this for years
>>>>> with various degrees of obfuscation.
>>>>>
>>>>> H does not report the correct result for P(P) and PO is putting up
>>>>> anything he can think of to keep the discussion going. It should
>>>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>>>> correct "even though P(P) halts" but the traces and the verbiage
>>>>> is keeping people keen.
>>>>>> 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.
>>>>>
>>>>> When a student comes to me and says that her program to add 5 and
>>>>> 6 gives 12, I don't, even for a moment, imagine that the laws of
>>>>> logic and mathematics are in doubt.
>>>>>
>>>>>> 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.
>>>>>
>>>>> For what it's worth, I don't think there is any "dry run" going on
>>>>> here at all. PO decide years ago that H(H_Hat, H_Hat) would be 0
>>>>> because he knew (correctly) that H could spot what would happen if
>>>>> H did not "intervene". Everything since then -- the "it only halt
>>>>> because...", the "it wouldn't halt if line 15 were commented out"
>>>>> and the rather less explicitly stated "H_Hat does not get to its
>>>>> ret instruction because a non top-level H aborts" are just the
>>>>> various attempt at after-the-fact justification.
>>>>>
>>>>> I agree it's never quite so simple because PO is usually fractally
>>>>> wrong, so he's not correct about almost everything he says at
>>>>> almost every level. For example, at one level he now admits that
>>>>> a halt decider is impossible because H(X,Y) must report "on its
>>>>> input" and the call X(Y) is not an input! He did this to explain
>>>>> why H(P,P) is permitted to return 0 "even though P(P) halts", but
>>>>> it also makes it clear that what he one thought was that halting
>>>>> problem is not solvable.
>>>>
>>>> YOU KNOW THAT THIS IS TRUE
>>>> 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.
>>>>
>>>> BECAUSE THIS IS PROVABLY TRUE
>>>> P(P) is provably not the actual behavior of the actual input.
>>>>
>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
>>>
>>> The issue is what constitutes a pathological input: the pathological
>>> input at issue here are YOUR PATHOLOGICAL LIES, Olcott.
>>>
>>> /Flibble
>>>
>>
>> Computable functions are the basic objects of study in
>> computability theory.
>> Computable functions are the formalized analogue of the
>> intuitive notion of
>> algorithms, in the sense that a function is computable if there
>> exists an algorithm
>> that can do the job of the function, i.e. given an input of the
>> function domain it
>> can return the corresponding output.
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> That you reject that the above proves that H and P have a
>> pathological relationship to each other seem to be your lack of
>> technical competence rather than dishonesty.
>
> There is nothing wrong with my technical competence however yours *is*
> suspect.
>
> Nobody is denying that P is pathological input as its comes
> from [Strachey, 1965]'s "Impossible Program";

// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{ L:if (T(Strachey_P))
goto L;
return;
}

int main()
{ Output("Input_Halts = ", T(Strachey_P));
}

_Strachey_P()
[000015b2](01) 55 push ebp
[000015b3](02) 8bec mov ebp,esp
[000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015ba](05) e813fdffff call 000012d2 // call T
[000015bf](03) 83c404 add esp,+04
[000015c2](02) 85c0 test eax,eax
[000015c4](02) 7402 jz 000015c8
[000015c6](02) ebed jmp 000015b5
[000015c8](01) 5d pop ebp
[000015c9](01) c3 ret
Size in bytes:(0024) [000015c9]

_main()
[000015d2](01) 55 push ebp
[000015d3](02) 8bec mov ebp,esp
[000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
[000015da](05) e8f3fcffff call 000012d2 // call T
[000015df](03) 83c404 add esp,+04
[000015e2](01) 50 push eax
[000015e3](05) 6833040000 push 00000433
[000015e8](05) e895eeffff call 00000482
[000015ed](03) 83c408 add esp,+08
[000015f0](02) 33c0 xor eax,eax
[000015f2](01) 5d pop ebp
[000015f3](01) c3 ret
Size in bytes:(0034) [000015f3]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000015d2][001025c6][00000000] 55 push ebp
[000015d3][001025c6][00000000] 8bec mov ebp,esp
[000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push Strachey_P
[000015da][001025be][000015df] e8f3fcffff call 000012d2 // call T

On 6/25/22 9:36 PM, olcott wrote:
> On 6/25/2022 8:16 PM, Mr Flibble wrote:
>> On Sat, 25 Jun 2022 20:07:04 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>> 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.
>>>>
>>>> Obviously.
>>>>> 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.
>>>>
>>>> He is just waffling.  There is no conclusion, just a constant
>>>> twisting and turning to find some why to persuade people that the
>>>> wrong answer is the right one.  He's being doing this for years
>>>> with various degrees of obfuscation.
>>>>
>>>> H does not report the correct result for P(P) and PO is putting up
>>>> anything he can think of to keep the discussion going.  It should
>>>> simply have stopped once he'd been clear that H(P,P) == 0 is
>>>> correct "even though P(P) halts" but the traces and the verbiage is
>>>> keeping people keen.
>>>>> 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.
>>>>
>>>> When a student comes to me and says that her program to add 5 and 6
>>>> gives 12, I don't, even for a moment, imagine that the laws of
>>>> logic and mathematics are in doubt.
>>>>> 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.
>>>>
>>>> For what it's worth, I don't think there is any "dry run" going on
>>>> here at all.  PO decide years ago that H(H_Hat, H_Hat) would be 0
>>>> because he knew (correctly) that H could spot what would happen if
>>>> H did not "intervene".  Everything since then -- the "it only halt
>>>> because...", the "it wouldn't halt if line 15 were commented out"
>>>> and the rather less explicitly stated "H_Hat does not get to its
>>>> ret instruction because a non top-level H aborts" are just the
>>>> various attempt at after-the-fact justification.
>>>>
>>>> I agree it's never quite so simple because PO is usually fractally
>>>> wrong, so he's not correct about almost everything he says at almost
>>>> every level.  For example, at one level he now admits that a halt
>>>> decider is impossible because H(X,Y) must report "on its input" and
>>>> the call X(Y) is not an input!  He did this to explain why H(P,P) is
>>>> permitted to return 0 "even though P(P) halts", but it also makes it
>>>> clear that what he one thought was that halting problem is not
>>>> solvable.
>>>
>>> (a) and (b) are proven to be verified facts entirely on the basis of
>>> the semantics of the x86 language. (Most people here do not seem to
>>> "believe in" the semantics of the x86 language otherwise they would
>>> have no basis to disagree).
>>>
>>> (a) The complete and correct x86 emulation of the input to H(P,P) by
>>> H never reaches the "ret" instruction of P.
>>>
>>> (b) The direct execution of P(P) does reach its "ret" instruction.
>>>
>>> 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.
>>>
>>> P(P) is provably not the actual behavior of the actual input.
>> (a) is false as the reason the ret instruction is not reached is
>> incorrect: the ret instruction should not be reached due to the
>> infinite loop in P and not because you abort the simulation before the
>> infinite loop is reached.  Your H is incorrect in its assumption that P
>> is pathological because it calls H.
>>
>> /Flibble
>>
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
>

The problem is that your "proof" of (a) is based on an "H" that ONLY
does a complete and correct emulation of its input, before making a
halting decision.

Yes, for such an H, the P built on it will be non-halting, that that H
can't report that fact, and in fact, NEVER reports that ANY non-halting
input is non-halting. That makes it not a decider.

When you fix that problem, by having your new H abort its processing, it
is a DIFFERENT H than the one above. That difference matter, and you new
H is incorrect to consider that its input P, built on it is the same as
the P that was built on the other input H. You seem to be confused
becaue they are both called H.

You claim to be working under the intrepretaton of the C languge. The C
language PROHIBITS the presence of two functions by the same name in one
translation unit, or with global scope in the same program, sine there
is no "H with static scope listed in the file for P, it MUST be a
global scope H, and thus the only H that P can call is the one deciding
on it, which if you claim your H (P,P) is returning 0, must be the one
that aborts, and thus NOT the one that does the complete and correct
emulation and gets stuck in the infinite recursion.

It is also clear that you are lying about H doing a correct x86
emulation of its input, because at the x86 level, the call to H should
create an emulation of the x86 CODE of H, not reverting to some
"functional equivalent" converting it to a notation that it is emulating
P again. Maybe that just shows that YOU don't understand what x86
assembly code actually does. "Call H" does NOT do a emulataion at the
x86 level, it runs an emulator that it should be tracing.

THe fact that (b) shows the x86 assembly code actually does reach its
"ret" instruction means you need to point out where the emulation of the
input and the direct execution diverge, which is at the call H
instruction, which the emulation DOES'T correctly process as pointed
above, and thus your claim of a is shown to be a LIE.

On 6/25/22 9:58 PM, olcott wrote:
> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> 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.
>>
>> Obviously.
>>
>>> 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.
>>
>> He is just waffling.  There is no conclusion, just a constant twisting
>> and turning to find some why to persuade people that the wrong answer is
>> the right one.  He's being doing this for years with various degrees of
>> obfuscation.
>>
>> H does not report the correct result for P(P) and PO is putting up
>> anything he can think of to keep the discussion going.  It should simply
>> have stopped once he'd been clear that H(P,P) == 0 is correct "even
>> though P(P) halts" but the traces and the verbiage is keeping people
>> keen.
>>
>>> 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.
>>
>> When a student comes to me and says that her program to add 5 and 6
>> gives 12, I don't, even for a moment, imagine that the laws of logic and
>> mathematics are in doubt.
>>
>>> 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.
>>
>> For what it's worth, I don't think there is any "dry run" going on here
>> at all.  PO decide years ago that H(H_Hat, H_Hat) would be 0 because he
>> knew (correctly) that H could spot what would happen if H did not
>> "intervene".  Everything since then -- the "it only halt because...",
>> the "it wouldn't halt if line 15 were commented out" and the rather less
>> explicitly stated "H_Hat does not get to its ret instruction because a
>> non top-level H aborts" are just the various attempt at after-the-fact
>> justification.
>>
>> I agree it's never quite so simple because PO is usually fractally
>> wrong, so he's not correct about almost everything he says at almost
>> every level.  For example, at one level he now admits that a halt
>> decider is impossible because H(X,Y) must report "on its input" and the
>> call X(Y) is not an input!  He did this to explain why H(P,P) is
>> permitted to return 0 "even though P(P) halts", but it also makes it
>> clear that what he one thought was that halting problem is not solvable.
>>
>
> YOU KNOW THAT THIS IS TRUE
> 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.
>
> BECAUSE THIS IS PROVABLY TRUE
> P(P) is provably not the actual behavior of the actual input.
>
> YOU ARE THE ONE FUDGING WITH THE TRUTH
>

Then you are lying that P and H are defined as required.

P is defined, that when given a description of itself, to ask H about
itself applied to its input. Since you say P calls H(P,P), it that
doesn't mean H is to decide on P(P), then P wasn't defined correctly,
and YOU made the error.

If H can't be asked about P(P), then H is proven to be defined
incorrectly as H must be able to be asked about ANY compuputation, that
being a program with any input, and P is a program, at least as long as
H meets the requriements for being a program.

Thus, if the input to H(P,P) is proved to have different behaviot than
P(P, you have just proved that your "counter example" fails to meet the
requirements, and thus isn't a counter example.

Thus YOU are the one shown to be not being Truthful, since your own
proof just proves that you lied about other things.

FAIL.

LIAR.

On Sun, 26 Jun 2022 14:40:26 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 6/25/22 9:36 PM, olcott wrote:
> > On 6/25/2022 8:16 PM, Mr Flibble wrote:
> >> On Sat, 25 Jun 2022 20:07:04 -0500
> >> olcott <NoOne@NoWhere.com> wrote:
> >>
> >>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>> 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.
> >>>>
> >>>> Obviously.
> >>>>> 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.
> >>>>
> >>>> He is just waffling.  There is no conclusion, just a constant
> >>>> twisting and turning to find some why to persuade people that the
> >>>> wrong answer is the right one.  He's being doing this for years
> >>>> with various degrees of obfuscation.
> >>>>
> >>>> H does not report the correct result for P(P) and PO is putting
> >>>> up anything he can think of to keep the discussion going.  It
> >>>> should simply have stopped once he'd been clear that H(P,P) == 0
> >>>> is correct "even though P(P) halts" but the traces and the
> >>>> verbiage is keeping people keen.
> >>>>> 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.
> >>>>
> >>>> When a student comes to me and says that her program to add 5
> >>>> and 6 gives 12, I don't, even for a moment, imagine that the
> >>>> laws of logic and mathematics are in doubt.
> >>>>> 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.
> >>>>
> >>>> For what it's worth, I don't think there is any "dry run" going
> >>>> on here at all.  PO decide years ago that H(H_Hat, H_Hat) would
> >>>> be 0 because he knew (correctly) that H could spot what would
> >>>> happen if H did not "intervene".  Everything since then -- the
> >>>> "it only halt because...", the "it wouldn't halt if line 15 were
> >>>> commented out" and the rather less explicitly stated "H_Hat does
> >>>> not get to its ret instruction because a non top-level H aborts"
> >>>> are just the various attempt at after-the-fact justification.
> >>>>
> >>>> I agree it's never quite so simple because PO is usually
> >>>> fractally wrong, so he's not correct about almost everything he
> >>>> says at almost every level.  For example, at one level he now
> >>>> admits that a halt decider is impossible because H(X,Y) must
> >>>> report "on its input" and the call X(Y) is not an input!  He did
> >>>> this to explain why H(P,P) is permitted to return 0 "even though
> >>>> P(P) halts", but it also makes it clear that what he one thought
> >>>> was that halting problem is not solvable.
> >>>
> >>> (a) and (b) are proven to be verified facts entirely on the basis
> >>> of the semantics of the x86 language. (Most people here do not
> >>> seem to "believe in" the semantics of the x86 language otherwise
> >>> they would have no basis to disagree).
> >>>
> >>> (a) The complete and correct x86 emulation of the input to H(P,P)
> >>> by H never reaches the "ret" instruction of P.
> >>>
> >>> (b) The direct execution of P(P) does reach its "ret" instruction.
> >>>
> >>> 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.
> >>>
> >>> P(P) is provably not the actual behavior of the actual input.
> >> (a) is false as the reason the ret instruction is not reached is
> >> incorrect: the ret instruction should not be reached due to the
> >> infinite loop in P and not because you abort the simulation before
> >> the infinite loop is reached.  Your H is incorrect in its
> >> assumption that P is pathological because it calls H.
> >>
> >> /Flibble
> >>
> >
> >      For any program H that might determine if programs halt, a
> > "pathological"
> >      program P, called with some input, can pass its own source
> > and its input to
> >      H and then specifically do the opposite of what H predicts P
> > will do. No H
> >      can exist that handles this case.
> > https://en.wikipedia.org/wiki/Halting_problem
> >
> >
> > void P(u32 x)
> > {
> >   if (H(x, x))
> >     HERE: goto HERE;
> >   return;
> > }
> >
> > int main()
> > {
> >   Output("Input_Halts = ", H((u32)P, (u32)P));
> > }
> >
> >
>
> The problem is that your "proof" of (a) is based on an "H" that ONLY
> does a complete and correct emulation of its input, before making a
> halting decision.
>
> Yes, for such an H, the P built on it will be non-halting, that that
> H can't report that fact, and in fact, NEVER reports that ANY
> non-halting input is non-halting. That makes it not a decider.
>
> When you fix that problem, by having your new H abort its processing,
> it is a DIFFERENT H than the one above. That difference matter, and
> you new H is incorrect to consider that its input P, built on it is
> the same as the P that was built on the other input H. You seem to be
> confused becaue they are both called H.
>
> You claim to be working under the intrepretaton of the C languge. The
> C language PROHIBITS the presence of two functions by the same name
> in one translation unit, or with global scope in the same program,
> sine there is no "H with static scope listed in the file for P, it
> MUST be a global scope H, and thus the only H that P can call is the
> one deciding on it, which if you claim your H (P,P) is returning 0,
> must be the one that aborts, and thus NOT the one that does the
> complete and correct emulation and gets stuck in the infinite
> recursion.
>
> It is also clear that you are lying about H doing a correct x86
> emulation of its input, because at the x86 level, the call to H
> should create an emulation of the x86 CODE of H, not reverting to
> some "functional equivalent" converting it to a notation that it is
> emulating P again. Maybe that just shows that YOU don't understand
> what x86 assembly code actually does. "Call H" does NOT do a
> emulataion at the x86 level, it runs an emulator that it should be
> tracing.
>
> THe fact that (b) shows the x86 assembly code actually does reach its
> "ret" instruction means you need to point out where the emulation of
> the input and the direct execution diverge, which is at the call H
> instruction, which the emulation DOES'T correctly process as pointed
> above, and thus your claim of a is shown to be a LIE.

On Sun, 26 Jun 2022 11:27:06 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/26/2022 6:15 AM, Mr Flibble wrote:
> > On Sun, 26 Jun 2022 05:31:53 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> >>> On Sat, 25 Jun 2022 20:58:23 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>> Obviously.
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>> He is just waffling. There is no conclusion, just a constant
> >>>>> twisting and turning to find some why to persuade people that
> >>>>> the wrong answer is the right one. He's being doing this for
> >>>>> years with various degrees of obfuscation.
> >>>>>
> >>>>> H does not report the correct result for P(P) and PO is putting
> >>>>> up anything he can think of to keep the discussion going. It
> >>>>> should simply have stopped once he'd been clear that H(P,P) => >>>>> 0 is correct "even though P(P) halts" but the traces and the
> >>>>> verbiage is keeping people keen.
> >>>>>> 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.
> >>>>>
> >>>>> When a student comes to me and says that her program to add 5
> >>>>> and 6 gives 12, I don't, even for a moment, imagine that the
> >>>>> laws of logic and mathematics are in doubt.
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>> For what it's worth, I don't think there is any "dry run" going
> >>>>> on here at all. PO decide years ago that H(H_Hat, H_Hat) would
> >>>>> be 0 because he knew (correctly) that H could spot what would
> >>>>> happen if H did not "intervene". Everything since then -- the
> >>>>> "it only halt because...", the "it wouldn't halt if line 15
> >>>>> were commented out" and the rather less explicitly stated
> >>>>> "H_Hat does not get to its ret instruction because a non
> >>>>> top-level H aborts" are just the various attempt at
> >>>>> after-the-fact justification.
> >>>>>
> >>>>> I agree it's never quite so simple because PO is usually
> >>>>> fractally wrong, so he's not correct about almost everything he
> >>>>> says at almost every level. For example, at one level he now
> >>>>> admits that a halt decider is impossible because H(X,Y) must
> >>>>> report "on its input" and the call X(Y) is not an input! He
> >>>>> did this to explain why H(P,P) is permitted to return 0 "even
> >>>>> though P(P) halts", but it also makes it clear that what he one
> >>>>> thought was that halting problem is not solvable.
> >>>>
> >>>> YOU KNOW THAT THIS IS TRUE
> >>>> 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.
> >>>>
> >>>> BECAUSE THIS IS PROVABLY TRUE
> >>>> P(P) is provably not the actual behavior of the actual input.
> >>>>
> >>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >>>
> >>> The issue is what constitutes a pathological input: the
> >>> pathological input at issue here are YOUR PATHOLOGICAL LIES,
> >>> Olcott.
> >>>
> >>> /Flibble
> >>>
> >>
> >> Computable functions are the basic objects of study in
> >> computability theory.
> >> Computable functions are the formalized analogue of the
> >> intuitive notion of
> >> algorithms, in the sense that a function is computable if
> >> there exists an algorithm
> >> that can do the job of the function, i.e. given an input of
> >> the function domain it
> >> can return the corresponding output.
> >> https://en.wikipedia.org/wiki/Computable_function
> >>
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)P, (u32)P));
> >> }
> >>
> >> That you reject that the above proves that H and P have a
> >> pathological relationship to each other seem to be your lack of
> >> technical competence rather than dishonesty.
> >
> > There is nothing wrong with my technical competence however yours
> > *is* suspect.
> >
> > Nobody is denying that P is pathological input as its comes
> > from [Strachey, 1965]'s "Impossible Program";
>
> // rec routine P
> // §L :if T[P] go to L
> // Return §
> // https://academic.oup.com/comjnl/article/7/4/313/354243
> void Strachey_P()
> {
> L:if (T(Strachey_P))
> goto L;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", T(Strachey_P));
> }
>
> _Strachey_P()
> [000015b2](01) 55 push ebp
> [000015b3](02) 8bec mov ebp,esp
> [000015b5](05) 68b2150000 push 000015b2 // push Strachey_P
> [000015ba](05) e813fdffff call 000012d2 // call T
> [000015bf](03) 83c404 add esp,+04
> [000015c2](02) 85c0 test eax,eax
> [000015c4](02) 7402 jz 000015c8
> [000015c6](02) ebed jmp 000015b5
> [000015c8](01) 5d pop ebp
> [000015c9](01) c3 ret
> Size in bytes:(0024) [000015c9]
>
> _main()
> [000015d2](01) 55 push ebp
> [000015d3](02) 8bec mov ebp,esp
> [000015d5](05) 68b2150000 push 000015b2 // push Strachey_P
> [000015da](05) e8f3fcffff call 000012d2 // call T
> [000015df](03) 83c404 add esp,+04
> [000015e2](01) 50 push eax
> [000015e3](05) 6833040000 push 00000433
> [000015e8](05) e895eeffff call 00000482
> [000015ed](03) 83c408 add esp,+08
> [000015f0](02) 33c0 xor eax,eax
> [000015f2](01) 5d pop ebp
> [000015f3](01) c3 ret
> Size in bytes:(0034) [000015f3]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> [000015d2][001025c6][00000000] 55 push ebp
> [000015d3][001025c6][00000000] 8bec mov ebp,esp
> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 // push
> Strachey_P [000015da][001025be][000015df] e8f3fcffff call 000012d2 //
> call T
>
> Begin Simulation Execution Trace Stored at:21267a
> Address_of_T:12d2
> [000015b2][0021266a][0021266e] 55 push ebp
> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 // push
> Strachey_P [000015ba][00212662][000015bf] e813fdffff call 000012d2 //
> call T Infinitely Recursive Simulation Detected Simulation Stopped
>
> T knows its own machine address and on this basis it can easily
> examine its stored execution_trace of Strachey_P (see above) to
> determine: (a) Strachey_P is calling T with the same arguments that T
> was called with. (b) No instructions in Strachey_P could possibly
> escape this otherwise infinitely recursive emulation.

On Sun, 26 Jun 2022 14:56:02 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 6/25/22 9:58 PM, olcott wrote:
> > On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>
> >>> 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.
> >>
> >> Obviously.
> >>
> >>> 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.
> >>
> >> He is just waffling.  There is no conclusion, just a constant
> >> twisting and turning to find some why to persuade people that the
> >> wrong answer is the right one.  He's being doing this for years
> >> with various degrees of obfuscation.
> >>
> >> H does not report the correct result for P(P) and PO is putting up
> >> anything he can think of to keep the discussion going.  It should
> >> simply have stopped once he'd been clear that H(P,P) == 0 is
> >> correct "even though P(P) halts" but the traces and the verbiage
> >> is keeping people keen.
> >>
> >>> 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.
> >>
> >> When a student comes to me and says that her program to add 5 and 6
> >> gives 12, I don't, even for a moment, imagine that the laws of
> >> logic and mathematics are in doubt.
> >>
> >>> 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.
> >>
> >> For what it's worth, I don't think there is any "dry run" going on
> >> here at all.  PO decide years ago that H(H_Hat, H_Hat) would be 0
> >> because he knew (correctly) that H could spot what would happen if
> >> H did not "intervene".  Everything since then -- the "it only halt
> >> because...", the "it wouldn't halt if line 15 were commented out"
> >> and the rather less explicitly stated "H_Hat does not get to its
> >> ret instruction because a non top-level H aborts" are just the
> >> various attempt at after-the-fact justification.
> >>
> >> I agree it's never quite so simple because PO is usually fractally
> >> wrong, so he's not correct about almost everything he says at
> >> almost every level.  For example, at one level he now admits that
> >> a halt decider is impossible because H(X,Y) must report "on its
> >> input" and the call X(Y) is not an input!  He did this to explain
> >> why H(P,P) is permitted to return 0 "even though P(P) halts", but
> >> it also makes it clear that what he one thought was that halting
> >> problem is not solvable.
> >
> > YOU KNOW THAT THIS IS TRUE
> > 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.
> >
> > BECAUSE THIS IS PROVABLY TRUE
> > P(P) is provably not the actual behavior of the actual input.
> >
> > YOU ARE THE ONE FUDGING WITH THE TRUTH
> >
>
> Then you are lying that P and H are defined as required.
>
> P is defined, that when given a description of itself, to ask H about
> itself applied to its input. Since you say P calls H(P,P), it that
> doesn't mean H is to decide on P(P), then P wasn't defined correctly,
> and YOU made the error.
>
> If H can't be asked about P(P), then H is proven to be defined
> incorrectly as H must be able to be asked about ANY compuputation,
> that being a program with any input, and P is a program, at least as
> long as H meets the requriements for being a program.
>
> Thus, if the input to H(P,P) is proved to have different behaviot
> than P(P, you have just proved that your "counter example" fails to
> meet the requirements, and thus isn't a counter example.
>
> Thus YOU are the one shown to be not being Truthful, since your own
> proof just proves that you lied about other things.
>
> FAIL.
>
> LIAR.

If I reply to you Olcott will see your post. :)

/Flibble