On 25/07/2022 01:18, olcott wrote:
> On 7/24/2022 6:50 PM, Mike Terry wrote:
>> On 24/07/2022 20:11, olcott wrote:
>>> On 7/24/2022 1:03 PM, Mike Terry wrote:
>>>> On 24/07/2022 18:54, olcott wrote:
>>>>> On 7/24/2022 12:32 PM, Mike Terry wrote:
>>>>>> On 24/07/2022 16:08, olcott wrote:
>>>>>>> On 7/24/2022 9:49 AM, Mike Terry wrote:
>>>>>>>> On 24/07/2022 13:26, Mikko wrote:
>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86 question for you, what is the
>>>>>>>>>>> first instruction executed in P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [000013c6](01)  55         push ebp               // Save Base Pointer register onto the
>>>>>>>>>> stack
>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load Base Pointer with Stack Pointer
>>>>>>>>>> [000013c9](01)  51         push ecx               // Save the value of ecx on the stack
>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load eax with argument to P
>>>>>>>>>> [000013cd](01)  50         push eax               // push 2nd argument to H onto the stack
>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load ecx with with argument to P
>>>>>>>>>> [000013d1](01)  51         push ecx               // push 1st argument to H onto the stack
>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push return address on the stack;
>>>>>>>>>> call simulated H
>>>>>>>>
>>>>>>>> um, H here is not simulated, it's directly called by P.
>>>>>>>>
>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            // remove call arguments from stack
>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load Halt_Status with return value
>>>>>>>>>> from H
>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare Halt_Status to 0
>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if Halt_Status == 0 goto 000013e5
>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load Stack Pointer with Base Pointer
>>>>>>>>>> [000013e7](01)  5d         pop ebp                // Restore Base Pointer value from stack
>>>>>>>>>> [000013e8](01)  c3         ret                    // return to caller
>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>
>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>
>>>>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>>>>> In particular, that the immediately preceding instruction is
>>>>>>>>> the same?
>>>>>>>>>
>>>>>>>>> Mikko
>>>>>>>>>
>>>>>>>>
>>>>>>>> In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the first call to H.  That is
>>>>>>>> obviously not the last step of the computation, as we can see by looking at the trace of
>>>>>>>> P(P) [native]:
>>>>>>>>
>>>>>>>> [Native P(P): summary of execution + simulations]
>>>>>>>> P(P)
>>>>>>>>      H(P,P)
>>>>>>>>      [#SIMULATION...]
>>>>>>>>      P(P)
>>>>>>>>          H(P,P)
>>>>>>>>      [#STOP SIMULATING]
>>>>>>>>      H ret 0 [non-halting]
>>>>>>>> P ret [P(P) halts]
>>>>>>>>
>>>>>>>> For "H simulating its input (P,P)" PO is just counting the lines above between
>>>>>>>> "#SIMULATION..." and "#STOP SIMULATING":
>>>>>>>>
>>>>>>>> [H's simulation of P(P): summary of execution + simulations]
>>>>>>>> P(P)
>>>>>>>>      H(P,P)
>>>>>>>> er that's it - Simulator has given up simulating!!
>>>>>>>>
>>>>>>>> Claiming the computations are "a different sequence of instructions" is completely
>>>>>>>> misleading, as the sequence is exactly the same in both cases, other than H decides to give
>>>>>>>> up simulating at an early point in the sequence,
>>>>>>>
>>>>>>> That is not true.
>>>>>>
>>>>>> What exactly is not true?  Whether your claim is misleading or not is a matter of opinion, not
>>>>>> verifiable truth.
>>>>>>
>>>>>> Do you agree with the factual points I made:  "the sequence is exactly the same in both cases,
>>>>>> other than H decides to give up simulating at an earlier point in the sequence" ?
>>>>>>
>>>>>> Mike.
>>>>>
>>>>> No I do not agree.
>>>>>
>>>>
>>>> Ok, the way to resolve this is for you to present both sequences:
>>>>
>>>> A)  sequence of instructions for P(P) direct call
>>>> B)  sequence of (emulated) instructions for H's simulation of P(P)
>>>>
>>>> Since you have both of these to hand, it wouldn't be much effort for you to supply the traces...
>>>> (Be sure to keep code addresses common across the two traces to make comparisons straight
>>>> forward...)
>>>>
>>>> Regards,
>>>> Mike.
>>>
>>> I have already done that 30 times now.
>>
>> Then it will be easy for you to cut and paste it again, right.  Except that you have never
>> directly presented the two comparisons.
>>
>
> Sure I have you just didn't bother to pay enough attention.
> The execution trace of P(P) includes the execution trace of the correctly simulated input to H(P,P)
> is at the end of this post.
>

I've commented previously on that trace, pointing out that the instruction sequences for P(P) and
H's simulation of P(P) are EXACTLY THE SAME - up to the point where H stops its simulation. It
seems you didn't agree with that, but weren't paying enough attention at the time.

Still, let's spell it out using your output below. Here's the trace output copied from below, with
line numbers added for reference:

-------------------
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
1 [0000146b][00102428][00000000] 55 push ebp
2 [0000146c][00102428][00000000] 8bec mov ebp,esp
3 [0000146e][00102424][0000143b] 683b140000 push 0000143b // push P
4 [00001473][00102420][00001478] e8c3ffffff call 0000143b // call P with argument on stack
5 [0000143b][0010241c][00102428] 55 push ebp // enter executed P
6 [0000143c][0010241c][00102428] 8bec mov ebp,esp
7 [0000143e][00102418][00000000] 51 push ecx
8 [0000143f][00102418][00000000] 8b4508 mov eax,[ebp+08] // load eax with argument to P
9 [00001442][00102414][0000143b] 50 push eax // push P from eax
10 [00001443][00102414][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx with argument to P
11 [00001446][00102410][0000143b] 51 push ecx // push P from ecx
12 [00001447][0010240c][0000144c] e8affcffff call 000010fb // call executed H with arguments on stack

On 7/25/2022 10:37 AM, Todor Genov wrote:
> On Monday, 25 July 2022 at 17:33:21 UTC+2, olcott wrote:
>> Nothing like that.
>> D:\>x86utm Halt7.obj
>> executes Halt7.c main()
>
> Which means what? You've confused yourself in a million abstractions.
>
> What does it mean if x86utm returns 0?
> What does it mean if x86utm returns 1?

When x86utm returns that means you are back to the command line prompt:
D:\>

x86utm is an operating system that executes the COFF object file output
from the Microsoft C compiler.

--
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 7/25/2022 10:43 AM, Skep Dick wrote:
> On Monday, 25 July 2022 at 17:33:21 UTC+2, olcott wrote:
>> Nothing like that.
>> D:\>x86utm Halt7.obj
>> executes Halt7.c main()
>
> All of those abstraction layers are not necessary.
>
> What is the meaning of x86utm(Halt7.obj) ?
>

gibberish

> What does it mean if x86utm(Halt7.obj) returns 0?
> What does it mean if x86utm(Halt7.obj) returns 1?
>
>

--
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 2022-07-25 15:20:02 +0000, olcott said:

> On 7/25/2022 10:14 AM, Mikko wrote:
>> On 2022-07-25 13:49:20 +0000, olcott said:
>>
>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>
>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>
>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86 question for
>>>>>>>>>> you, what is the first instruction executed in P(P) that differs from
>>>>>>>>>> the correct simulation of H(P,P)?
>>>>>>>>>
>>>
>>> _P()
>>> [000013c6](01)  55         push ebp
>>> [000013c7](02)  8bec       mov ebp,esp
>>> [000013c9](01)  51         push ecx
>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>> [000013cd](01)  50         push eax
>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>> [000013d1](01)  51         push ecx
>>> [000013d2](05)  e82ffdffff call 00001106
>>> [000013d7](03)  83c408     add esp,+08
>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>> [000013e1](02)  7402       jz 000013e5
>>> [000013e3](02)  ebfe       jmp 000013e3
>>> [000013e5](02)  8be5       mov esp,ebp
>>> [000013e7](01)  5d         pop ebp
>>> [000013e8](01)  c3         ret
>>> Size in bytes:(0035) [000013e8]
>>>
>>>
>>>>> We have to do this at the C level.
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>> }
>>>>>
>>>>> (a) H(P,P) simulates its input
>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>
>>>>> *Can you see the repeating pattern* ?
>>>>
>>>> Yes, but I cannot see any answer to any of my questions.
>>>>
>>>> Can you prove that 13d7 is the first differeing instruction?
>>>> In particular, that the immediately preceding instruction is
>>>> the same?
>>>>
>>>> Mikko
>>>>
>>>
>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>> The source-code of P specifies that the next instruction after machine
>>> address 13d2 when H returns to P for P(P) is 13d7.
>>>
>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>> The source-code of P specifies the next machine address for the
>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>
>> Wrong. In both cases P is the same so therefore specifies the same.
>> The difference seems to be that in the second case the instruction
>> H(P,P) is not simulated correctly as a call to a decider.
>>
>> Mikko
>>
>
> You can assume that I am wrong by making sure to not even look at the
> proof that I am correct.

Wrong. I didn't assume that you are wrong. I presented a sentence that
is true because of the meaning of the words. You have not found anything
wrong in that sentence.

Mikko

On Monday, 25 July 2022 at 18:36:58 UTC+2, olcott wrote:
> When x86utm returns that means you are back to the command line prompt:
> D:\>
> x86utm is an operating system that executes the COFF object file output
> from the Microsoft C compiler.

This is not an answer.

x86utm is just another computable function which takes some input and produce some outputs.
The outputs of x86utm are its status/error codes ( https://ss64.com/nt/errorlevel.html ) - it's no different to any other function which returns an integer.
You can trivially obtain the status code of the function call x86utm(Halt7.obj) with the command "echo %errorlevel%"

When H(P) returns 1 it means P halts.
When H(P) returns 0 it means P doesn't halt.

What does it mean if x86utm(Halt7.obj) returns 0?
What does it mean if x86utm(Halt7.obj) returns 1?

On 7/25/2022 11:47 AM, Mikko wrote:
> On 2022-07-25 15:20:02 +0000, olcott said:
>
>> On 7/25/2022 10:14 AM, Mikko wrote:
>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>
>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>
>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>
>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>
>>>>
>>>> _P()
>>>> [000013c6](01)  55         push ebp
>>>> [000013c7](02)  8bec       mov ebp,esp
>>>> [000013c9](01)  51         push ecx
>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>> [000013cd](01)  50         push eax
>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>> [000013d1](01)  51         push ecx
>>>> [000013d2](05)  e82ffdffff call 00001106
>>>> [000013d7](03)  83c408     add esp,+08
>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>> [000013e1](02)  7402       jz 000013e5
>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>> [000013e5](02)  8be5       mov esp,ebp
>>>> [000013e7](01)  5d         pop ebp
>>>> [000013e8](01)  c3         ret
>>>> Size in bytes:(0035) [000013e8]
>>>>
>>>>
>>>>>> We have to do this at the C level.
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    int Halt_Status = H(x, x);
>>>>>>    if (Halt_Status)
>>>>>>      HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>> }
>>>>>>
>>>>>> (a) H(P,P) simulates its input
>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>
>>>>>> *Can you see the repeating pattern* ?
>>>>>
>>>>> Yes, but I cannot see any answer to any of my questions.
>>>>>
>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>> In particular, that the immediately preceding instruction is
>>>>> the same?
>>>>>
>>>>> Mikko
>>>>>
>>>>
>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>> The source-code of P specifies that the next instruction after
>>>> machine address 13d2 when H returns to P for P(P) is 13d7.
>>>>
>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>> The source-code of P specifies the next machine address for the
>>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>>
>>> Wrong. In both cases P is the same so therefore specifies the same.
>>> The difference seems to be that in the second case the instruction
>>> H(P,P) is not simulated correctly as a call to a decider.
>>>
>>> Mikko
>>>
>>
>> You can assume that I am wrong by making sure to not even look at the
>> proof that I am correct.
>
> Wrong. I didn't assume that you are wrong. I presented a sentence that
> is true because of the meaning of the words. You have not found anything
> wrong in that sentence.
>
> Mikko
>

The behavior of P when directly executed is different than the behavior
of P when correctly simulated by H even though each case uses the exact
same machine-code for P. This is an established fact thus disbelieving
this in incorrect.

Example 05 proves that these two behaviors are different and shows that
they have different sequences of instructions.

The correctly simulated input to H(P,P) calls H(P,P) in infinite
recursion thus H never returns to P and P never reaches its own "return"
statement. The directly executed P(P) calls H(P,P) *not* in infinite
recursion thus H(P,P) returns to 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 7/25/2022 12:20 PM, Skep Dick wrote:
> On Monday, 25 July 2022 at 18:36:58 UTC+2, olcott wrote:
>> When x86utm returns that means you are back to the command line prompt:
>> D:\>
>> x86utm is an operating system that executes the COFF object file output
>> from the Microsoft C compiler.
>
> This is not an answer.
>
> x86utm is just another computable function which takes some input and produce some outputs.
> The outputs of x86utm are its status/error codes ( https://ss64.com/nt/errorlevel.html ) - it's no different to any other function which returns an integer.
> You can trivially obtain the status code of the function call x86utm(Halt7.obj) with the command "echo %errorlevel%"
>
> When H(P) returns 1 it means P halts.
> When H(P) returns 0 it means P doesn't halt.
>
> What does it mean if x86utm(Halt7.obj) returns 0?
> What does it mean if x86utm(Halt7.obj) returns 1?
>

Here is what x86utm returns:

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

--
Copyright 2022 Pete Olcott

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

On 7/25/22 9:49 AM, olcott wrote:
> On 7/25/2022 6:02 AM, Mikko wrote:
>> On 2022-07-24 20:03:29 +0000, olcott said:
>>
>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>
>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>
>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>> question for you, what is the first instruction executed in P(P)
>>>>>>>> that differs from the correct simulation of H(P,P)?
>>>>>>>
>
> _P()
> [000013c6](01)  55         push ebp
> [000013c7](02)  8bec       mov ebp,esp
> [000013c9](01)  51         push ecx
> [000013ca](03)  8b4508     mov eax,[ebp+08]
> [000013cd](01)  50         push eax
> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
> [000013d1](01)  51         push ecx
> [000013d2](05)  e82ffdffff call 00001106
> [000013d7](03)  83c408     add esp,+08
> [000013da](03)  8945fc     mov [ebp-04],eax
> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
> [000013e1](02)  7402       jz 000013e5
> [000013e3](02)  ebfe       jmp 000013e3
> [000013e5](02)  8be5       mov esp,ebp
> [000013e7](01)  5d         pop ebp
> [000013e8](01)  c3         ret
> Size in bytes:(0035) [000013e8]
>
>
>>> We have to do this at the C level.
>>>
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ",  H(P, P));
>>> }
>>>
>>> (a) H(P,P) simulates its input
>>> (b) P calls H(P,P) to simulate itself *again*
>>> (c) H(P,P) would simulate its input if it does what P asks
>>> (d) P calls H(P,P) to simulate itself *again*
>>> (e) H(P,P) would simulate its input if it does what P asks
>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>
>>> *Can you see the repeating pattern* ?
>>
>> Yes, but I cannot see any answer to any of my questions.
>>
>> Can you prove that 13d7 is the first differeing instruction?
>> In particular, that the immediately preceding instruction is
>> the same?
>>
>> Mikko
>>
>
> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
> The source-code of P specifies that the next instruction after machine
> address 13d2 when H returns to P for P(P) is 13d7.
>
> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
> The source-code of P specifies the next machine address for the
> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)

Which is a MEANINGLESS Statement as H's simulation of P IS aborted,
which cause an P(P) that calls H(P,P) to Halt.

Thus P(P) is a Halting computation, an H(P,P) returning 0 to be INCORRECT.

If H(P,P) doesn;t refer to P(P), then you are just lying abou following
the definitions of the Halting Problem and NOTHING you have said has any
validity.

You can't base a sound conclusion on a premise that isn't true.

Since H(P,P) DOES abort its simullation of P(P), any logic based on H
not aborting it is just unsound.

>
>
> Example 03 show more details of the latter case.
> Halting problem proofs refuted on the basis of software engineering ?
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>
> 13d7
> 13c6
>
>

On 7/25/22 11:20 AM, olcott wrote:
> On 7/25/2022 10:14 AM, Mikko wrote:
>> On 2022-07-25 13:49:20 +0000, olcott said:
>>
>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>
>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>
>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>
>>>
>>> _P()
>>> [000013c6](01)  55         push ebp
>>> [000013c7](02)  8bec       mov ebp,esp
>>> [000013c9](01)  51         push ecx
>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>> [000013cd](01)  50         push eax
>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>> [000013d1](01)  51         push ecx
>>> [000013d2](05)  e82ffdffff call 00001106
>>> [000013d7](03)  83c408     add esp,+08
>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>> [000013e1](02)  7402       jz 000013e5
>>> [000013e3](02)  ebfe       jmp 000013e3
>>> [000013e5](02)  8be5       mov esp,ebp
>>> [000013e7](01)  5d         pop ebp
>>> [000013e8](01)  c3         ret
>>> Size in bytes:(0035) [000013e8]
>>>
>>>
>>>>> We have to do this at the C level.
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>> }
>>>>>
>>>>> (a) H(P,P) simulates its input
>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>
>>>>> *Can you see the repeating pattern* ?
>>>>
>>>> Yes, but I cannot see any answer to any of my questions.
>>>>
>>>> Can you prove that 13d7 is the first differeing instruction?
>>>> In particular, that the immediately preceding instruction is
>>>> the same?
>>>>
>>>> Mikko
>>>>
>>>
>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>> The source-code of P specifies that the next instruction after
>>> machine address 13d2 when H returns to P for P(P) is 13d7.
>>>
>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>> The source-code of P specifies the next machine address for the
>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>
>> Wrong. In both cases P is the same so therefore specifies the same.
>> The difference seems to be that in the second case the instruction
>> H(P,P) is not simulated correctly as a call to a decider.
>>
>> Mikko
>>
>
> You can assume that I am wrong by making sure to not even look at the
> proof that I am correct. The actual execution trace showed in example 05
> at the end of the paper proves that P(P) stops running and the correctly
> simulated input to H(P,P) never stops running unless aborted.

But since the defined H(P,P) deos abort, that is a meaningless statement.

The definition of Halting is based on the machine, not the simulation.

>
> *Halting problem proofs refuted on the basis of software engineering* ?
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>
>

On 7/25/22 4:09 PM, olcott wrote:
> On 7/25/2022 11:47 AM, Mikko wrote:
>> On 2022-07-25 15:20:02 +0000, olcott said:
>>
>>> On 7/25/2022 10:14 AM, Mikko wrote:
>>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>>
>>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>>
>>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>
>>>>>
>>>>> _P()
>>>>> [000013c6](01)  55         push ebp
>>>>> [000013c7](02)  8bec       mov ebp,esp
>>>>> [000013c9](01)  51         push ecx
>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>>> [000013cd](01)  50         push eax
>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>>> [000013d1](01)  51         push ecx
>>>>> [000013d2](05)  e82ffdffff call 00001106
>>>>> [000013d7](03)  83c408     add esp,+08
>>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>>> [000013e1](02)  7402       jz 000013e5
>>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>>> [000013e5](02)  8be5       mov esp,ebp
>>>>> [000013e7](01)  5d         pop ebp
>>>>> [000013e8](01)  c3         ret
>>>>> Size in bytes:(0035) [000013e8]
>>>>>
>>>>>
>>>>>>> We have to do this at the C level.
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> (a) H(P,P) simulates its input
>>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>>
>>>>>>> *Can you see the repeating pattern* ?
>>>>>>
>>>>>> Yes, but I cannot see any answer to any of my questions.
>>>>>>
>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>> In particular, that the immediately preceding instruction is
>>>>>> the same?
>>>>>>
>>>>>> Mikko
>>>>>>
>>>>>
>>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>>> The source-code of P specifies that the next instruction after
>>>>> machine address 13d2 when H returns to P for P(P) is 13d7.
>>>>>
>>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>>> The source-code of P specifies the next machine address for the
>>>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>>>
>>>> Wrong. In both cases P is the same so therefore specifies the same.
>>>> The difference seems to be that in the second case the instruction
>>>> H(P,P) is not simulated correctly as a call to a decider.
>>>>
>>>> Mikko
>>>>
>>>
>>> You can assume that I am wrong by making sure to not even look at the
>>> proof that I am correct.
>>
>> Wrong. I didn't assume that you are wrong. I presented a sentence that
>> is true because of the meaning of the words. You have not found anything
>> wrong in that sentence.
>>
>> Mikko
>>
>
> The behavior of P when directly executed is different than the behavior
> of P when correctly simulated by H even though each case uses the exact
> same machine-code for P. This is an established fact thus disbelieving
> this in incorrect.

Only bcauase H uses an INCORRECT detemination of what the copy of H
called by P will do.

We KNOW, from the trace that H(P,P) returns 0, so until you can show why
the H(P,P) called by P would behave differently, H is just using
incorrect simulation and/or UNSOUND logic.

> Example 05 proves that these two behaviors are different and shows that
> they have different sequences of instructions.
>
> The correctly simulated input to H(P,P) calls H(P,P) in infinite
> recursion thus H never returns to P and P never reaches its own "return"
> statement. The directly executed P(P) calls H(P,P) *not* in infinite
> recursion thus H(P,P) returns to P.
>

Except it DOESN'T since we KNOW that your H(P,P) aborts its simulation
and returns 0.

All you have shown is that for the fictional H that doesn't abort, P(P)
will be non-halting, and for that H(P,P) it will fail to return so isn't
correct.

WHICH WRONG H are you claiming is right?

On 7/25/22 11:20 AM, olcott wrote:
> On 7/25/2022 10:14 AM, Mikko wrote:
>> On 2022-07-25 13:49:20 +0000, olcott said:
>>
>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>
>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>
>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>
>>>
>>> _P()
>>> [000013c6](01)  55         push ebp
>>> [000013c7](02)  8bec       mov ebp,esp
>>> [000013c9](01)  51         push ecx
>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>> [000013cd](01)  50         push eax
>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>> [000013d1](01)  51         push ecx
>>> [000013d2](05)  e82ffdffff call 00001106
>>> [000013d7](03)  83c408     add esp,+08
>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>> [000013e1](02)  7402       jz 000013e5
>>> [000013e3](02)  ebfe       jmp 000013e3
>>> [000013e5](02)  8be5       mov esp,ebp
>>> [000013e7](01)  5d         pop ebp
>>> [000013e8](01)  c3         ret
>>> Size in bytes:(0035) [000013e8]
>>>
>>>
>>>>> We have to do this at the C level.
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>> }
>>>>>
>>>>> (a) H(P,P) simulates its input
>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>
>>>>> *Can you see the repeating pattern* ?
>>>>
>>>> Yes, but I cannot see any answer to any of my questions.
>>>>
>>>> Can you prove that 13d7 is the first differeing instruction?
>>>> In particular, that the immediately preceding instruction is
>>>> the same?
>>>>
>>>> Mikko
>>>>
>>>
>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>> The source-code of P specifies that the next instruction after
>>> machine address 13d2 when H returns to P for P(P) is 13d7.
>>>
>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>> The source-code of P specifies the next machine address for the
>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>
>> Wrong. In both cases P is the same so therefore specifies the same.
>> The difference seems to be that in the second case the instruction
>> H(P,P) is not simulated correctly as a call to a decider.
>>
>> Mikko
>>
>
> You can assume that I am wrong by making sure to not even look at the
> proof that I am correct. The actual execution trace showed in example 05
> at the end of the paper proves that P(P) stops running and the correctly
> simulated input to H(P,P) never stops running unless aborted.
>
> *Halting problem proofs refuted on the basis of software engineering* ?
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>
>

No, it shows that H INCORRECTLY presumes that the call to H(P,P) from P
will be infinitely recursive while also showing that H(P,P) returns 0.

Thus, H is WRONG about the behavior of H(P,P), or H isn't a Pure
Function and thus not a model of a Computation, and thus can't be a Decider.

Which way are you wrong?

On 7/25/2022 10:49 AM, Mike Terry wrote:
> On 25/07/2022 01:18, olcott wrote:
>> On 7/24/2022 6:50 PM, Mike Terry wrote:
>>> On 24/07/2022 20:11, olcott wrote:
>>>> On 7/24/2022 1:03 PM, Mike Terry wrote:
>>>>> On 24/07/2022 18:54, olcott wrote:
>>>>>> On 7/24/2022 12:32 PM, Mike Terry wrote:
>>>>>>> On 24/07/2022 16:08, olcott wrote:
>>>>>>>> On 7/24/2022 9:49 AM, Mike Terry wrote:
>>>>>>>>> On 24/07/2022 13:26, Mikko wrote:
>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save
>>>>>>>>>>> Base Pointer register onto the stack
>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load
>>>>>>>>>>> Base Pointer with Stack Pointer
>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save the
>>>>>>>>>>> value of ecx on the stack
>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load eax
>>>>>>>>>>> with argument to P
>>>>>>>>>>> [000013cd](01)  50         push eax               // push 2nd
>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load ecx
>>>>>>>>>>> with with argument to P
>>>>>>>>>>> [000013d1](01)  51         push ecx               // push 1st
>>>>>>>>>>> argument to H onto the stack
>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push
>>>>>>>>>>> return address on the stack; call simulated H
>>>>>>>>>
>>>>>>>>> um, H here is not simulated, it's directly called by P.
>>>>>>>>>
>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            // remove
>>>>>>>>>>> call arguments from stack
>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>>>>>>>>>>> Halt_Status to 0
>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load
>>>>>>>>>>> Stack Pointer with Base Pointer
>>>>>>>>>>> [000013e7](01)  5d         pop ebp                // Restore
>>>>>>>>>>> Base Pointer value from stack
>>>>>>>>>>> [000013e8](01)  c3         ret                    // return
>>>>>>>>>>> to caller
>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>
>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>
>>>>>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>>>>>> In particular, that the immediately preceding instruction is
>>>>>>>>>> the same?
>>>>>>>>>>
>>>>>>>>>> Mikko
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the
>>>>>>>>> first call to H.  That is obviously not the last step of the
>>>>>>>>> computation, as we can see by looking at the trace of P(P)
>>>>>>>>> [native]:
>>>>>>>>>
>>>>>>>>> [Native P(P): summary of execution + simulations]
>>>>>>>>> P(P)
>>>>>>>>>      H(P,P)
>>>>>>>>>      [#SIMULATION...]
>>>>>>>>>      P(P)
>>>>>>>>>          H(P,P)
>>>>>>>>>      [#STOP SIMULATING]
>>>>>>>>>      H ret 0 [non-halting]
>>>>>>>>> P ret [P(P) halts]
>>>>>>>>>
>>>>>>>>> For "H simulating its input (P,P)" PO is just counting the
>>>>>>>>> lines above between "#SIMULATION..." and "#STOP SIMULATING":
>>>>>>>>>
>>>>>>>>> [H's simulation of P(P): summary of execution + simulations]
>>>>>>>>> P(P)
>>>>>>>>>      H(P,P)
>>>>>>>>> er that's it - Simulator has given up simulating!!
>>>>>>>>>
>>>>>>>>> Claiming the computations are "a different sequence of
>>>>>>>>> instructions" is completely misleading, as the sequence is
>>>>>>>>> exactly the same in both cases, other than H decides to give up
>>>>>>>>> simulating at an early point in the sequence,
>>>>>>>>
>>>>>>>> That is not true.
>>>>>>>
>>>>>>> What exactly is not true?  Whether your claim is misleading or
>>>>>>> not is a matter of opinion, not verifiable truth.
>>>>>>>
>>>>>>> Do you agree with the factual points I made:  "the sequence is
>>>>>>> exactly the same in both cases, other than H decides to give up
>>>>>>> simulating at an earlier point in the sequence" ?
>>>>>>>
>>>>>>> Mike.
>>>>>>
>>>>>> No I do not agree.
>>>>>>
>>>>>
>>>>> Ok, the way to resolve this is for you to present both sequences:
>>>>>
>>>>> A)  sequence of instructions for P(P) direct call
>>>>> B)  sequence of (emulated) instructions for H's simulation of P(P)
>>>>>
>>>>> Since you have both of these to hand, it wouldn't be much effort
>>>>> for you to supply the traces...
>>>>> (Be sure to keep code addresses common across the two traces to
>>>>> make comparisons straight forward...)
>>>>>
>>>>> Regards,
>>>>> Mike.
>>>>
>>>> I have already done that 30 times now.
>>>
>>> Then it will be easy for you to cut and paste it again, right.
>>> Except that you have never directly presented the two comparisons.
>>>
>>
>> Sure I have you just didn't bother to pay enough attention.
>> The execution trace of P(P) includes the execution trace of the
>> correctly simulated input to H(P,P) is at the end of this post.
>>
>
> I've commented previously on that trace, pointing out that the
> instruction sequences for P(P) and H's simulation of P(P) are EXACTLY
> THE SAME - up to the point where H stops its simulation.  It seems you
> didn't agree with that, but weren't paying enough attention at the time.
>

*I have to break up this massive post into one reply per point*

On 7/25/22 8:43 PM, olcott wrote:
> On 7/25/2022 10:49 AM, Mike Terry wrote:
>> On 25/07/2022 01:18, olcott wrote:
>>> On 7/24/2022 6:50 PM, Mike Terry wrote:
>>>> On 24/07/2022 20:11, olcott wrote:
>>>>> On 7/24/2022 1:03 PM, Mike Terry wrote:
>>>>>> On 24/07/2022 18:54, olcott wrote:
>>>>>>> On 7/24/2022 12:32 PM, Mike Terry wrote:
>>>>>>>> On 24/07/2022 16:08, olcott wrote:
>>>>>>>>> On 7/24/2022 9:49 AM, Mike Terry wrote:
>>>>>>>>>> On 24/07/2022 13:26, Mikko wrote:
>>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [000013c6](01)  55         push ebp               // Save
>>>>>>>>>>>> Base Pointer register onto the stack
>>>>>>>>>>>> [000013c7](02)  8bec       mov ebp,esp            // Load
>>>>>>>>>>>> Base Pointer with Stack Pointer
>>>>>>>>>>>> [000013c9](01)  51         push ecx               // Save
>>>>>>>>>>>> the value of ecx on the stack
>>>>>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load
>>>>>>>>>>>> eax with argument to P
>>>>>>>>>>>> [000013cd](01)  50         push eax               // push
>>>>>>>>>>>> 2nd argument to H onto the stack
>>>>>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load
>>>>>>>>>>>> ecx with with argument to P
>>>>>>>>>>>> [000013d1](01)  51         push ecx               // push
>>>>>>>>>>>> 1st argument to H onto the stack
>>>>>>>>>>>> [000013d2](05)  e82ffdffff call 00001106          // push
>>>>>>>>>>>> return address on the stack; call simulated H
>>>>>>>>>>
>>>>>>>>>> um, H here is not simulated, it's directly called by P.
>>>>>>>>>>
>>>>>>>>>>>> [000013d7](03)  83c408     add esp,+08            // remove
>>>>>>>>>>>> call arguments from stack
>>>>>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>>>>>>>>>> Halt_Status with return value from H
>>>>>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>>>>>>>>>>>> Halt_Status to 0
>>>>>>>>>>>> [000013e1](02)  7402       jz 000013e5            // if
>>>>>>>>>>>> Halt_Status == 0 goto 000013e5
>>>>>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>>>>>>>>>> [000013e5](02)  8be5       mov esp,ebp            // Load
>>>>>>>>>>>> Stack Pointer with Base Pointer
>>>>>>>>>>>> [000013e7](01)  5d         pop ebp                // Restore
>>>>>>>>>>>> Base Pointer value from stack
>>>>>>>>>>>> [000013e8](01)  c3         ret                    // return
>>>>>>>>>>>> to caller
>>>>>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>>>>>
>>>>>>>>>>>> The instruction at machine address 13d7
>>>>>>>>>>>
>>>>>>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>>>>>>> In particular, that the immediately preceding instruction is
>>>>>>>>>>> the same?
>>>>>>>>>>>
>>>>>>>>>>> Mikko
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the
>>>>>>>>>> first call to H.  That is obviously not the last step of the
>>>>>>>>>> computation, as we can see by looking at the trace of P(P)
>>>>>>>>>> [native]:
>>>>>>>>>>
>>>>>>>>>> [Native P(P): summary of execution + simulations]
>>>>>>>>>> P(P)
>>>>>>>>>>      H(P,P)
>>>>>>>>>>      [#SIMULATION...]
>>>>>>>>>>      P(P)
>>>>>>>>>>          H(P,P)
>>>>>>>>>>      [#STOP SIMULATING]
>>>>>>>>>>      H ret 0 [non-halting]
>>>>>>>>>> P ret [P(P) halts]
>>>>>>>>>>
>>>>>>>>>> For "H simulating its input (P,P)" PO is just counting the
>>>>>>>>>> lines above between "#SIMULATION..." and "#STOP SIMULATING":
>>>>>>>>>>
>>>>>>>>>> [H's simulation of P(P): summary of execution + simulations]
>>>>>>>>>> P(P)
>>>>>>>>>>      H(P,P)
>>>>>>>>>> er that's it - Simulator has given up simulating!!
>>>>>>>>>>
>>>>>>>>>> Claiming the computations are "a different sequence of
>>>>>>>>>> instructions" is completely misleading, as the sequence is
>>>>>>>>>> exactly the same in both cases, other than H decides to give
>>>>>>>>>> up simulating at an early point in the sequence,
>>>>>>>>>
>>>>>>>>> That is not true.
>>>>>>>>
>>>>>>>> What exactly is not true?  Whether your claim is misleading or
>>>>>>>> not is a matter of opinion, not verifiable truth.
>>>>>>>>
>>>>>>>> Do you agree with the factual points I made:  "the sequence is
>>>>>>>> exactly the same in both cases, other than H decides to give up
>>>>>>>> simulating at an earlier point in the sequence" ?
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>
>>>>>>> No I do not agree.
>>>>>>>
>>>>>>
>>>>>> Ok, the way to resolve this is for you to present both sequences:
>>>>>>
>>>>>> A)  sequence of instructions for P(P) direct call
>>>>>> B)  sequence of (emulated) instructions for H's simulation of P(P)
>>>>>>
>>>>>> Since you have both of these to hand, it wouldn't be much effort
>>>>>> for you to supply the traces...
>>>>>> (Be sure to keep code addresses common across the two traces to
>>>>>> make comparisons straight forward...)
>>>>>>
>>>>>> Regards,
>>>>>> Mike.
>>>>>
>>>>> I have already done that 30 times now.
>>>>
>>>> Then it will be easy for you to cut and paste it again, right.
>>>> Except that you have never directly presented the two comparisons.
>>>>
>>>
>>> Sure I have you just didn't bother to pay enough attention.
>>> The execution trace of P(P) includes the execution trace of the
>>> correctly simulated input to H(P,P) is at the end of this post.
>>>
>>
>> I've commented previously on that trace, pointing out that the
>> instruction sequences for P(P) and H's simulation of P(P) are EXACTLY
>> THE SAME - up to the point where H stops its simulation.  It seems you
>> didn't agree with that, but weren't paying enough attention at the time.
>>
>
> *I have to break up this massive post into one reply per point*
>
> The next instruction that the correctly emulated input to H(P,P) would
> execute if not aborted would be the instruction at machine address 14b3,
> earlier versions of my system (that required static local memory so that
> different instances of H could communicate with each other) explicitly
> showed that. The next instruction for the executed P(P) is shown to be
> at machine address 144c, when P's call to H(P,P) returns to P.

On 7/25/2022 10:49 AM, Mike Terry wrote:
> On 25/07/2022 01:18, olcott wrote:
>> On 7/24/2022 6:50 PM, Mike Terry wrote:

>> Sure I have you just didn't bother to pay enough attention.
>> The execution trace of P(P) includes the execution trace of the
>> correctly simulated input to H(P,P) is at the end of this post.
>>
>
> I've commented previously on that trace, pointing out that the
> instruction sequences for P(P) and H's simulation of P(P) are EXACTLY
> THE SAME - up to the point where H stops its simulation.
Yes this is correct yet beside the point.
The next instruction for P(P) is 1447 when H(P,P) returns to P.

The next instruction for the correctly simulated H(P,P) is 143b as I
have shown with the prior version of my system on pages 2-3 of this
linked paper.

Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

I took a long time to respond to your massive post because you are
currently my most important reviewer: The only one with both the
capacity and inclination to understand me.

_P()
[0000143b](01) 55 push ebp
[0000143c](02) 8bec mov ebp,esp
[0000143e](01) 51 push ecx
[0000143f](03) 8b4508 mov eax,[ebp+08]
[00001442](01) 50 push eax
[00001443](03) 8b4d08 mov ecx,[ebp+08]
[00001446](01) 51 push ecx
[00001447](05) e8affcffff call 000010fb
[0000144c](03) 83c408 add esp,+08
[0000144f](03) 8945fc mov [ebp-04],eax
[00001452](04) 837dfc00 cmp dword [ebp-04],+00
[00001456](02) 7402 jz 0000145a
[00001458](02) ebfe jmp 00001458
[0000145a](02) 8be5 mov esp,ebp
[0000145c](01) 5d pop ebp
[0000145d](01) c3 ret
Size in bytes:(0035) [0000145d]

--
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 7/25/22 10:08 PM, olcott wrote:
> On 7/25/2022 10:49 AM, Mike Terry wrote:
>> On 25/07/2022 01:18, olcott wrote:
>>> On 7/24/2022 6:50 PM, Mike Terry wrote:
>
>>> Sure I have you just didn't bother to pay enough attention.
>>> The execution trace of P(P) includes the execution trace of the
>>> correctly simulated input to H(P,P) is at the end of this post.
>>>
>>
>> I've commented previously on that trace, pointing out that the
>> instruction sequences for P(P) and H's simulation of P(P) are EXACTLY
>> THE SAME - up to the point where H stops its simulation.
> Yes this is correct yet beside the point.
> The next instruction for P(P) is 1447 when H(P,P) returns to P.

No, the next instructon of P(P) is at 000010FB, as that is what a call H
does.

Remember, the H that P calls is oart of the comoputation of P

Let me ask you what the x86 semantics of a call 000010FB is?

Remember, the processor doesn't get to see "names" of the routines, only
the instruction sequence, so that is what the semantic of the x86 says
will happen.

>
> The next instruction for the correctly simulated H(P,P) is 143b as I
> have shown with the prior version of my system on pages 2-3 of this
> linked paper.

WHY? Actually the next instruction to be simulated is exactly the same
as above, the instruction at 000010FB

If you are skipping what happens inside H, where in the exection of H
did we get a divergence?

All you claim does is PROVE that H isn't actually a computation, and
thus not eligable to be a decider, or H is just incorrect in its
presumption of the behavior of itself.

>
> Halting problem undecidability and infinitely nested simulation (V5)
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
> I took a long time to respond to your massive post because you are
> currently my most important reviewer: The only one with both the
> capacity and inclination to understand me.
>
> _P()
> [0000143b](01)  55             push ebp
> [0000143c](02)  8bec           mov ebp,esp
> [0000143e](01)  51             push ecx
> [0000143f](03)  8b4508         mov eax,[ebp+08]
> [00001442](01)  50             push eax
> [00001443](03)  8b4d08         mov ecx,[ebp+08]
> [00001446](01)  51             push ecx
> [00001447](05)  e8affcffff     call 000010fb
> [0000144c](03)  83c408         add esp,+08
> [0000144f](03)  8945fc         mov [ebp-04],eax
> [00001452](04)  837dfc00       cmp dword [ebp-04],+00
> [00001456](02)  7402           jz 0000145a
> [00001458](02)  ebfe           jmp 00001458
> [0000145a](02)  8be5           mov esp,ebp
> [0000145c](01)  5d             pop ebp
> [0000145d](01)  c3             ret
> Size in bytes:(0035) [0000145d]
>
>

On Monday, 25 July 2022 at 22:12:28 UTC+2, olcott wrote:
> > What does it mean if x86utm(Halt7.obj) returns 0?
> > What does it mean if x86utm(Halt7.obj) returns 1?
> >
> Here is what x86utm returns:
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }

So if you make the main() procedure of x86utm like this...

int main(){
if (H(P,P)){
HERE: goto HERE};
return 0;
}

Then it becomes exactly the same function as P?!?

On 7/26/2022 1:01 AM, Skep Dick wrote:
> On Monday, 25 July 2022 at 22:12:28 UTC+2, olcott wrote:
>>> What does it mean if x86utm(Halt7.obj) returns 0?
>>> What does it mean if x86utm(Halt7.obj) returns 1?
>>>
>> Here is what x86utm returns:
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>
> So if you make the main() procedure of x86utm like this...
>
> int main(){
> if (H(P,P)){
> HERE: goto HERE};
> return 0;
> }
>
> Then it becomes exactly the same function as P?!?

int main()
{ int Input_Halts;
Input_Halts = H(P,P);
if (Input_Halts)
HERE: goto HERE;
Output("Input_Halts = ", Input_Halts);
return 0;
}

Input_Halts = 0

--
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 2022-07-25 20:09:42 +0000, olcott said:

> On 7/25/2022 11:47 AM, Mikko wrote:
>> On 2022-07-25 15:20:02 +0000, olcott said:
>>
>>> On 7/25/2022 10:14 AM, Mikko wrote:
>>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>>
>>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>>
>>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86 question for
>>>>>>>>>>>> you, what is the first instruction executed in P(P) that differs from
>>>>>>>>>>>> the correct simulation of H(P,P)?
>>>>>>>>>>>
>>>>>
>>>>> _P()
>>>>> [000013c6](01)  55         push ebp
>>>>> [000013c7](02)  8bec       mov ebp,esp
>>>>> [000013c9](01)  51         push ecx
>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>>> [000013cd](01)  50         push eax
>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>>> [000013d1](01)  51         push ecx
>>>>> [000013d2](05)  e82ffdffff call 00001106
>>>>> [000013d7](03)  83c408     add esp,+08
>>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>>> [000013e1](02)  7402       jz 000013e5
>>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>>> [000013e5](02)  8be5       mov esp,ebp
>>>>> [000013e7](01)  5d         pop ebp
>>>>> [000013e8](01)  c3         ret
>>>>> Size in bytes:(0035) [000013e8]
>>>>>
>>>>>
>>>>>>> We have to do this at the C level.
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> (a) H(P,P) simulates its input
>>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>>
>>>>>>> *Can you see the repeating pattern* ?
>>>>>>
>>>>>> Yes, but I cannot see any answer to any of my questions.
>>>>>>
>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>> In particular, that the immediately preceding instruction is
>>>>>> the same?
>>>>>>
>>>>>> Mikko
>>>>>>
>>>>>
>>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>>> The source-code of P specifies that the next instruction after machine
>>>>> address 13d2 when H returns to P for P(P) is 13d7.
>>>>>
>>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>>> The source-code of P specifies the next machine address for the
>>>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>>>
>>>> Wrong. In both cases P is the same so therefore specifies the same.
>>>> The difference seems to be that in the second case the instruction
>>>> H(P,P) is not simulated correctly as a call to a decider.
>>>>
>>>> Mikko
>>>>
>>>
>>> You can assume that I am wrong by making sure to not even look at the
>>> proof that I am correct.
>>
>> Wrong. I didn't assume that you are wrong. I presented a sentence that
>> is true because of the meaning of the words. You have not found anything
>> wrong in that sentence.
>>
>> Mikko
>>
>
> The behavior of P when directly executed is different than the behavior
> of P when correctly simulated by H even though each case uses the exact
> same machine-code for P. This is an established fact thus disbelieving
> this in incorrect.

That does not contradict what I said above.

However, none of that is any estabilished fact. The behaviour
simulated by H is not the behaviour specified by P and there
is no proof that H simulates correctly.

Mikko

On 7/26/2022 8:48 AM, Mikko wrote:
> On 2022-07-25 20:09:42 +0000, olcott said:
>
>> On 7/25/2022 11:47 AM, Mikko wrote:
>>> On 2022-07-25 15:20:02 +0000, olcott said:
>>>
>>>> On 7/25/2022 10:14 AM, Mikko wrote:
>>>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>>>
>>>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>>>
>>>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>>> question for you, what is the first instruction executed in
>>>>>>>>>>>>> P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>
>>>>>>
>>>>>> _P()
>>>>>> [000013c6](01)  55         push ebp
>>>>>> [000013c7](02)  8bec       mov ebp,esp
>>>>>> [000013c9](01)  51         push ecx
>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>>>> [000013cd](01)  50         push eax
>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>>>> [000013d1](01)  51         push ecx
>>>>>> [000013d2](05)  e82ffdffff call 00001106
>>>>>> [000013d7](03)  83c408     add esp,+08
>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>>>> [000013e1](02)  7402       jz 000013e5
>>>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>>>> [000013e5](02)  8be5       mov esp,ebp
>>>>>> [000013e7](01)  5d         pop ebp
>>>>>> [000013e8](01)  c3         ret
>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>
>>>>>>
>>>>>>>> We have to do this at the C level.
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>    if (Halt_Status)
>>>>>>>>      HERE: goto HERE;
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> (a) H(P,P) simulates its input
>>>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>>>
>>>>>>>> *Can you see the repeating pattern* ?
>>>>>>>
>>>>>>> Yes, but I cannot see any answer to any of my questions.
>>>>>>>
>>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>>> In particular, that the immediately preceding instruction is
>>>>>>> the same?
>>>>>>>
>>>>>>> Mikko
>>>>>>>
>>>>>>
>>>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>>>> The source-code of P specifies that the next instruction after
>>>>>> machine address 13d2 when H returns to P for P(P) is 13d7.
>>>>>>
>>>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>>>> The source-code of P specifies the next machine address for the
>>>>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>>>>
>>>>> Wrong. In both cases P is the same so therefore specifies the same.
>>>>> The difference seems to be that in the second case the instruction
>>>>> H(P,P) is not simulated correctly as a call to a decider.
>>>>>
>>>>> Mikko
>>>>>
>>>>
>>>> You can assume that I am wrong by making sure to not even look at
>>>> the proof that I am correct.
>>>
>>> Wrong. I didn't assume that you are wrong. I presented a sentence that
>>> is true because of the meaning of the words. You have not found anything
>>> wrong in that sentence.
>>>
>>> Mikko
>>>
>>
>> The behavior of P when directly executed is different than the
>> behavior of P when correctly simulated by H even though each case uses
>> the exact same machine-code for P. This is an established fact thus
>> disbelieving this in incorrect.
>
> That does not contradict what I said above.
>
> However, none of that is any estabilished fact. The behaviour
> simulated by H is not the behaviour specified by P and there
> is no proof that H simulates correctly.
>
> Mikko
>

That the line-by-line execution trace of the simulated input to H(P,P)
exactly matches the line-by-line source-code conclusively proves that P
is simulated correctly. If you don't understand this then your technical
competence is woefully insufficient.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

This earlier version of the halt decider postpones its halt status
decision until it sees:

This is main()
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

*Matched infinite recursion detection criteria*
(1) P() calls H(P,P) twice in sequence.
(2) With the same arguments.
(3) With no control flow instructions in P preceding its invocation of
H(P,P) that could escape repeated simulations.

On 7/26/22 9:14 AM, olcott wrote:
> On 7/26/2022 1:01 AM, Skep Dick wrote:
>> On Monday, 25 July 2022 at 22:12:28 UTC+2, olcott wrote:
>>>> What does it mean if x86utm(Halt7.obj) returns 0?
>>>> What does it mean if x86utm(Halt7.obj) returns 1?
>>>>
>>> Here is what x86utm returns:
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>
>> So if you make the main() procedure of x86utm like this...
>>
>> int main(){
>>      if (H(P,P)){
>>         HERE: goto HERE};
>>     return 0;
>> }
>>
>> Then it becomes exactly the same function as P?!?
>
> int main()
> {
>   int Input_Halts;
>   Input_Halts = H(P,P);
>     if (Input_Halts)
>        HERE: goto HERE;
>     Output("Input_Halts = ", Input_Halts);
>    return 0;
> }
>
> Input_Halts = 0
>

Proving that main() and thus P(P) will halt. (Since it is the same
algorithm)

Thus H(P,P) returning 0 is wrong.

PERIOD.

On 7/26/22 10:40 AM, olcott wrote:
> On 7/26/2022 8:48 AM, Mikko wrote:
>> On 2022-07-25 20:09:42 +0000, olcott said:
>>
>>> On 7/25/2022 11:47 AM, Mikko wrote:
>>>> On 2022-07-25 15:20:02 +0000, olcott said:
>>>>
>>>>> On 7/25/2022 10:14 AM, Mikko wrote:
>>>>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>>>>
>>>>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86
>>>>>>>>>>>>>> question for you, what is the first instruction executed
>>>>>>>>>>>>>> in P(P) that differs from the correct simulation of H(P,P)?
>>>>>>>>>>>>>
>>>>>>>
>>>>>>> _P()
>>>>>>> [000013c6](01)  55         push ebp
>>>>>>> [000013c7](02)  8bec       mov ebp,esp
>>>>>>> [000013c9](01)  51         push ecx
>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>>>>> [000013cd](01)  50         push eax
>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>>>>> [000013d1](01)  51         push ecx
>>>>>>> [000013d2](05)  e82ffdffff call 00001106
>>>>>>> [000013d7](03)  83c408     add esp,+08
>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>>>>> [000013e1](02)  7402       jz 000013e5
>>>>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>>>>> [000013e5](02)  8be5       mov esp,ebp
>>>>>>> [000013e7](01)  5d         pop ebp
>>>>>>> [000013e8](01)  c3         ret
>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>
>>>>>>>
>>>>>>>>> We have to do this at the C level.
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>    if (Halt_Status)
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> (a) H(P,P) simulates its input
>>>>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>>>>
>>>>>>>>> *Can you see the repeating pattern* ?
>>>>>>>>
>>>>>>>> Yes, but I cannot see any answer to any of my questions.
>>>>>>>>
>>>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>>>> In particular, that the immediately preceding instruction is
>>>>>>>> the same?
>>>>>>>>
>>>>>>>> Mikko
>>>>>>>>
>>>>>>>
>>>>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>>>>> The source-code of P specifies that the next instruction after
>>>>>>> machine address 13d2 when H returns to P for P(P) is 13d7.
>>>>>>>
>>>>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>>>>> The source-code of P specifies the next machine address for the
>>>>>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>>>>>
>>>>>> Wrong. In both cases P is the same so therefore specifies the same.
>>>>>> The difference seems to be that in the second case the instruction
>>>>>> H(P,P) is not simulated correctly as a call to a decider.
>>>>>>
>>>>>> Mikko
>>>>>>
>>>>>
>>>>> You can assume that I am wrong by making sure to not even look at
>>>>> the proof that I am correct.
>>>>
>>>> Wrong. I didn't assume that you are wrong. I presented a sentence that
>>>> is true because of the meaning of the words. You have not found
>>>> anything
>>>> wrong in that sentence.
>>>>
>>>> Mikko
>>>>
>>>
>>> The behavior of P when directly executed is different than the
>>> behavior of P when correctly simulated by H even though each case
>>> uses the exact same machine-code for P. This is an established fact
>>> thus disbelieving this in incorrect.
>>
>> That does not contradict what I said above.
>>
>> However, none of that is any estabilished fact. The behaviour
>> simulated by H is not the behaviour specified by P and there
>> is no proof that H simulates correctly.
>>
>> Mikko
>>
>
> That the line-by-line execution trace of the simulated input to H(P,P)
> exactly matches the line-by-line source-code conclusively proves that P
> is simulated correctly. If you don't understand this then your technical
> competence is woefully insufficient.

No, because H doesn't recreate the behavior of the call to H(P,P).

>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> This earlier version of the halt decider postpones its halt status
> decision until it sees:
>
>
> This is main()
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> // H emulates the first seven instructions of P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> // The emulated H emulates the first seven instructions of P
> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> *Matched infinite recursion detection criteria*
> (1) P() calls H(P,P) twice in sequence.
> (2) With the same arguments.
> (3) With no control flow instructions in P preceding its invocation of
> H(P,P) that could escape repeated simulations.

On 2022-07-26 14:40:22 +0000, olcott said:

> On 7/26/2022 8:48 AM, Mikko wrote:
>> On 2022-07-25 20:09:42 +0000, olcott said:
>>
>>> On 7/25/2022 11:47 AM, Mikko wrote:
>>>> On 2022-07-25 15:20:02 +0000, olcott said:
>>>>
>>>>> On 7/25/2022 10:14 AM, Mikko wrote:
>>>>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>>>>
>>>>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the x86 question for
>>>>>>>>>>>>>> you, what is the first instruction executed in P(P) that differs from
>>>>>>>>>>>>>> the correct simulation of H(P,P)?
>>>>>>>>>>>>>
>>>>>>>
>>>>>>> _P()
>>>>>>> [000013c6](01)  55         push ebp
>>>>>>> [000013c7](02)  8bec       mov ebp,esp
>>>>>>> [000013c9](01)  51         push ecx
>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>>>>> [000013cd](01)  50         push eax
>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>>>>> [000013d1](01)  51         push ecx
>>>>>>> [000013d2](05)  e82ffdffff call 00001106
>>>>>>> [000013d7](03)  83c408     add esp,+08
>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>>>>> [000013e1](02)  7402       jz 000013e5
>>>>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>>>>> [000013e5](02)  8be5       mov esp,ebp
>>>>>>> [000013e7](01)  5d         pop ebp
>>>>>>> [000013e8](01)  c3         ret
>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>
>>>>>>>
>>>>>>>>> We have to do this at the C level.
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>    if (Halt_Status)
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> (a) H(P,P) simulates its input
>>>>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>>>>
>>>>>>>>> *Can you see the repeating pattern* ?
>>>>>>>>
>>>>>>>> Yes, but I cannot see any answer to any of my questions.
>>>>>>>>
>>>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>>>> In particular, that the immediately preceding instruction is
>>>>>>>> the same?
>>>>>>>>
>>>>>>>> Mikko
>>>>>>>>
>>>>>>>
>>>>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>>>>> The source-code of P specifies that the next instruction after machine
>>>>>>> address 13d2 when H returns to P for P(P) is 13d7.
>>>>>>>
>>>>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>>>>> The source-code of P specifies the next machine address for the
>>>>>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>>>>>
>>>>>> Wrong. In both cases P is the same so therefore specifies the same.
>>>>>> The difference seems to be that in the second case the instruction
>>>>>> H(P,P) is not simulated correctly as a call to a decider.
>>>>>>
>>>>>> Mikko
>>>>>>
>>>>>
>>>>> You can assume that I am wrong by making sure to not even look at the
>>>>> proof that I am correct.
>>>>
>>>> Wrong. I didn't assume that you are wrong. I presented a sentence that
>>>> is true because of the meaning of the words. You have not found anything
>>>> wrong in that sentence.
>>>>
>>>> Mikko
>>>>
>>>
>>> The behavior of P when directly executed is different than the behavior
>>> of P when correctly simulated by H even though each case uses the exact
>>> same machine-code for P. This is an established fact thus disbelieving
>>> this in incorrect.
>>
>> That does not contradict what I said above.
>>
>> However, none of that is any estabilished fact. The behaviour
>> simulated by H is not the behaviour specified by P and there
>> is no proof that H simulates correctly.
>>
>> Mikko
>>
>
> That the line-by-line execution trace of the simulated input to H(P,P)
> exactly matches the line-by-line source-code conclusively proves that P
> is simulated correctly.

Only partially, to the call of H. The simulation is discontinued before
the return from H so the full behaviour specified by P is not simulated.
In particular, the behaviour specified by P is either to halt or to run
forever but the simulation does neither.

Mikko

On 7/27/2022 4:48 AM, Mikko wrote:
> On 2022-07-26 14:40:22 +0000, olcott said:
>
>> On 7/26/2022 8:48 AM, Mikko wrote:
>>> On 2022-07-25 20:09:42 +0000, olcott said:
>>>
>>>> On 7/25/2022 11:47 AM, Mikko wrote:
>>>>> On 2022-07-25 15:20:02 +0000, olcott said:
>>>>>
>>>>>> On 7/25/2022 10:14 AM, Mikko wrote:
>>>>>>> On 2022-07-25 13:49:20 +0000, olcott said:
>>>>>>>
>>>>>>>> On 7/25/2022 6:02 AM, Mikko wrote:
>>>>>>>>> On 2022-07-24 20:03:29 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 7/24/2022 12:01 PM, Mikko wrote:
>>>>>>>>>>> On 2022-07-24 14:53:43 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/24/2022 7:26 AM, Mikko wrote:
>>>>>>>>>>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> The trace proves no such thing. Here is a basic of the
>>>>>>>>>>>>>>> x86 question for you, what is the first instruction
>>>>>>>>>>>>>>> executed in P(P) that differs from the correct simulation
>>>>>>>>>>>>>>> of H(P,P)?
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [000013c6](01)  55         push ebp
>>>>>>>> [000013c7](02)  8bec       mov ebp,esp
>>>>>>>> [000013c9](01)  51         push ecx
>>>>>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]
>>>>>>>> [000013cd](01)  50         push eax
>>>>>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
>>>>>>>> [000013d1](01)  51         push ecx
>>>>>>>> [000013d2](05)  e82ffdffff call 00001106
>>>>>>>> [000013d7](03)  83c408     add esp,+08
>>>>>>>> [000013da](03)  8945fc     mov [ebp-04],eax
>>>>>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
>>>>>>>> [000013e1](02)  7402       jz 000013e5
>>>>>>>> [000013e3](02)  ebfe       jmp 000013e3
>>>>>>>> [000013e5](02)  8be5       mov esp,ebp
>>>>>>>> [000013e7](01)  5d         pop ebp
>>>>>>>> [000013e8](01)  c3         ret
>>>>>>>> Size in bytes:(0035) [000013e8]
>>>>>>>>
>>>>>>>>
>>>>>>>>>> We have to do this at the C level.
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>    Output("Input_Halts = ",  H(P, P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> (a) H(P,P) simulates its input
>>>>>>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>>>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>>>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>>>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>>>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>>>>>>
>>>>>>>>>> *Can you see the repeating pattern* ?
>>>>>>>>>
>>>>>>>>> Yes, but I cannot see any answer to any of my questions.
>>>>>>>>>
>>>>>>>>> Can you prove that 13d7 is the first differeing instruction?
>>>>>>>>> In particular, that the immediately preceding instruction is
>>>>>>>>> the same?
>>>>>>>>>
>>>>>>>>> Mikko
>>>>>>>>>
>>>>>>>>
>>>>>>>> WHEN THE DIRECTLY EXECUTED P(P) CALLS H(P,P)
>>>>>>>> The source-code of P specifies that the next instruction after
>>>>>>>> machine address 13d2 when H returns to P for P(P) is 13d7.
>>>>>>>>
>>>>>>>> WHEN THE SIMULATED INPUT TO H(P,P) CALLS H(P,P)
>>>>>>>> The source-code of P specifies the next machine address for the
>>>>>>>> correctly simulated input to H(P,P) is 13c6 (if P is not aborted)
>>>>>>>
>>>>>>> Wrong. In both cases P is the same so therefore specifies the same.
>>>>>>> The difference seems to be that in the second case the instruction
>>>>>>> H(P,P) is not simulated correctly as a call to a decider.
>>>>>>>
>>>>>>> Mikko
>>>>>>>
>>>>>>
>>>>>> You can assume that I am wrong by making sure to not even look at
>>>>>> the proof that I am correct.
>>>>>
>>>>> Wrong. I didn't assume that you are wrong. I presented a sentence that
>>>>> is true because of the meaning of the words. You have not found
>>>>> anything
>>>>> wrong in that sentence.
>>>>>
>>>>> Mikko
>>>>>
>>>>
>>>> The behavior of P when directly executed is different than the
>>>> behavior of P when correctly simulated by H even though each case
>>>> uses the exact same machine-code for P. This is an established fact
>>>> thus disbelieving this in incorrect.
>>>
>>> That does not contradict what I said above.
>>>
>>> However, none of that is any estabilished fact. The behaviour
>>> simulated by H is not the behaviour specified by P and there
>>> is no proof that H simulates correctly.
>>>
>>> Mikko
>>>
>>
>> That the line-by-line execution trace of the simulated input to H(P,P)
>> exactly matches the line-by-line source-code conclusively proves that
>> P is simulated correctly.
>
> Only partially, to the call of H. The simulation is discontinued before
> the return from H so the full behaviour specified by P is not simulated.
> In particular, the behaviour specified by P is either to halt or to run
> forever but the simulation does neither.
>
> Mikko
>

*Not with this version* With this version I show where the correctly
simulated input to H(P,P) goes after the call.

Example 06: H correctly determines that P() never halts (prior version
of halt decider)

#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()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]