On 8/9/21 5:12 PM, olcott wrote:
> On 8/9/2021 2:38 PM, André G. Isaak wrote:
>> On 2021-08-09 10:57, olcott wrote:
>>> On 8/8/2021 1:50 PM, André G. Isaak wrote:
>>>> On 2021-08-06 22:23, olcott wrote:
>>>>> On 8/6/2021 10:55 PM, André G. Isaak wrote:
>>>>>> On 2021-08-06 09:59, olcott wrote:
>>>>
>>>>>> Yes, but bear in mind that 'halting' refers to Turing Machines
>>>>>> operating on a specific input. It does not refer to simulations or
>>>>>> what happens inside a halting decider. It refers *only* to actual
>>>>>> computations, i.e. an actual Turing Machine operating on an actual
>>>>>> input string.
>>>>>>
>>>>>
>>>>> So yet again you prove that you are totally clueless that pure
>>>>> simulations are computationally equivalent to direct executions ?
>>>>
>>>> Your H is not a pure simulator
>>>>
>>>
>>> // Simplified Linz Ĥ (Linz:1990:319)
>>> // Strachey(1965) CPL translated to C
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> _P()
>>> [00000d02](01)  55          push ebp
>>> [00000d03](02)  8bec        mov ebp,esp
>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>> [00000d08](01)  50          push eax       // push 2nd Param
>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>> [00000d12](03)  83c408      add esp,+08
>>> [00000d15](02)  85c0        test eax,eax
>>> [00000d17](02)  7402        jz 00000d1b
>>> [00000d19](02)  ebfe        jmp 00000d19
>>> [00000d1b](01)  5d          pop ebp
>>> [00000d1c](01)  c3          ret
>>> Size in bytes:(0027) [00000d1c]
>>>
>>>      machine   stack     stack     machine     assembly
>>>      address   address   data      code        language
>>>      ========  ========  ========  =========   =============
>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>>>
>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> The fact that the execution trace of the simulation of P(P) on page 6
>>> perfectly matches its source-code on page 5 conclusively proves that
>>> this execution trace performed by H is a pure simulation of P(P).
>>> There is no correct basis for disagreement, therefore anyone
>>> disagreeing either does not know the x86 language or they are simply
>>> lying.
>>
>> You have a *partial trace* and *partial source code*. Neither shows
>> what happens at B82.
>>
>
> if int add(int x, int y) returns 5 on add(2,3) we know for sure that add
> was correct on that input.
>
> If every line of the execution trace of the simulation of P on input P
> behaves exactly as its x86 source-code specifies that it must behave
> then we know with 100% perfectly justified logical certainty that H did
> perform a pure simulation of P on input P.

Except the CALL instruction doesn't work per the definition of the CALL
instruction.

FAIL.

>
> Do you care about the truth or will you continue to argue when you know
> that you are wrong?

Maybe YOU should value what is TRUE.

>
>> Your trace ends with the cryptic message "Local Halt Decider: Infinite
>> Recursion Detected Simulation Stopped" which doesn't indicate *which*
>> invocation of H aborted *which* simulation and to where control was
>> transferred once that simulation was aborted.
>>
>> Amdré
>>
>
> All that matters it that it is perfectly obvious to anyone knowing the
> x86 language well enough that the input to H does specifies infinitely
> nested simulation. This proves that whatever H aborted whichever P was
> correct in its never halting decision.
>
>

On 8/9/21 6:47 PM, olcott wrote:
> On 8/9/2021 5:43 PM, André G. Isaak wrote:

>> X only halts because Y IMPLIES that X halts. That's basic logic.
>>
>> The definition of halting does not refer at all to the *reason* why a
>> particular computation halts.
>>
>
> The P that halts seems to contradict that H(P,P)==0 is correct yet it is
> verifiable that H(P,P)==0 is correct. That you keep ignoring this means
> that you are dishonest.

Except that your 'PROOF' the H(P,P) is correct is based on UNSOUND
logic. H is WRONG.

On 2021-08-09 16:47, olcott wrote:
> On 8/9/2021 5:43 PM, André G. Isaak wrote:
>> On 2021-08-09 16:21, olcott wrote:
>>> On 8/9/2021 5:17 PM, André G. Isaak wrote:
>>>> On 2021-08-09 15:12, olcott wrote:
>>>>> On 8/9/2021 2:38 PM, André G. Isaak wrote:
>>>>>> On 2021-08-09 10:57, olcott wrote:
>>>>>>> On 8/8/2021 1:50 PM, André G. Isaak wrote:
>>>>>>>> On 2021-08-06 22:23, olcott wrote:
>>>>>>>>> On 8/6/2021 10:55 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-08-06 09:59, olcott wrote:
>>>>>>>>
>>>>>>>>>> Yes, but bear in mind that 'halting' refers to Turing Machines
>>>>>>>>>> operating on a specific input. It does not refer to
>>>>>>>>>> simulations or what happens inside a halting decider. It
>>>>>>>>>> refers *only* to actual computations, i.e. an actual Turing
>>>>>>>>>> Machine operating on an actual input string.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So yet again you prove that you are totally clueless that pure
>>>>>>>>> simulations are computationally equivalent to direct executions ?
>>>>>>>>
>>>>>>>> Your H is not a pure simulator
>>>>>>>>
>>>>>>>
>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>    if (H(x, x))
>>>>>>>      HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00000d02](01)  55          push ebp
>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>> [00000d1c](01)  c3          ret
>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>
>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>      address   address   data      code        language
>>>>>>>      ========  ========  ========  =========   =============
>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  //
>>>>>>> call H
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       //
>>>>>>> push P
>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       //
>>>>>>> push P
>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  //
>>>>>>> call H
>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       //
>>>>>>> push P
>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       //
>>>>>>> push P
>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  //
>>>>>>> call H
>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>
>>>>>>> The fact that the execution trace of the simulation of P(P) on
>>>>>>> page 6 perfectly matches its source-code on page 5 conclusively
>>>>>>> proves that this execution trace performed by H is a pure
>>>>>>> simulation of P(P). There is no correct basis for disagreement,
>>>>>>> therefore anyone disagreeing either does not know the x86
>>>>>>> language or they are simply lying.
>>>>>>
>>>>>> You have a *partial trace* and *partial source code*. Neither
>>>>>> shows what happens at B82.
>>>>>>
>>>>>
>>>>> if int add(int x, int y) returns 5 on add(2,3) we know for sure
>>>>> that add was correct on that input.
>>>>
>>>> That is a poor analogy since 5 actually *is* the correct answer to 2+3.
>>>>
>>>> We know that P(P) *does* halt, which means that if H(P, P) returns
>>>> false we know for sure that H was *incorrect* on that input.
>>>
>>> P(P) only halts because H(P,P) correctly decides that its input never
>>> halts and aborts this input on that basis.
>>
>> X only halts because Y IMPLIES that X halts. That's basic logic.
>>
>> The definition of halting does not refer at all to the *reason* why a
>> particular computation halts.
>>
>
> The P that halts seems to contradict that H(P,P)==0 is correct yet it is
> verifiable that H(P,P)==0 is correct.

P(P) is either in the set of halting computations or it is not. It can't
be both.

Since halting is a property defined *solely* in terms of the behaviour
of the *actual* computation in question, we know that P(P) is in this
set. Therefore H(P, P) == 0 *cannot* be verifiably correct.

> That you keep ignoring this means that you are dishonest.

I am not ignoring this. I am asserting that it is false.

To consider your earlier poor analogy:

"if int add(int x, int y) returns 5 on add(2,3) we know for sure that
add was correct on that input."

The above as stated leaves out a critical piece. if int add(int x, int
y) returns 5 on add(2,3) we know for sure that add was correct on that
input *because* we know independently that 5 is actually the correct answer.

What you are claiming is more analogous to the claim that:

if int add(int x, int y) returns 9 on add(2,3) we know for sure that add
was correct on that input.

Which of course is rubbish if add(x, y) is purported to do what its name
suggests.

André

>> "The airplane crashed "only" because it ran out of fuel" IMPLIES that
>> the airplane crashed.
>>
>> "The man was arrested "only" because the police chief held a grudge"
>> IMPLIES that the man was arrested.
>>
>> Why you think that 'halting' works differently from these examples
>> remains a mystery.
>>
>> If you want to determine the correct answer to "does P(P) halt?", you
>> need look only at the behaviour of P(P), not at your traces. In fact,
>> you *shouldn't* look at anything other than the behaviour of P(P)
>> because halting is defined *entirely* in terms of the behaviour of P(P).
>>
>> If it is the case that P(P) "only" halts because H(P, P) returns
>> false, it still halts, which means that H(P, P) *incorrectly* returns
>> false.
>>
>>> Until you pay enough attention to see and acknowledge this I will
>>> simply assume that you are dishonest.
>>
>> As is the case with virtually all of your terms, I assume you also
>> have some private definition of 'dishonest'.

On 8/9/2021 8:47 PM, André G. Isaak wrote:
> On 2021-08-09 16:47, olcott wrote:
>> On 8/9/2021 5:43 PM, André G. Isaak wrote:
>>> On 2021-08-09 16:21, olcott wrote:
>>>> On 8/9/2021 5:17 PM, André G. Isaak wrote:
>>>>> On 2021-08-09 15:12, olcott wrote:
>>>>>> On 8/9/2021 2:38 PM, André G. Isaak wrote:
>>>>>>> On 2021-08-09 10:57, olcott wrote:
>>>>>>>> On 8/8/2021 1:50 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-08-06 22:23, olcott wrote:
>>>>>>>>>> On 8/6/2021 10:55 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-08-06 09:59, olcott wrote:
>>>>>>>>>
>>>>>>>>>>> Yes, but bear in mind that 'halting' refers to Turing
>>>>>>>>>>> Machines operating on a specific input. It does not refer to
>>>>>>>>>>> simulations or what happens inside a halting decider. It
>>>>>>>>>>> refers *only* to actual computations, i.e. an actual Turing
>>>>>>>>>>> Machine operating on an actual input string.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So yet again you prove that you are totally clueless that pure
>>>>>>>>>> simulations are computationally equivalent to direct executions ?
>>>>>>>>>
>>>>>>>>> Your H is not a pure simulator
>>>>>>>>>
>>>>>>>>
>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>    if (H(x, x))
>>>>>>>>      HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00000d02](01)  55          push ebp
>>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>>> [00000d1c](01)  c3          ret
>>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>>
>>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>>      address   address   data      code        language
>>>>>>>>      ========  ========  ========  =========   =============
>>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  //
>>>>>>>> call H
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       //
>>>>>>>> push P
>>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       //
>>>>>>>> push P
>>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  //
>>>>>>>> call H
>>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       //
>>>>>>>> push P
>>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       //
>>>>>>>> push P
>>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  //
>>>>>>>> call H
>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>>
>>>>>>>> The fact that the execution trace of the simulation of P(P) on
>>>>>>>> page 6 perfectly matches its source-code on page 5 conclusively
>>>>>>>> proves that this execution trace performed by H is a pure
>>>>>>>> simulation of P(P). There is no correct basis for disagreement,
>>>>>>>> therefore anyone disagreeing either does not know the x86
>>>>>>>> language or they are simply lying.
>>>>>>>
>>>>>>> You have a *partial trace* and *partial source code*. Neither
>>>>>>> shows what happens at B82.
>>>>>>>
>>>>>>
>>>>>> if int add(int x, int y) returns 5 on add(2,3) we know for sure
>>>>>> that add was correct on that input.
>>>>>
>>>>> That is a poor analogy since 5 actually *is* the correct answer to
>>>>> 2+3.
>>>>>
>>>>> We know that P(P) *does* halt, which means that if H(P, P) returns
>>>>> false we know for sure that H was *incorrect* on that input.
>>>>
>>>> P(P) only halts because H(P,P) correctly decides that its input
>>>> never halts and aborts this input on that basis.
>>>
>>> X only halts because Y IMPLIES that X halts. That's basic logic.
>>>
>>> The definition of halting does not refer at all to the *reason* why a
>>> particular computation halts.
>>>
>>
>> The P that halts seems to contradict that H(P,P)==0 is correct yet it
>> is verifiable that H(P,P)==0 is correct.
>
> P(P) is either in the set of halting computations or it is not. It can't
> be both.
>
> Since halting is a property defined *solely* in terms of the behaviour
> of the *actual* computation in question, we know that P(P) is in this
> set. Therefore H(P, P) == 0 *cannot* be verifiably correct.
>
>> That you keep ignoring this means that you are dishonest.
>
> I am not ignoring this. I am asserting that it is false.
>

_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H

Begin Local Halt Decider Simulation at Machine Address:d02
....[00000d02][002118f1][002118f5] 55 push ebp
....[00000d03][002118f1][002118f5] 8bec mov ebp,esp
....[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
....[00000d08][002118ed][00000d02] 50 push eax // push P
....[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][002118e9][00000d02] 51 push ecx // push P
....[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
....[00000d02][0025c319][0025c31d] 55 push ebp
....[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
....[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
....[00000d08][0025c315][00000d02] 50 push eax // push P
....[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][0025c311][00000d02] 51 push ecx // push P
....[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

On 2021-08-10 09:07, olcott wrote:
> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>> On 2021-08-09 16:47, olcott wrote:

>>> The P that halts seems to contradict that H(P,P)==0 is correct yet it
>>> is verifiable that H(P,P)==0 is correct.
>>
>> P(P) is either in the set of halting computations or it is not. It
>> can't be both.
>>
>> Since halting is a property defined *solely* in terms of the behaviour
>> of the *actual* computation in question, we know that P(P) is in this
>> set. Therefore H(P, P) == 0 *cannot* be verifiably correct.
>>
>>> That you keep ignoring this means that you are dishonest.
>>
>> I am not ignoring this. I am asserting that it is false.
>>
>
>
>
> _P()
> [00000d02](01)  55          push ebp
> [00000d03](02)  8bec        mov ebp,esp
> [00000d05](03)  8b4508      mov eax,[ebp+08]
> [00000d08](01)  50          push eax       // push 2nd Param
> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
> [00000d0c](01)  51          push ecx       // push 1st Param
> [00000d0d](05)  e870feffff  call 00000b82  // call H
> [00000d12](03)  83c408      add esp,+08
> [00000d15](02)  85c0        test eax,eax
> [00000d17](02)  7402        jz 00000d1b
> [00000d19](02)  ebfe        jmp 00000d19
> [00000d1b](01)  5d          pop ebp
> [00000d1c](01)  c3          ret
> Size in bytes:(0027) [00000d1c]
>
>     machine   stack     stack     machine     assembly
>     address   address   data      code        language
>     ========  ========  ========  =========   =============
> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>
> Begin Local Halt Decider Simulation at Machine Address:d02
> ...[00000d02][002118f1][002118f5] 55          push ebp
> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
> ...[00000d02][0025c319][0025c31d] 55          push ebp
> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> We can see that the above is a pure simulation of P on input P.

It *isn't* a pure simulation since a pure simulation cannot abort its input.

> We can see that the above cannot possibly stop running unless H aborts
> its simulation of P on input P.

Except you are aborting in the *wrong* place. That cannot be seen in the
above trace since you don't actually *show* the code at B82, and your
message that the simulation was stopped doesn't tell us *which*
invocation of H aborted *which* simulation.

When P(P) is computed, it is the H contained in the outermost P which
aborts the simulation, and control is then returned to that H and then
to P which halts.

When you run H(P, P) it is the *outermost* H which aborts the simulation
of P *rather* than the H contained in the outermost P. This means your
"simulation" is not an accurate one since it does something different
from when the computation is performed independently.

You keep stressing that a simulation is "equivalent" to the computation
itself. That means your simulation must actually do *exactly* the same
thing as the actual computation which yours does not, which means your
"simulation" cannot be used to demonstrate anything about the actual
computation under consideration.

> We can see that even if H does aborts its simulation of P on input P
> that P never reaches its final state, thus never halts even though its
> stops running.
>
> Until you acknowledge these things or prove that the above P does reach
> its final state you are simply a liar. Proving that a different P
> reaches its final state is a dishonest dodge, thus also dishonest.

What do you mean by "a different P"? There is only one Turing Machine P
under consideration, and that Turing Machine clearly halts when given
its own representation as an input.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/10/2021 10:28 AM, André G. Isaak wrote:
> On 2021-08-10 09:07, olcott wrote:
>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>> On 2021-08-09 16:47, olcott wrote:
>
>>>> The P that halts seems to contradict that H(P,P)==0 is correct yet
>>>> it is verifiable that H(P,P)==0 is correct.
>>>
>>> P(P) is either in the set of halting computations or it is not. It
>>> can't be both.
>>>
>>> Since halting is a property defined *solely* in terms of the
>>> behaviour of the *actual* computation in question, we know that P(P)
>>> is in this set. Therefore H(P, P) == 0 *cannot* be verifiably correct.
>>>
>>>> That you keep ignoring this means that you are dishonest.
>>>
>>> I am not ignoring this. I am asserting that it is false.
>>>
>>
>>
>>
>> _P()
>> [00000d02](01)  55          push ebp
>> [00000d03](02)  8bec        mov ebp,esp
>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>> [00000d08](01)  50          push eax       // push 2nd Param
>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>> [00000d0c](01)  51          push ecx       // push 1st Param
>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>> [00000d12](03)  83c408      add esp,+08
>> [00000d15](02)  85c0        test eax,eax
>> [00000d17](02)  7402        jz 00000d1b
>> [00000d19](02)  ebfe        jmp 00000d19
>> [00000d1b](01)  5d          pop ebp
>> [00000d1c](01)  c3          ret
>> Size in bytes:(0027) [00000d1c]
>>
>>      machine   stack     stack     machine     assembly
>>      address   address   data      code        language
>>      ========  ========  ========  =========   =============
>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>>
>> Begin Local Halt Decider Simulation at Machine Address:d02
>> ...[00000d02][002118f1][002118f5] 55          push ebp
>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> We can see that the above is a pure simulation of P on input P.
>
> It *isn't* a pure simulation since a pure simulation cannot abort its
> input.
>

Yet another dishonest dodge. The above is a pure simulation, Only
*AFTER* the above is there any aborting of the simulation.

>> We can see that the above cannot possibly stop running unless H aborts
>> its simulation of P on input P.
>
> Except you are aborting in the *wrong* place. That cannot be seen in the
> above trace since you don't actually *show* the code at B82, and your
> message that the simulation was stopped doesn't tell us *which*
> invocation of H aborted *which* simulation.
>

It does not matter which simulation was aborted and you know this. You
are nit picking at irrelevant details because you have no actual rebuttal.

> When P(P) is computed, it is the H contained in the outermost P which
> aborts the simulation, and control is then returned to that H and then
> to P which halts.
>

This also does not matter, thus yet another dishonest dodge. What
matters is that unless the input to H(P,P) is aborted it never stops
running thus conclusively proving that the decision of some H to abort
the simulation of some P was correct.

There is no correct rebuttal to this.

> When you run H(P, P) it is the *outermost* H which aborts the simulation
> of P *rather* than the H contained in the outermost P. This means your
> "simulation" is not an accurate one since it does something different
> from when the computation is performed independently.
>
> You keep stressing that a simulation is "equivalent" to the computation
> itself. That means your simulation must actually do *exactly* the same
> thing as the actual computation which yours does not, which means your
> "simulation" cannot be used to demonstrate anything about the actual
> computation under consideration.
>
>> We can see that even if H does aborts its simulation of P on input P
>> that P never reaches its final state, thus never halts even though its
>> stops running.
>>
>> Until you acknowledge these things or prove that the above P does
>> reach its final state you are simply a liar. Proving that a different
>> P reaches its final state is a dishonest dodge, thus also dishonest.
>
> What do you mean by "a different P"? There is only one Turing Machine P
> under consideration, and that Turing Machine clearly halts when given
> its own representation as an input.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 2021-08-10 10:59, olcott wrote:
> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>> On 2021-08-10 09:07, olcott wrote:
>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>> On 2021-08-09 16:47, olcott wrote:
>>
>>>>> The P that halts seems to contradict that H(P,P)==0 is correct yet
>>>>> it is verifiable that H(P,P)==0 is correct.
>>>>
>>>> P(P) is either in the set of halting computations or it is not. It
>>>> can't be both.
>>>>
>>>> Since halting is a property defined *solely* in terms of the
>>>> behaviour of the *actual* computation in question, we know that P(P)
>>>> is in this set. Therefore H(P, P) == 0 *cannot* be verifiably correct.
>>>>
>>>>> That you keep ignoring this means that you are dishonest.
>>>>
>>>> I am not ignoring this. I am asserting that it is false.
>>>>
>>>
>>>
>>>
>>> _P()
>>> [00000d02](01)  55          push ebp
>>> [00000d03](02)  8bec        mov ebp,esp
>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>> [00000d08](01)  50          push eax       // push 2nd Param
>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>> [00000d12](03)  83c408      add esp,+08
>>> [00000d15](02)  85c0        test eax,eax
>>> [00000d17](02)  7402        jz 00000d1b
>>> [00000d19](02)  ebfe        jmp 00000d19
>>> [00000d1b](01)  5d          pop ebp
>>> [00000d1c](01)  c3          ret
>>> Size in bytes:(0027) [00000d1c]
>>>
>>>      machine   stack     stack     machine     assembly
>>>      address   address   data      code        language
>>>      ========  ========  ========  =========   =============
>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>>>
>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> We can see that the above is a pure simulation of P on input P.
>>
>> It *isn't* a pure simulation since a pure simulation cannot abort its
>> input.
>>
>
> Yet another dishonest dodge. The above is a pure simulation, Only
> *AFTER* the above is there any aborting of the simulation.

But what happens *after* this is exactly what is critical, since that
determines where control returns to once the simulation is aborted. We
need to know *which* specific call to H does the aborting.

>>> We can see that the above cannot possibly stop running unless H
>>> aborts its simulation of P on input P.
>>
>> Except you are aborting in the *wrong* place. That cannot be seen in
>> the above trace since you don't actually *show* the code at B82, and
>> your message that the simulation was stopped doesn't tell us *which*
>> invocation of H aborted *which* simulation.
>>
>
> It does not matter which simulation was aborted and you know this. You
> are nit picking at irrelevant details because you have no actual rebuttal.

Of course it matters.

>> When P(P) is computed, it is the H contained in the outermost P which
>> aborts the simulation, and control is then returned to that H and then
>> to P which halts.
>>
>
> This also does not matter, thus yet another dishonest dodge. What
> matters is that unless the input to H(P,P) is aborted it never stops

Again, of course it matters. You can't claim that H is *accurately*
simulating P(P) and also claim that it doesn't matter which invocation
of H does the aborting. If it's not the same one in both cases, then you
are *not* accurately simulating P(P).

You want to insist that people look at what happens in the simulation
taking place inside H(P, P) *rather* than the actual computation P(P) on
the grounds that "a simulation is computationally equivalent to the
thing being simulated".

But you can't have it both ways. Either the simulation of P(P) inside H
and P(P) run independently are computationally equivalent or they
aren't. You can't claim they are computationally equivalent yet behave
differently.

If your simulation were really accurate, H(P, P) would *not* abort the
simulation of its input. Rather, the H called by the outermost P in that
simulation would abort the simulation of *its* input at which point
control would return to the outermost P, at which point that P would halt.

Why?

BECAUSE THAT'S WHAT HAPPENS WHEN P(P) IS RUN INDEPENDENTLY! And that's
what H(P, P) is supposedly a 'pure simulation' of.

> running thus conclusively proving that the decision of some H to abort
> the simulation of some P was correct.

The decision of 'some' H isn't what we're interested in. We're
specifically interested in the decision of the outermost H in H(P, P)
vs. the H inside the outermost P being simulated by H(P, P). They're not
the same thing. It matters which one does the aborting.

> There is no correct rebuttal to this.

Yes, there is, and it has been given to you many times. You simply have
some sort of pathological block against attempting to process it.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/10/2021 12:36 PM, André G. Isaak wrote:
> On 2021-08-10 10:59, olcott wrote:
>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>> On 2021-08-10 09:07, olcott wrote:
>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>> On 2021-08-09 16:47, olcott wrote:
>>>
>>>>>> The P that halts seems to contradict that H(P,P)==0 is correct yet
>>>>>> it is verifiable that H(P,P)==0 is correct.
>>>>>
>>>>> P(P) is either in the set of halting computations or it is not. It
>>>>> can't be both.
>>>>>
>>>>> Since halting is a property defined *solely* in terms of the
>>>>> behaviour of the *actual* computation in question, we know that
>>>>> P(P) is in this set. Therefore H(P, P) == 0 *cannot* be verifiably
>>>>> correct.
>>>>>
>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>
>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>
>>>>
>>>>
>>>>
>>>> _P()
>>>> [00000d02](01)  55          push ebp
>>>> [00000d03](02)  8bec        mov ebp,esp
>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>> [00000d12](03)  83c408      add esp,+08
>>>> [00000d15](02)  85c0        test eax,eax
>>>> [00000d17](02)  7402        jz 00000d1b
>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>> [00000d1b](01)  5d          pop ebp
>>>> [00000d1c](01)  c3          ret
>>>> Size in bytes:(0027) [00000d1c]
>>>>
>>>>      machine   stack     stack     machine     assembly
>>>>      address   address   data      code        language
>>>>      ========  ========  ========  =========   =============
>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> We can see that the above is a pure simulation of P on input P.
>>>
>>> It *isn't* a pure simulation since a pure simulation cannot abort its
>>> input.
>>>
>>
>> Yet another dishonest dodge. The above is a pure simulation, Only
>> *AFTER* the above is there any aborting of the simulation.
>
> But what happens *after* this is exactly what is critical,

No it is not. What can be seen while H is in pure simulator mode
conclusively proves that unless some H aborts some P that neither H nor
P will ever stop running.

> since that
> determines where control returns to once the simulation is aborted. We
> need to know *which* specific call to H does the aborting.
>
>>>> We can see that the above cannot possibly stop running unless H
>>>> aborts its simulation of P on input P.
>>>
>>> Except you are aborting in the *wrong* place. That cannot be seen in
>>> the above trace since you don't actually *show* the code at B82, and
>>> your message that the simulation was stopped doesn't tell us *which*
>>> invocation of H aborted *which* simulation.
>>>
>>
>> It does not matter which simulation was aborted and you know this. You
>> are nit picking at irrelevant details because you have no actual
>> rebuttal.
>
> Of course it matters.
>
>>> When P(P) is computed, it is the H contained in the outermost P which
>>> aborts the simulation, and control is then returned to that H and
>>> then to P which halts.
>>>
>>
>> This also does not matter, thus yet another dishonest dodge. What
>> matters is that unless the input to H(P,P) is aborted it never stops
>
> Again, of course it matters. You can't claim that H is *accurately*
> simulating P(P) and also claim that it doesn't matter which invocation
> of H does the aborting. If it's not the same one in both cases, then you
> are *not* accurately simulating P(P).
>
> You want to insist that people look at what happens in the simulation
> taking place inside H(P, P) *rather* than the actual computation P(P) on
> the grounds that "a simulation is computationally equivalent to the
> thing being simulated".
>
> But you can't have it both ways. Either the simulation of P(P) inside H
> and P(P) run independently are computationally equivalent or they
> aren't. You can't claim they are computationally equivalent yet behave
> differently.
>
> If your simulation were really accurate, H(P, P) would *not* abort the
> simulation of its input. Rather, the H called by the outermost P in that
> simulation would abort the simulation of *its* input at which point
> control would return to the outermost P, at which point that P would halt.
>
> Why?
>
> BECAUSE THAT'S WHAT HAPPENS WHEN P(P) IS RUN INDEPENDENTLY! And that's
> what H(P, P) is supposedly a 'pure simulation' of.
>
>> running thus conclusively proving that the decision of some H to abort
>> the simulation of some P was correct.
>
> The decision of 'some' H isn't what we're interested in. We're
> specifically interested in the decision of the outermost H in H(P, P)
> vs. the H inside the outermost P being simulated by H(P, P). They're not
> the same thing. It matters which one does the aborting.
>
>> There is no correct rebuttal to this.
>
> Yes, there is, and it has been given to you many times. You simply have
> some sort of pathological block against attempting to process it.
>
> André
>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/8/2021 7:27 AM, Alan Mackenzie wrote:
> olcott <NoOne@nowhere.com> wrote:
>
> [ .... ]
>
>> If you wanted an actual honest dialogue you would use logic and
>> reasoning to show exactly how the simulated P would reach its final
>> state of [00000d1c] when we know that H is a pure x86 emulator of P
>> until it makes its halt status decision.
>
> How dare you try to tell me how to conduct a dialogue.

Whenever anyone is challenged to provide reasoning to support their
position and they respond to emotionally charged rhetoric and no
reasoning we generally have sufficient reason to conclude that they are
a liar.

> If I wanted an
> actual honest dialogue, I wouldn't chose you as my dialogue partner. You
> are not honest.
>
> You have been lying about the existence of your H for a very long time.
> But you are not a sufficiently consequent liar. There's something
> stopping you from moving from implicitly asserting the existence of H to
> barefaced lying about it.
>
> So, i challenge you once more. Either assert the actual existence of
> your H, or admit it does not exist.
>
>> On the other hand if you were a mere liar you would use all kinds of
>> subterfuge an rhetoric to avoid this direct challenge.
>
> As I've said often enough before, I don't lie on Usenet, ever.
>
> [ .... ]
>
>> --
>> Copyright 2021 Pete Olcott
>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 2021-08-10 12:39, olcott wrote:
> On 8/10/2021 12:36 PM, André G. Isaak wrote:
>> On 2021-08-10 10:59, olcott wrote:
>>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>>> On 2021-08-10 09:07, olcott wrote:
>>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>>> On 2021-08-09 16:47, olcott wrote:
>>>>
>>>>>>> The P that halts seems to contradict that H(P,P)==0 is correct
>>>>>>> yet it is verifiable that H(P,P)==0 is correct.
>>>>>>
>>>>>> P(P) is either in the set of halting computations or it is not. It
>>>>>> can't be both.
>>>>>>
>>>>>> Since halting is a property defined *solely* in terms of the
>>>>>> behaviour of the *actual* computation in question, we know that
>>>>>> P(P) is in this set. Therefore H(P, P) == 0 *cannot* be verifiably
>>>>>> correct.
>>>>>>
>>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>>
>>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _P()
>>>>> [00000d02](01)  55          push ebp
>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>> [00000d12](03)  83c408      add esp,+08
>>>>> [00000d15](02)  85c0        test eax,eax
>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>> [00000d1b](01)  5d          pop ebp
>>>>> [00000d1c](01)  c3          ret
>>>>> Size in bytes:(0027) [00000d1c]
>>>>>
>>>>>      machine   stack     stack     machine     assembly
>>>>>      address   address   data      code        language
>>>>>      ========  ========  ========  =========   =============
>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>
>>>>> We can see that the above is a pure simulation of P on input P.
>>>>
>>>> It *isn't* a pure simulation since a pure simulation cannot abort
>>>> its input.
>>>>
>>>
>>> Yet another dishonest dodge. The above is a pure simulation, Only
>>> *AFTER* the above is there any aborting of the simulation.
>>
>> But what happens *after* this is exactly what is critical,
>
> No it is not. What can be seen while H is in pure simulator mode
> conclusively proves that unless some H aborts some P that neither H nor
> P will ever stop running.

But whether *some* H aborts *some* P isn't the question H(P, P) is
supposed to answer. It's suppose answer the question "does P(P), run as
an independent computation, halt". You keep trying to invent new
questions which you claim are somehow "equivalent" to the above
question, but if two questions do not always result in the exact same
answer then they *cannot* be equivalent.

People have agreed to the fact that if it really were the case that a
simulating halt decider *must* abort its input, then that would entail
that its input represents a non-halting computation. But that's *only*
defensible if it is interpreted as meaning that that a *specific* H must
abort its input or the input to that *specific* H wouldn't halt, not
merely that *some* H aborts its input somewhere.

The outermost H in H(P, P) doesn't *need* to abort its input, nor
*should* it abort its input given that when P(P) is run independently,
the H contained in P aborts its input thereby allowing the outermost P
to halt.

Given that P(P) halts, any 'decider' which claims that it does not is
simply wrong. Given that P(P) halts, any 'simulating decider' which
claims that it *must* abort its simulation rather than allow the
simulation to terminate on its own is not accurately simulating P(P) or
is using illegitimate criteria to determine that it "must" abort its
simulation.

It is the *actual* behaviour of P(P) which *unequivocally* determines
which answer any halt decider must give if it really correctly decides
halting. There's simply no way around that fact. You will *never* be
taken seriously by anyone if you keep trying to justify your claim that
a demonstrably incorrect answer is somehow "correct".

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/10/2021 3:33 PM, André G. Isaak wrote:
> On 2021-08-10 12:39, olcott wrote:
>> On 8/10/2021 12:36 PM, André G. Isaak wrote:
>>> On 2021-08-10 10:59, olcott wrote:
>>>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>>>> On 2021-08-10 09:07, olcott wrote:
>>>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>>>> On 2021-08-09 16:47, olcott wrote:
>>>>>
>>>>>>>> The P that halts seems to contradict that H(P,P)==0 is correct
>>>>>>>> yet it is verifiable that H(P,P)==0 is correct.
>>>>>>>
>>>>>>> P(P) is either in the set of halting computations or it is not.
>>>>>>> It can't be both.
>>>>>>>
>>>>>>> Since halting is a property defined *solely* in terms of the
>>>>>>> behaviour of the *actual* computation in question, we know that
>>>>>>> P(P) is in this set. Therefore H(P, P) == 0 *cannot* be
>>>>>>> verifiably correct.
>>>>>>>
>>>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>>>
>>>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _P()
>>>>>> [00000d02](01)  55          push ebp
>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>> [00000d1c](01)  c3          ret
>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>
>>>>>>      machine   stack     stack     machine     assembly
>>>>>>      address   address   data      code        language
>>>>>>      ========  ========  ========  =========   =============
>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  //
>>>>>> call H
>>>>>>
>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       //
>>>>>> push P
>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       //
>>>>>> push P
>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  //
>>>>>> call H
>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       //
>>>>>> push P
>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       //
>>>>>> push P
>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  //
>>>>>> call H
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>
>>>>>> We can see that the above is a pure simulation of P on input P.
>>>>>
>>>>> It *isn't* a pure simulation since a pure simulation cannot abort
>>>>> its input.
>>>>>
>>>>
>>>> Yet another dishonest dodge. The above is a pure simulation, Only
>>>> *AFTER* the above is there any aborting of the simulation.
>>>
>>> But what happens *after* this is exactly what is critical,
>>
>> No it is not. What can be seen while H is in pure simulator mode
>> conclusively proves that unless some H aborts some P that neither H
>> nor P will ever stop running.
>
> But whether *some* H aborts *some* P isn't the question H(P, P) is
> supposed to answer.

When we know that some H must abort some P we know for sure that this H
did abort that P correctly. Until you are honest enough to agree to that
I will not respond to you.

> It's suppose answer the question "does P(P), run as
> an independent computation, halt".  You keep trying to invent new
> questions which you claim are somehow "equivalent" to the above
> question, but if two questions do not always result in the exact same
> answer then they *cannot* be equivalent.
>
> People have agreed to the fact that if it really were the case that a
> simulating halt decider *must* abort its input, then that would entail
> that its input represents a non-halting computation. But that's *only*
> defensible if it is interpreted as meaning that that a *specific* H must
> abort its input or the input to that *specific* H wouldn't halt, not
> merely that *some* H aborts its input somewhere.
>
> The outermost H in H(P, P) doesn't *need* to abort its input, nor
> *should* it abort its input given that when P(P) is run independently,
> the H contained in P aborts its input thereby allowing the outermost P
> to halt.
>
> Given that P(P) halts, any 'decider' which claims that it does not is
> simply wrong. Given that P(P) halts, any 'simulating decider' which
> claims that it *must* abort its simulation rather than allow the
> simulation to terminate on its own is not accurately simulating P(P) or
> is using illegitimate criteria to determine that it "must" abort its
> simulation.
>
> It is the *actual* behaviour of P(P) which *unequivocally* determines
> which answer any halt decider must give if it really correctly decides
> halting. There's simply no way around that fact. You will *never* be
> taken seriously by anyone if you keep trying to justify your claim that
> a demonstrably incorrect answer is somehow "correct".
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 2021-08-10 15:27, olcott wrote:
> On 8/10/2021 3:33 PM, André G. Isaak wrote:
>> On 2021-08-10 12:39, olcott wrote:
>>> On 8/10/2021 12:36 PM, André G. Isaak wrote:
>>>> On 2021-08-10 10:59, olcott wrote:
>>>>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>>>>> On 2021-08-10 09:07, olcott wrote:
>>>>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>>>>> On 2021-08-09 16:47, olcott wrote:
>>>>>>
>>>>>>>>> The P that halts seems to contradict that H(P,P)==0 is correct
>>>>>>>>> yet it is verifiable that H(P,P)==0 is correct.
>>>>>>>>
>>>>>>>> P(P) is either in the set of halting computations or it is not.
>>>>>>>> It can't be both.
>>>>>>>>
>>>>>>>> Since halting is a property defined *solely* in terms of the
>>>>>>>> behaviour of the *actual* computation in question, we know that
>>>>>>>> P(P) is in this set. Therefore H(P, P) == 0 *cannot* be
>>>>>>>> verifiably correct.
>>>>>>>>
>>>>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>>>>
>>>>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _P()
>>>>>>> [00000d02](01)  55          push ebp
>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>> [00000d1c](01)  c3          ret
>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>
>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>      address   address   data      code        language
>>>>>>>      ========  ========  ========  =========   =============
>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  //
>>>>>>> call H
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       //
>>>>>>> push P
>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       //
>>>>>>> push P
>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  //
>>>>>>> call H
>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       //
>>>>>>> push P
>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       //
>>>>>>> push P
>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  //
>>>>>>> call H
>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>
>>>>>>> We can see that the above is a pure simulation of P on input P.
>>>>>>
>>>>>> It *isn't* a pure simulation since a pure simulation cannot abort
>>>>>> its input.
>>>>>>
>>>>>
>>>>> Yet another dishonest dodge. The above is a pure simulation, Only
>>>>> *AFTER* the above is there any aborting of the simulation.
>>>>
>>>> But what happens *after* this is exactly what is critical,
>>>
>>> No it is not. What can be seen while H is in pure simulator mode
>>> conclusively proves that unless some H aborts some P that neither H
>>> nor P will ever stop running.
>>
>> But whether *some* H aborts *some* P isn't the question H(P, P) is
>> supposed to answer.
>
>
> When we know that some H must abort some P we know for sure that this H
> did abort that P correctly. Until you are honest enough to agree to that
> I will not respond to you.

Let's see if that reasoning works...

Dr. Halstead knew that *some* baby needed to be aborted.
Therefore he was correct in aborting Mrs. Smith's baby.

Something doesn't seem quite right with that...

>
>> It's suppose answer the question "does P(P), run as an independent
>> computation, halt".  You keep trying to invent new questions which you
>> claim are somehow "equivalent" to the above question, but if two
>> questions do not always result in the exact same answer then they
>> *cannot* be equivalent.

Did you even try to address the above?

>> People have agreed to the fact that if it really were the case that a
>> simulating halt decider *must* abort its input, then that would entail
>> that its input represents a non-halting computation. But that's *only*
>> defensible if it is interpreted as meaning that that a *specific* H
>> must abort its input or the input to that *specific* H wouldn't halt,
>> not merely that *some* H aborts its input somewhere.
>>
>> The outermost H in H(P, P) doesn't *need* to abort its input, nor
>> *should* it abort its input given that when P(P) is run independently,
>> the H contained in P aborts its input thereby allowing the outermost P
>> to halt.

Did you even read the above two paragraphs which make it clear that
"some H aborts its input" definitely does not entail that "the outermost
H needs to abort its input"

>> Given that P(P) halts, any 'decider' which claims that it does not is
>> simply wrong. Given that P(P) halts, any 'simulating decider' which
>> claims that it *must* abort its simulation rather than allow the
>> simulation to terminate on its own is not accurately simulating P(P)
>> or is using illegitimate criteria to determine that it "must" abort
>> its simulation.

Did you even try to address the above?

>> It is the *actual* behaviour of P(P) which *unequivocally* determines
>> which answer any halt decider must give if it really correctly decides
>> halting. There's simply no way around that fact. You will *never* be
>> taken seriously by anyone if you keep trying to justify your claim
>> that a demonstrably incorrect answer is somehow "correct".

Did you even try to address the above?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/10/2021 4:36 PM, André G. Isaak wrote:
> On 2021-08-10 15:27, olcott wrote:
>> On 8/10/2021 3:33 PM, André G. Isaak wrote:
>>> On 2021-08-10 12:39, olcott wrote:
>>>> On 8/10/2021 12:36 PM, André G. Isaak wrote:
>>>>> On 2021-08-10 10:59, olcott wrote:
>>>>>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>>>>>> On 2021-08-10 09:07, olcott wrote:
>>>>>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-08-09 16:47, olcott wrote:
>>>>>>>
>>>>>>>>>> The P that halts seems to contradict that H(P,P)==0 is correct
>>>>>>>>>> yet it is verifiable that H(P,P)==0 is correct.
>>>>>>>>>
>>>>>>>>> P(P) is either in the set of halting computations or it is not.
>>>>>>>>> It can't be both.
>>>>>>>>>
>>>>>>>>> Since halting is a property defined *solely* in terms of the
>>>>>>>>> behaviour of the *actual* computation in question, we know that
>>>>>>>>> P(P) is in this set. Therefore H(P, P) == 0 *cannot* be
>>>>>>>>> verifiably correct.
>>>>>>>>>
>>>>>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>>>>>
>>>>>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00000d02](01)  55          push ebp
>>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>>> [00000d1c](01)  c3          ret
>>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>>
>>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>>      address   address   data      code        language
>>>>>>>>      ========  ========  ========  =========   =============
>>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  //
>>>>>>>> call H
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       //
>>>>>>>> push P
>>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       //
>>>>>>>> push P
>>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  //
>>>>>>>> call H
>>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       //
>>>>>>>> push P
>>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       //
>>>>>>>> push P
>>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  //
>>>>>>>> call H
>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>>
>>>>>>>> We can see that the above is a pure simulation of P on input P.
>>>>>>>
>>>>>>> It *isn't* a pure simulation since a pure simulation cannot abort
>>>>>>> its input.
>>>>>>>
>>>>>>
>>>>>> Yet another dishonest dodge. The above is a pure simulation, Only
>>>>>> *AFTER* the above is there any aborting of the simulation.
>>>>>
>>>>> But what happens *after* this is exactly what is critical,
>>>>
>>>> No it is not. What can be seen while H is in pure simulator mode
>>>> conclusively proves that unless some H aborts some P that neither H
>>>> nor P will ever stop running.
>>>
>>> But whether *some* H aborts *some* P isn't the question H(P, P) is
>>> supposed to answer.
>>
>>
>> When we know that some H must abort some P we know for sure that this
>> H did abort that P correctly. Until you are honest enough to agree to
>> that I will not respond to you.
>
> Let's see if that reasoning works...
>
> Dr. Halstead knew that *some* baby needed to be aborted.
> Therefore he was correct in aborting Mrs. Smith's baby.
>
> Something doesn't seem quite right with that...

This seem to indicate that you have little interest in an honest dialogue.

When we know (by logical necessity) that some H must abort some P we
know for sure that this H did abort that P correctly.

Until you are honest enough to agree to that I will not respond to you.

>
>>
>>> It's suppose answer the question "does P(P), run as an independent
>>> computation, halt".  You keep trying to invent new questions which
>>> you claim are somehow "equivalent" to the above question, but if two
>>> questions do not always result in the exact same answer then they
>>> *cannot* be equivalent.
>
> Did you even try to address the above?
>
>>> People have agreed to the fact that if it really were the case that a
>>> simulating halt decider *must* abort its input, then that would
>>> entail that its input represents a non-halting computation. But
>>> that's *only* defensible if it is interpreted as meaning that that a
>>> *specific* H must abort its input or the input to that *specific* H
>>> wouldn't halt, not merely that *some* H aborts its input somewhere.
>>>
>>> The outermost H in H(P, P) doesn't *need* to abort its input, nor
>>> *should* it abort its input given that when P(P) is run
>>> independently, the H contained in P aborts its input thereby allowing
>>> the outermost P to halt.
>
> Did you even read the above two paragraphs which make it clear that
> "some H aborts its input" definitely does not entail that "the outermost
> H needs to abort its input"
>
>>> Given that P(P) halts, any 'decider' which claims that it does not is
>>> simply wrong. Given that P(P) halts, any 'simulating decider' which
>>> claims that it *must* abort its simulation rather than allow the
>>> simulation to terminate on its own is not accurately simulating P(P)
>>> or is using illegitimate criteria to determine that it "must" abort
>>> its simulation.
>
> Did you even try to address the above?
>
>>> It is the *actual* behaviour of P(P) which *unequivocally* determines
>>> which answer any halt decider must give if it really correctly
>>> decides halting. There's simply no way around that fact. You will
>>> *never* be taken seriously by anyone if you keep trying to justify
>>> your claim that a demonstrably incorrect answer is somehow "correct".
>
> Did you even try to address the above?
>
> André
>

On 2021-08-10 15:54, olcott wrote:
> On 8/10/2021 4:36 PM, André G. Isaak wrote:
>> On 2021-08-10 15:27, olcott wrote:
>>> On 8/10/2021 3:33 PM, André G. Isaak wrote:
>>>> On 2021-08-10 12:39, olcott wrote:
>>>>> On 8/10/2021 12:36 PM, André G. Isaak wrote:
>>>>>> On 2021-08-10 10:59, olcott wrote:
>>>>>>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>>>>>>> On 2021-08-10 09:07, olcott wrote:
>>>>>>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-08-09 16:47, olcott wrote:
>>>>>>>>
>>>>>>>>>>> The P that halts seems to contradict that H(P,P)==0 is
>>>>>>>>>>> correct yet it is verifiable that H(P,P)==0 is correct.
>>>>>>>>>>
>>>>>>>>>> P(P) is either in the set of halting computations or it is
>>>>>>>>>> not. It can't be both.
>>>>>>>>>>
>>>>>>>>>> Since halting is a property defined *solely* in terms of the
>>>>>>>>>> behaviour of the *actual* computation in question, we know
>>>>>>>>>> that P(P) is in this set. Therefore H(P, P) == 0 *cannot* be
>>>>>>>>>> verifiably correct.
>>>>>>>>>>
>>>>>>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>>>>>>
>>>>>>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00000d02](01)  55          push ebp
>>>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>>>> [00000d1c](01)  c3          ret
>>>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>>>
>>>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>>>      address   address   data      code        language
>>>>>>>>>      ========  ========  ========  =========   =============
>>>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  //
>>>>>>>>> call H
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  //
>>>>>>>>> call H
>>>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  //
>>>>>>>>> call H
>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> We can see that the above is a pure simulation of P on input P.
>>>>>>>>
>>>>>>>> It *isn't* a pure simulation since a pure simulation cannot
>>>>>>>> abort its input.
>>>>>>>>
>>>>>>>
>>>>>>> Yet another dishonest dodge. The above is a pure simulation, Only
>>>>>>> *AFTER* the above is there any aborting of the simulation.
>>>>>>
>>>>>> But what happens *after* this is exactly what is critical,
>>>>>
>>>>> No it is not. What can be seen while H is in pure simulator mode
>>>>> conclusively proves that unless some H aborts some P that neither H
>>>>> nor P will ever stop running.
>>>>
>>>> But whether *some* H aborts *some* P isn't the question H(P, P) is
>>>> supposed to answer.
>>>
>>>
>>> When we know that some H must abort some P we know for sure that this
>>> H did abort that P correctly. Until you are honest enough to agree to
>>> that I will not respond to you.
>>
>> Let's see if that reasoning works...
>>
>> Dr. Halstead knew that *some* baby needed to be aborted.
>> Therefore he was correct in aborting Mrs. Smith's baby.
>>
>> Something doesn't seem quite right with that...
>
> This seem to indicate that you have little interest in an honest dialogue.

Says the person who simply keeps repeating themselves ignoring all of
the arguments which have been offered to demonstrate that they are wrong.

Do you *really* not see that the above argument about Dr. Halstead is
logically the same as yours? Do you really not see that the conclusion
to the above is simply false and would most likely lead to a malpractice
suit if not criminal prosecution of the hypothetical Dr. Halstead?

> When we know (by logical necessity) that some H must abort some P we
> know for sure that this H did abort that P correctly.

There is absolutely no rule of logic which supports such a claim. Please
supply a recognized rule of logic which allows us to get from 'some X
needs Y' to 'this X needs Y'.

As I have pointed out numerous times, and you have consistently ignored:

When P(P) is run independently, the H contained inside the uppermost P
ultimately aborts its simulation, returning control to P which then halts.

When H(P, P) is run, there is absolutely no reason why the same thing
shouldn't happen if indeed your H really does perform a "pure
simulation" of P. It does not *need* to abort its input, because the
outermost simulated P has the ability to abort its own input and then
halt, returning control to the outermost H. For your H to claim that it
*needed* to abort P(P) because this input would not otherwise halt is
therefore simply *false*.

The fact that H(P, P) is giving the *wrong* answer should have been your
first clue.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 8/10/2021 5:08 PM, André G. Isaak wrote:
> On 2021-08-10 15:54, olcott wrote:
>> On 8/10/2021 4:36 PM, André G. Isaak wrote:
>>> On 2021-08-10 15:27, olcott wrote:
>>>> On 8/10/2021 3:33 PM, André G. Isaak wrote:
>>>>> On 2021-08-10 12:39, olcott wrote:
>>>>>> On 8/10/2021 12:36 PM, André G. Isaak wrote:
>>>>>>> On 2021-08-10 10:59, olcott wrote:
>>>>>>>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-08-10 09:07, olcott wrote:
>>>>>>>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-08-09 16:47, olcott wrote:
>>>>>>>>>
>>>>>>>>>>>> The P that halts seems to contradict that H(P,P)==0 is
>>>>>>>>>>>> correct yet it is verifiable that H(P,P)==0 is correct.
>>>>>>>>>>>
>>>>>>>>>>> P(P) is either in the set of halting computations or it is
>>>>>>>>>>> not. It can't be both.
>>>>>>>>>>>
>>>>>>>>>>> Since halting is a property defined *solely* in terms of the
>>>>>>>>>>> behaviour of the *actual* computation in question, we know
>>>>>>>>>>> that P(P) is in this set. Therefore H(P, P) == 0 *cannot* be
>>>>>>>>>>> verifiably correct.
>>>>>>>>>>>
>>>>>>>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>>>>>>>
>>>>>>>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [00000d02](01)  55          push ebp
>>>>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>>>>> [00000d1c](01)  c3          ret
>>>>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>>>>
>>>>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>>>>      address   address   data      code        language
>>>>>>>>>>      ========  ========  ========  =========   =============
>>>>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82
>>>>>>>>>> // call H
>>>>>>>>>>
>>>>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax
>>>>>>>>>> // push P
>>>>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx
>>>>>>>>>> // push P
>>>>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82
>>>>>>>>>> // call H
>>>>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax
>>>>>>>>>> // push P
>>>>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx
>>>>>>>>>> // push P
>>>>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82
>>>>>>>>>> // call H
>>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>>>>>> Stopped
>>>>>>>>>>
>>>>>>>>>> We can see that the above is a pure simulation of P on input P.
>>>>>>>>>
>>>>>>>>> It *isn't* a pure simulation since a pure simulation cannot
>>>>>>>>> abort its input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yet another dishonest dodge. The above is a pure simulation,
>>>>>>>> Only *AFTER* the above is there any aborting of the simulation.
>>>>>>>
>>>>>>> But what happens *after* this is exactly what is critical,
>>>>>>
>>>>>> No it is not. What can be seen while H is in pure simulator mode
>>>>>> conclusively proves that unless some H aborts some P that neither
>>>>>> H nor P will ever stop running.
>>>>>
>>>>> But whether *some* H aborts *some* P isn't the question H(P, P) is
>>>>> supposed to answer.
>>>>
>>>>
>>>> When we know that some H must abort some P we know for sure that
>>>> this H did abort that P correctly. Until you are honest enough to
>>>> agree to that I will not respond to you.
>>>
>>> Let's see if that reasoning works...
>>>
>>> Dr. Halstead knew that *some* baby needed to be aborted.
>>> Therefore he was correct in aborting Mrs. Smith's baby.
>>>
>>> Something doesn't seem quite right with that...
>>
>> This seem to indicate that you have little interest in an honest
>> dialogue.
>
> Says the person who simply keeps repeating themselves ignoring all of
> the arguments which have been offered to demonstrate that they are wrong.
>

_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]

....[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H

Begin Local Halt Decider Simulation at Machine Address:d02
....[00000d02][002118f1][002118f5] 55 push ebp
....[00000d03][002118f1][002118f5] 8bec mov ebp,esp
....[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
....[00000d08][002118ed][00000d02] 50 push eax // push P
....[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][002118e9][00000d02] 51 push ecx // push P
....[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
....[00000d02][0025c319][0025c31d] 55 push ebp
....[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
....[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
....[00000d08][0025c315][00000d02] 50 push eax // push P
....[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][0025c311][00000d02] 51 push ecx // push P
....[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

On 8/9/2021 5:25 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> It's unclear to me exactly how H is a "simulator", given this
>> execution trace. Normally a simulator creates a virtual machine with
>> a virtual address space and virtual instructions. The execution trace
>> of the simulator looks nothing like the execution trace of the
>> simulated code - basically the simulator does a big switch on the op
>> code of the virtual machine's instruction, then updates memory and
>> registers, with special rules for IO.
>
> He makes the same mistake about TMs as well. Because the classic
> construction of H^ from H used in proofs like Linz's makes H^ duplicate
> the input string (into a pair, if the that needs to be specially
> encoded) and then "behave like H", he thinks that if H is a UTM the
> resulting endless looping causes the input to be endlessly duplicated.
> He's even started to give these copies names: <H^[1]> and <H^[2]> etc.
>
> But this is because he's never studied, much less written, a UTM. The
> UTM has to use the tape to encode the sate and the tape of the TM being
> simulated, and that means the neat fiction of endless copies of the
> encoding of UTM^ (i.e. <UTM^>) does not occur. The execution is
> endless, but the strings on the tape are way more complex than he
> thinks. He reads Linz's notation in a sort of metaphorical way, whereas
> it is intended to show exactly what's on the tape.
>

It is the case that Ĥ on input ⟨Ĥ⟩ does specify infinite recursion to
every simulating halt decider embedded in Ĥ.

That you talk all around this using all kinds of rhetoric yet never use
any actual reasoning as a rebuttal would seem to prove that you are
dishonest.

> I've glossed over this as best I can because he loves people getting
> bogged down in the details whereas he's been clear that his plan is
> wrong for the simplest, high-level reasons.
>
>> You don't seem to be using this model for H.
>
> Indeed. I've thought for some time that he has not been able invoke the
> x86 emulator he's found inline as a nested instance. My guess is that
> his H just calls its argument function and the "detection" of the
> recursion (which is now, of course, a reality) occurs outside. He
> probably just thinks that it /could/ be brought into H without making
> any difference. Part of the evidence for this comes from his briefly
> talking about the "OS as the halt decider".
>
> The game would be up if he ever published H, hence the need to keep it
> secret.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 8/10/21 6:41 PM, olcott wrote:
> On 8/10/2021 5:08 PM, André G. Isaak wrote:
>> On 2021-08-10 15:54, olcott wrote:
>>> On 8/10/2021 4:36 PM, André G. Isaak wrote:
>>>> On 2021-08-10 15:27, olcott wrote:
>>>>> On 8/10/2021 3:33 PM, André G. Isaak wrote:
>>>>>> On 2021-08-10 12:39, olcott wrote:
>>>>>>> On 8/10/2021 12:36 PM, André G. Isaak wrote:
>>>>>>>> On 2021-08-10 10:59, olcott wrote:
>>>>>>>>> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>>>>>>>>> On 2021-08-10 09:07, olcott wrote:
>>>>>>>>>>> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-08-09 16:47, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>>>> The P that halts seems to contradict that H(P,P)==0 is
>>>>>>>>>>>>> correct yet it is verifiable that H(P,P)==0 is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> P(P) is either in the set of halting computations or it is
>>>>>>>>>>>> not. It can't be both.
>>>>>>>>>>>>
>>>>>>>>>>>> Since halting is a property defined *solely* in terms of the
>>>>>>>>>>>> behaviour of the *actual* computation in question, we know
>>>>>>>>>>>> that P(P) is in this set. Therefore H(P, P) == 0 *cannot* be
>>>>>>>>>>>> verifiably correct.
>>>>>>>>>>>>
>>>>>>>>>>>>> That you keep ignoring this means that you are dishonest.
>>>>>>>>>>>>
>>>>>>>>>>>> I am not ignoring this. I am asserting that it is false.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [00000d02](01)  55          push ebp
>>>>>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>>>>>> [00000d1c](01)  c3          ret
>>>>>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>>>>>
>>>>>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>>>>>      address   address   data      code        language
>>>>>>>>>>>      ========  ========  ========  =========   =============
>>>>>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82 
>>>>>>>>>>> // call H
>>>>>>>>>>>
>>>>>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax      
>>>>>>>>>>> // push P
>>>>>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx      
>>>>>>>>>>> // push P
>>>>>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82 
>>>>>>>>>>> // call H
>>>>>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax      
>>>>>>>>>>> // push P
>>>>>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx      
>>>>>>>>>>> // push P
>>>>>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82 
>>>>>>>>>>> // call H
>>>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>>>>>>> Stopped
>>>>>>>>>>>
>>>>>>>>>>> We can see that the above is a pure simulation of P on input P.
>>>>>>>>>>
>>>>>>>>>> It *isn't* a pure simulation since a pure simulation cannot
>>>>>>>>>> abort its input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yet another dishonest dodge. The above is a pure simulation,
>>>>>>>>> Only *AFTER* the above is there any aborting of the simulation.
>>>>>>>>
>>>>>>>> But what happens *after* this is exactly what is critical,
>>>>>>>
>>>>>>> No it is not. What can be seen while H is in pure simulator mode
>>>>>>> conclusively proves that unless some H aborts some P that neither
>>>>>>> H nor P will ever stop running.
>>>>>>
>>>>>> But whether *some* H aborts *some* P isn't the question H(P, P) is
>>>>>> supposed to answer.
>>>>>
>>>>>
>>>>> When we know that some H must abort some P we know for sure that
>>>>> this H did abort that P correctly. Until you are honest enough to
>>>>> agree to that I will not respond to you.
>>>>
>>>> Let's see if that reasoning works...
>>>>
>>>> Dr. Halstead knew that *some* baby needed to be aborted.
>>>> Therefore he was correct in aborting Mrs. Smith's baby.
>>>>
>>>> Something doesn't seem quite right with that...
>>>
>>> This seem to indicate that you have little interest in an honest
>>> dialogue.
>>
>> Says the person who simply keeps repeating themselves ignoring all of
>> the arguments which have been offered to demonstrate that they are wrong.
>>
>
> _P()
> [00000d02](01)  55          push ebp
> [00000d03](02)  8bec        mov ebp,esp
> [00000d05](03)  8b4508      mov eax,[ebp+08]
> [00000d08](01)  50          push eax       // push 2nd Param
> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
> [00000d0c](01)  51          push ecx       // push 1st Param
> [00000d0d](05)  e870feffff  call 00000b82  // call H
> [00000d12](03)  83c408      add esp,+08
> [00000d15](02)  85c0        test eax,eax
> [00000d17](02)  7402        jz 00000d1b
> [00000d19](02)  ebfe        jmp 00000d19
> [00000d1b](01)  5d          pop ebp
> [00000d1c](01)  c3          ret
> Size in bytes:(0027) [00000d1c]
>
> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>
> Begin Local Halt Decider Simulation at Machine Address:d02
> ...[00000d02][002118f1][002118f5] 55          push ebp
> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
> ...[00000d02][0025c319][0025c31d] 55          push ebp
> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> You have never once shown how the above does not conclusively prove that
> while H acts as a pure simulator on its input (P,P) can possibly halt
> because you know that I am correct. I will not tolerate a dishonest
> dialogue that never reaches closure on any points.

On 8/10/21 7:08 PM, olcott wrote:
> On 8/9/2021 5:25 PM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> It's unclear to me exactly how H is a "simulator", given this
>>> execution trace.  Normally a simulator creates a virtual machine with
>>> a virtual address space and virtual instructions. The execution trace
>>> of the simulator looks nothing like the execution trace of the
>>> simulated code - basically the simulator does a big switch on the op
>>> code of the virtual machine's instruction, then updates memory and
>>> registers, with special rules for IO.
>>
>> He makes the same mistake about TMs as well.  Because the classic
>> construction of H^ from H used in proofs like Linz's makes H^ duplicate
>> the input string (into a pair, if the that needs to be specially
>> encoded) and then "behave like H", he thinks that if H is a UTM the
>> resulting endless looping causes the input to be endlessly duplicated.
>> He's even started to give these copies names: <H^[1]> and <H^[2]> etc.
>>
>> But this is because he's never studied, much less written, a UTM.  The
>> UTM has to use the tape to encode the sate and the tape of the TM being
>> simulated, and that means the neat fiction of endless copies of the
>> encoding of UTM^ (i.e. <UTM^>) does not occur.  The execution is
>> endless, but the strings on the tape are way more complex than he
>> thinks.  He reads Linz's notation in a sort of metaphorical way, whereas
>> it is intended to show exactly what's on the tape.
>>
>
> It is the case that Ĥ on input ⟨Ĥ⟩ does specify infinite recursion to
> every simulating halt decider embedded in Ĥ.

Wrong.

If H does answer non-halting for the question H(H^,H^) then as YOU have
shown H^(H^) is halting and thus is wrong.

Only if H does NOT abort its simulation will H^ have actual infinite
recursive like behavior, and that H will not answer and thus is also wrong.

>
> That you talk all around this using all kinds of rhetoric yet never use
> any actual reasoning as a rebuttal would seem to prove that you are
> dishonest.

See your self in the mirror? You have YET to use any actual reasoning as
a rebuttal to errors pointed out in your 'logic' (to use the word lightely)

>
>
>> I've glossed over this as best I can because he loves people getting
>> bogged down in the details whereas he's been clear that his plan is
>> wrong for the simplest, high-level reasons.
>>
>>> You don't seem to be using this model for H.
>>
>> Indeed.  I've thought for some time that he has not been able invoke the
>> x86 emulator he's found inline as a nested instance.  My guess is that
>> his H just calls its argument function and the "detection" of the
>> recursion (which is now, of course, a reality) occurs outside.  He
>> probably just thinks that it /could/ be brought into H without making
>> any difference.  Part of the evidence for this comes from his briefly
>> talking about the "OS as the halt decider".
>>
>> The game would be up if he ever published H, hence the need to keep it
>> secret.
>>
>
>

On 8/10/21 11:07 AM, olcott wrote:
> On 8/9/2021 8:47 PM, André G. Isaak wrote:
>> On 2021-08-09 16:47, olcott wrote:
>>> On 8/9/2021 5:43 PM, André G. Isaak wrote:
>>>> On 2021-08-09 16:21, olcott wrote:
>>>>> On 8/9/2021 5:17 PM, André G. Isaak wrote:
>>>>>> On 2021-08-09 15:12, olcott wrote:
>>>>>>> On 8/9/2021 2:38 PM, André G. Isaak wrote:
>>>>>>>> On 2021-08-09 10:57, olcott wrote:
>>>>>>>>> On 8/8/2021 1:50 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-08-06 22:23, olcott wrote:
>>>>>>>>>>> On 8/6/2021 10:55 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-08-06 09:59, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>>> Yes, but bear in mind that 'halting' refers to Turing
>>>>>>>>>>>> Machines operating on a specific input. It does not refer to
>>>>>>>>>>>> simulations or what happens inside a halting decider. It
>>>>>>>>>>>> refers *only* to actual computations, i.e. an actual Turing
>>>>>>>>>>>> Machine operating on an actual input string.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So yet again you prove that you are totally clueless that
>>>>>>>>>>> pure simulations are computationally equivalent to direct
>>>>>>>>>>> executions ?
>>>>>>>>>>
>>>>>>>>>> Your H is not a pure simulator
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>    if (H(x, x))
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00000d02](01)  55          push ebp
>>>>>>>>> [00000d03](02)  8bec        mov ebp,esp
>>>>>>>>> [00000d05](03)  8b4508      mov eax,[ebp+08]
>>>>>>>>> [00000d08](01)  50          push eax       // push 2nd Param
>>>>>>>>> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
>>>>>>>>> [00000d0c](01)  51          push ecx       // push 1st Param
>>>>>>>>> [00000d0d](05)  e870feffff  call 00000b82  // call H
>>>>>>>>> [00000d12](03)  83c408      add esp,+08
>>>>>>>>> [00000d15](02)  85c0        test eax,eax
>>>>>>>>> [00000d17](02)  7402        jz 00000d1b
>>>>>>>>> [00000d19](02)  ebfe        jmp 00000d19
>>>>>>>>> [00000d1b](01)  5d          pop ebp
>>>>>>>>> [00000d1c](01)  c3          ret
>>>>>>>>> Size in bytes:(0027) [00000d1c]
>>>>>>>>>
>>>>>>>>>      machine   stack     stack     machine     assembly
>>>>>>>>>      address   address   data      code        language
>>>>>>>>>      ========  ========  ========  =========   =============
>>>>>>>>> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  //
>>>>>>>>> call H
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation at Machine Address:d02
>>>>>>>>> ...[00000d02][002118f1][002118f5] 55          push ebp
>>>>>>>>> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
>>>>>>>>> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
>>>>>>>>> ...[00000d08][002118ed][00000d02] 50          push eax       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>> ...[00000d0c][002118e9][00000d02] 51          push ecx       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  //
>>>>>>>>> call H
>>>>>>>>> ...[00000d02][0025c319][0025c31d] 55          push ebp
>>>>>>>>> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
>>>>>>>>> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
>>>>>>>>> ...[00000d08][0025c315][00000d02] 50          push eax       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
>>>>>>>>> ...[00000d0c][0025c311][00000d02] 51          push ecx       //
>>>>>>>>> push P
>>>>>>>>> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  //
>>>>>>>>> call H
>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> The fact that the execution trace of the simulation of P(P) on
>>>>>>>>> page 6 perfectly matches its source-code on page 5 conclusively
>>>>>>>>> proves that this execution trace performed by H is a pure
>>>>>>>>> simulation of P(P). There is no correct basis for disagreement,
>>>>>>>>> therefore anyone disagreeing either does not know the x86
>>>>>>>>> language or they are simply lying.
>>>>>>>>
>>>>>>>> You have a *partial trace* and *partial source code*. Neither
>>>>>>>> shows what happens at B82.
>>>>>>>>
>>>>>>>
>>>>>>> if int add(int x, int y) returns 5 on add(2,3) we know for sure
>>>>>>> that add was correct on that input.
>>>>>>
>>>>>> That is a poor analogy since 5 actually *is* the correct answer to
>>>>>> 2+3.
>>>>>>
>>>>>> We know that P(P) *does* halt, which means that if H(P, P) returns
>>>>>> false we know for sure that H was *incorrect* on that input.
>>>>>
>>>>> P(P) only halts because H(P,P) correctly decides that its input
>>>>> never halts and aborts this input on that basis.
>>>>
>>>> X only halts because Y IMPLIES that X halts. That's basic logic.
>>>>
>>>> The definition of halting does not refer at all to the *reason* why
>>>> a particular computation halts.
>>>>
>>>
>>> The P that halts seems to contradict that H(P,P)==0 is correct yet it
>>> is verifiable that H(P,P)==0 is correct.
>>
>> P(P) is either in the set of halting computations or it is not. It
>> can't be both.
>>
>> Since halting is a property defined *solely* in terms of the behaviour
>> of the *actual* computation in question, we know that P(P) is in this
>> set. Therefore H(P, P) == 0 *cannot* be verifiably correct.
>>
>>> That you keep ignoring this means that you are dishonest.
>>
>> I am not ignoring this. I am asserting that it is false.
>>
>
>
>
> _P()
> [00000d02](01)  55          push ebp
> [00000d03](02)  8bec        mov ebp,esp
> [00000d05](03)  8b4508      mov eax,[ebp+08]
> [00000d08](01)  50          push eax       // push 2nd Param
> [00000d09](03)  8b4d08      mov ecx,[ebp+08]
> [00000d0c](01)  51          push ecx       // push 1st Param
> [00000d0d](05)  e870feffff  call 00000b82  // call H
> [00000d12](03)  83c408      add esp,+08
> [00000d15](02)  85c0        test eax,eax
> [00000d17](02)  7402        jz 00000d1b
> [00000d19](02)  ebfe        jmp 00000d19
> [00000d1b](01)  5d          pop ebp
> [00000d1c](01)  c3          ret
> Size in bytes:(0027) [00000d1c]
>
>     machine   stack     stack     machine     assembly
>     address   address   data      code        language
>     ========  ========  ========  =========   =============
> ...[00000d0d][00101829][00000d12] e870feffff  call 00000b82  // call H
>
> Begin Local Halt Decider Simulation at Machine Address:d02
> ...[00000d02][002118f1][002118f5] 55          push ebp
> ...[00000d03][002118f1][002118f5] 8bec        mov ebp,esp
> ...[00000d05][002118f1][002118f5] 8b4508      mov eax,[ebp+08]
> ...[00000d08][002118ed][00000d02] 50          push eax       // push P
> ...[00000d09][002118ed][00000d02] 8b4d08      mov ecx,[ebp+08]
> ...[00000d0c][002118e9][00000d02] 51          push ecx       // push P
> ...[00000d0d][002118e5][00000d12] e870feffff  call 00000b82  // call H
> ...[00000d02][0025c319][0025c31d] 55          push ebp
> ...[00000d03][0025c319][0025c31d] 8bec        mov ebp,esp
> ...[00000d05][0025c319][0025c31d] 8b4508      mov eax,[ebp+08]
> ...[00000d08][0025c315][00000d02] 50          push eax       // push P
> ...[00000d09][0025c315][00000d02] 8b4d08      mov ecx,[ebp+08]
> ...[00000d0c][0025c311][00000d02] 51          push ecx       // push P
> ...[00000d0d][0025c30d][00000d12] e870feffff  call 00000b82  // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> We can see that the above is a pure simulation of P on input P.

On 8/10/21 12:59 PM, olcott wrote:
> On 8/10/2021 10:28 AM, André G. Isaak wrote:
>>
>> It *isn't* a pure simulation since a pure simulation cannot abort its
>> input.
>>
>
> Yet another dishonest dodge. The above is a pure simulation, Only
> *AFTER* the above is there any aborting of the simulation.

Since there *IS* an 'after' it wasn't a PURE simulation.

Remember, the DEFINITION of PURE for simulation is doing EXACTLY what
the original machine would do, INCLUDING running forever if that is what
the machine does. You can't 'run forever' and abort at the same time.

Ergo, H is NOT a PURE simulator.

Maybe you should play Russian Roulette and decide to not pull the
trigger, and then pull it. Since you first decided not to do it you will
be safe, right?

On Wednesday, 11 August 2021 at 00:08:50 UTC+1, olcott wrote:
> On 8/9/2021 5:25 PM, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >
> >> It's unclear to me exactly how H is a "simulator", given this
> >> execution trace. Normally a simulator creates a virtual machine with
> >> a virtual address space and virtual instructions. The execution trace
> >> of the simulator looks nothing like the execution trace of the
> >> simulated code - basically the simulator does a big switch on the op
> >> code of the virtual machine's instruction, then updates memory and
> >> registers, with special rules for IO.
> >
> > He makes the same mistake about TMs as well. Because the classic
> > construction of H^ from H used in proofs like Linz's makes H^ duplicate
> > the input string (into a pair, if the that needs to be specially
> > encoded) and then "behave like H", he thinks that if H is a UTM the
> > resulting endless looping causes the input to be endlessly duplicated.
> > He's even started to give these copies names: <H^[1]> and <H^[2]> etc.
> >
> > But this is because he's never studied, much less written, a UTM. The
> > UTM has to use the tape to encode the sate and the tape of the TM being
> > simulated, and that means the neat fiction of endless copies of the
> > encoding of UTM^ (i.e. <UTM^>) does not occur. The execution is
> > endless, but the strings on the tape are way more complex than he
> > thinks. He reads Linz's notation in a sort of metaphorical way, whereas
> > it is intended to show exactly what's on the tape.
> >
> It is the case that Ĥ on input ⟨Ĥ⟩ does specify infinite recursion to
> every simulating halt decider embedded in Ĥ.
>
> That you talk all around this using all kinds of rhetoric yet never use
> any actual reasoning as a rebuttal would seem to prove that you are
> dishonest.
>
You need to be clear about what you mean by "infinite recursion". We
all get the basic idea - H is a simulating halt decider, therefore H_Hat gets
executed multiple times under various levels of H,.

But you are not working with Turing machines. Turing machines don't really
have "recursion" because it is a structured programming concept, and Turing
machines are too low-level for structured programming.
In C, you can call subroutines recursively, but then how is H a "simulating halt
decider"?. Or you can create a simulation context, and another simulation
context within the simulation context, and so on, indefinitely. This is not
what you appear to be doing.

On Tuesday, 10 August 2021 at 23:08:27 UTC+1, André G. Isaak wrote:
>
> Do you *really* not see that the above argument about Dr. Halstead is
> logically the same as yours? Do you really not see that the conclusion
> to the above is simply false and would most likely lead to a malpractice
> suit if not criminal prosecution of the hypothetical Dr. Halstead?
>
Though "an unborn baby has no moral value" is a defensible philosophical
position.
"Mrs Jone's baby is of no moral value but Mrs Smith's is" is satanic.

On 8/11/2021 1:51 AM, Malcolm McLean wrote:
> On Wednesday, 11 August 2021 at 00:08:50 UTC+1, olcott wrote:
>> On 8/9/2021 5:25 PM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> It's unclear to me exactly how H is a "simulator", given this
>>>> execution trace. Normally a simulator creates a virtual machine with
>>>> a virtual address space and virtual instructions. The execution trace
>>>> of the simulator looks nothing like the execution trace of the
>>>> simulated code - basically the simulator does a big switch on the op
>>>> code of the virtual machine's instruction, then updates memory and
>>>> registers, with special rules for IO.
>>>
>>> He makes the same mistake about TMs as well. Because the classic
>>> construction of H^ from H used in proofs like Linz's makes H^ duplicate
>>> the input string (into a pair, if the that needs to be specially
>>> encoded) and then "behave like H", he thinks that if H is a UTM the
>>> resulting endless looping causes the input to be endlessly duplicated.
>>> He's even started to give these copies names: <H^[1]> and <H^[2]> etc.
>>>
>>> But this is because he's never studied, much less written, a UTM. The
>>> UTM has to use the tape to encode the sate and the tape of the TM being
>>> simulated, and that means the neat fiction of endless copies of the
>>> encoding of UTM^ (i.e. <UTM^>) does not occur. The execution is
>>> endless, but the strings on the tape are way more complex than he
>>> thinks. He reads Linz's notation in a sort of metaphorical way, whereas
>>> it is intended to show exactly what's on the tape.
>>>
>> It is the case that Ĥ on input ⟨Ĥ⟩ does specify infinite recursion to
>> every simulating halt decider embedded in Ĥ.
>>
>> That you talk all around this using all kinds of rhetoric yet never use
>> any actual reasoning as a rebuttal would seem to prove that you are
>> dishonest.
>>
> You need to be clear about what you mean by "infinite recursion". We
> all get the basic idea - H is a simulating halt decider, therefore H_Hat gets
> executed multiple times under various levels of H,.

_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]

The fact that while H acts as a pure simulator as shown below that P
would continue to call H with itself as input forever.

Begin Local Halt Decider Simulation at Machine Address:d02
....[00000d02][002118f1][002118f5] 55 push ebp
....[00000d03][002118f1][002118f5] 8bec mov ebp,esp
....[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
....[00000d08][002118ed][00000d02] 50 push eax // push P
....[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][002118e9][00000d02] 51 push ecx // push P
....[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
....[00000d02][0025c319][0025c31d] 55 push ebp
....[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
....[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
....[00000d08][0025c315][00000d02] 50 push eax // push P
....[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][0025c311][00000d02] 51 push ecx // push P
....[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

> But you are not working with Turing machines. Turing machines don't really
> have "recursion" because it is a structured programming concept, and Turing
> machines are too low-level for structured programming.

When the state transition sequence has an infinite cycle as shown in
figure 12.4 of page 17 we have infinitely nested simulation.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> In C, you can call subroutines recursively, but then how is H a "simulating halt
> decider"?. Or you can create a simulation context, and another simulation
> context within the simulation context, and so on, indefinitely. This is not
> what you appear to be doing.
>
I will not say one way or the other because it has already taken very
many months to get people to begin to understand the gist of 7 lines of
x86 code. Getting into the other details would be impossibly difficult
for people that can't seem to understand 7 lines of x86 code after many
months of discussion.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein