Within the definition of the x86 language H(P,P)==0 is a necessary
consequence for every simulating halt decider H.

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

As Flibble pointed out the first time that the simulated P calls H(P,P)
would seem to indicate infinite recursion because the currently running
H is being called again with identical parameters.

Flibble's comment caused me to accept the truth these words that I had
previously written: (Before his comment I was not quite sure)

Because H knows that it is a simulating halt decider it can
know that the first time that its input calls itself with
the same parameters this would be infinitely nested simulation.

[Olcott wrong about infinite recursion] comp.theory
On 11/10/2021 3:53 PM, Mr Flibble wrote:
> Olcott is barking up the wrong tree re infinite recursion: there
> is only a need to detect a single recursive call into the halt decider
> and signal an exception. Why? Because infinite recursion is valid
> program behavior.
>
> /Flibble

This halt deciding criteria can also be equally applied when P is
invoking H with a copy of its input. The only difference is that
string_compare is invoked instead of integer compare.

Because the call is aborted before the next level simulation is
initiated there is no need for static local data, thus this H is a pure
function. https://en.wikipedia.org/wiki/Pure_function

H uses the NumParams system to provide the number of parameters required
by any function of the COFF object file. H finds that the NumParams("H")
is 2. H then compares the top two elements pf P's stack its own
parameters. If it has a match then its [abort and decide not halting]
criteria have been met.

There is no need to maintain any static data across nested simulations
because no nested simulation are ever created.

--
Copyright 2021 Pete Olcott

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

On 11/10/21 8:25 PM, olcott wrote:
> Within the definition of the x86 language H(P,P)==0 is a necessary
> consequence for every simulating halt decider H.

Nope, and you simulation doesn't follow the definition of x86 assembly
language,

FAIL.

>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c56][0010172a][00000000] 55          push ebp
> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> As Flibble pointed out the first time that the simulated P calls H(P,P)
> would seem to indicate infinite recursion because the currently running
> H is being called again with identical parameters.
>
> Flibble's comment caused me to accept the truth  these words that I had
> previously written: (Before his comment I was not quite sure)
>
>    Because H knows that it is a simulating halt decider it can
>    know that the first time that its input calls itself with
>    the same parameters this would be infinitely nested simulation.
>

Except that is a false statment.

We have a similar statement that I presume we should also be able to use:

Since we know that H(P,P) returns 0, we therefore know that as soon as P
calls H(P.P) that this call will return 0, as we can see that P(P) will
halt.

> [Olcott wrong about infinite recursion] comp.theory
> On 11/10/2021 3:53 PM, Mr Flibble wrote:
> > Olcott is barking up the wrong tree re infinite recursion: there
> > is only a need to detect a single recursive call into the halt decider
> > and signal an exception.  Why?  Because infinite recursion is valid
> > program behavior.
> >
> > /Flibble
>
> This halt deciding criteria can also be equally applied when P is
> invoking H with a copy of its input. The only difference is that
> string_compare is invoked instead of integer compare.
>
> Because the call is aborted before the next level simulation is
> initiated there is no need for static local data, thus this H is a pure
> function. https://en.wikipedia.org/wiki/Pure_function
>
> H uses the NumParams system to provide the number of parameters required
> by any function of the COFF object file. H finds that the NumParams("H")
> is 2. H then compares the top two elements pf P's stack its own
> parameters. If it has a match then its [abort and decide not halting]
> criteria have been met.
>
> There is no need to maintain any static data across nested simulations
> because no nested simulation are ever created.
>

You still haven't shown how since H is only given the COFF object file
of P as its input it gets hold of the source code.

On 11/11/2021 8:01 AM, Richard Damon wrote:
> On 11/10/21 8:25 PM, olcott wrote:
>> Within the definition of the x86 language H(P,P)==0 is a necessary
>> consequence for every simulating halt decider H.
>
> Nope, and you simulation doesn't follow the definition of x86 assembly
> language,
>
> FAIL.
>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> // Strachey(1965) CPL translated to C
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00000c36](01)  55          push ebp
>> [00000c37](02)  8bec        mov ebp,esp
>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>> [00000c3c](01)  50          push eax
>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>> [00000c40](01)  51          push ecx
>> [00000c41](05)  e820fdffff  call 00000966    // call H
>> [00000c46](03)  83c408      add esp,+08
>> [00000c49](02)  85c0        test eax,eax
>> [00000c4b](02)  7402        jz 00000c4f
>> [00000c4d](02)  ebfe        jmp 00000c4d
>> [00000c4f](01)  5d          pop ebp
>> [00000c50](01)  c3          ret
>> Size in bytes:(0027) [00000c50]
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [00000c56][0010172a][00000000] 55          push ebp
>> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
>> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
>> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
>> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>>
>> Begin Local Halt Decider Simulation at Machine Address:c36
>> [00000c36][002117ca][002117ce] 55          push ebp
>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>
>> As Flibble pointed out the first time that the simulated P calls
>> H(P,P) would seem to indicate infinite recursion because the currently
>> running H is being called again with identical parameters.
>>
>> Flibble's comment caused me to accept the truth  these words that I
>> had previously written: (Before his comment I was not quite sure)
>>
>>     Because H knows that it is a simulating halt decider it can
>>     know that the first time that its input calls itself with
>>     the same parameters this would be infinitely nested simulation.
>>
>
> Except that is a false statment.
>

Actually H only need see that its simulated input is calling itself with
the same parameters that it was called with to realize that this call is
infinitely recursive.

> We have a similar statement that I presume we should also be able to use:
>
> Since we know that H(P,P) returns 0, we therefore know that as soon as P
> calls H(P.P) that this call will return 0, as we can see that P(P) will
> halt.
>
>> [Olcott wrong about infinite recursion] comp.theory
>> On 11/10/2021 3:53 PM, Mr Flibble wrote:
>>  > Olcott is barking up the wrong tree re infinite recursion: there
>>  > is only a need to detect a single recursive call into the halt decider
>>  > and signal an exception.  Why?  Because infinite recursion is valid
>>  > program behavior.
>>  >
>>  > /Flibble
>>
>> This halt deciding criteria can also be equally applied when P is
>> invoking H with a copy of its input. The only difference is that
>> string_compare is invoked instead of integer compare.
>>
>> Because the call is aborted before the next level simulation is
>> initiated there is no need for static local data, thus this H is a
>> pure function. https://en.wikipedia.org/wiki/Pure_function
>>
>> H uses the NumParams system to provide the number of parameters
>> required by any function of the COFF object file. H finds that the
>> NumParams("H") is 2. H then compares the top two elements pf P's stack
>> its own parameters. If it has a match then its [abort and decide not
>> halting] criteria have been met.
>>
>> There is no need to maintain any static data across nested simulations
>> because no nested simulation are ever created.
>>
>
> You still haven't shown how since H is only given the COFF object file
> of P as its input it gets hold of the source code.
>
>
>
>

--
Copyright 2021 Pete Olcott

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

On 11/11/21 9:10 AM, olcott wrote:
> On 11/11/2021 8:01 AM, Richard Damon wrote:
>> On 11/10/21 8:25 PM, olcott wrote:
>>> Within the definition of the x86 language H(P,P)==0 is a necessary
>>> consequence for every simulating halt decider H.
>>
>> Nope, and you simulation doesn't follow the definition of x86 assembly
>> language,
>>
>> FAIL.
>>
>>>
>>> // Simplified Linz Ĥ (Linz:1990:319)
>>> // Strachey(1965) CPL translated to C
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00000c36](01)  55          push ebp
>>> [00000c37](02)  8bec        mov ebp,esp
>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>> [00000c3c](01)  50          push eax
>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>> [00000c40](01)  51          push ecx
>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>> [00000c46](03)  83c408      add esp,+08
>>> [00000c49](02)  85c0        test eax,eax
>>> [00000c4b](02)  7402        jz 00000c4f
>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>> [00000c4f](01)  5d          pop ebp
>>> [00000c50](01)  c3          ret
>>> Size in bytes:(0027) [00000c50]
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [00000c56][0010172a][00000000] 55          push ebp
>>> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
>>> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
>>> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
>>> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>>>
>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>> [00000c36][002117ca][002117ce] 55          push ebp
>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>>
>>> As Flibble pointed out the first time that the simulated P calls
>>> H(P,P) would seem to indicate infinite recursion because the
>>> currently running H is being called again with identical parameters.
>>>
>>> Flibble's comment caused me to accept the truth  these words that I
>>> had previously written: (Before his comment I was not quite sure)
>>>
>>>     Because H knows that it is a simulating halt decider it can
>>>     know that the first time that its input calls itself with
>>>     the same parameters this would be infinitely nested simulation.
>>>
>>
>> Except that is a false statment.
>>
>
> Actually H only need see that its simulated input is calling itself with
> the same parameters that it was called with to realize that this call is
> infinitely recursive.

No, that is a FALSE statement.

If H IS a proper halt decider, then we KNOW that a call to it will
always be finite, and thus CAN'T be infinitely recurcive.

PERIOD.

Your logic is based on an inconsistent assumption/definition of the
operation of H.

Please claify what is the behavior of H(P,P):

1) Does H(P,P) return the value 0 in finite time, or

2) Does H(P,P) simulate P(P) which calls H(P,P) which simulate P(P) and
so on in infinite recursion and thus never return,

It can't do both, at least not and be a Computation, which is a
requirement to be a Halt Deciddr.

Failure to give a straight answer will be considered an admission that
you argument is incorrect.

On 11/11/2021 8:56 AM, Richard Damon wrote:
> On 11/11/21 9:10 AM, olcott wrote:
>> On 11/11/2021 8:01 AM, Richard Damon wrote:
>>> On 11/10/21 8:25 PM, olcott wrote:
>>>> Within the definition of the x86 language H(P,P)==0 is a necessary
>>>> consequence for every simulating halt decider H.
>>>
>>> Nope, and you simulation doesn't follow the definition of x86
>>> assembly language,
>>>
>>> FAIL.
>>>
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> // Strachey(1965) CPL translated to C
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00000c36](01)  55          push ebp
>>>> [00000c37](02)  8bec        mov ebp,esp
>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>> [00000c3c](01)  50          push eax
>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>> [00000c40](01)  51          push ecx
>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>> [00000c46](03)  83c408      add esp,+08
>>>> [00000c49](02)  85c0        test eax,eax
>>>> [00000c4b](02)  7402        jz 00000c4f
>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>> [00000c4f](01)  5d          pop ebp
>>>> [00000c50](01)  c3          ret
>>>> Size in bytes:(0027) [00000c50]
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [00000c56][0010172a][00000000] 55          push ebp
>>>> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
>>>> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
>>>> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
>>>> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>>
>>>> As Flibble pointed out the first time that the simulated P calls
>>>> H(P,P) would seem to indicate infinite recursion because the
>>>> currently running H is being called again with identical parameters.
>>>>
>>>> Flibble's comment caused me to accept the truth  these words that I
>>>> had previously written: (Before his comment I was not quite sure)
>>>>
>>>>     Because H knows that it is a simulating halt decider it can
>>>>     know that the first time that its input calls itself with
>>>>     the same parameters this would be infinitely nested simulation.
>>>>
>>>
>>> Except that is a false statment.
>>>
>>
>> Actually H only need see that its simulated input is calling itself
>> with the same parameters that it was called with to realize that this
>> call is infinitely recursive.
>
> No, that is a FALSE statement.
>
> If H IS a proper halt decider, then we KNOW that a call to it will
> always be finite, and thus CAN'T be infinitely recurcive.
>

Every time the input P never reaches its final state the input P never
halts even if it stops running.

When H(P,P) aborts the simulation of P, P never halts.
When H(P,P) does not abort the simulation of P, P never halts and H
never returns.

P never halts under every possible case thus H(P,P)==0 under every
possible case.

Of these two cases where P never halts if H never halts then H is not a
halt decider.

Of the other case where H returns 0 H has correctly decided that its
input never halts.

> PERIOD.
>
> Your logic is based on an inconsistent assumption/definition of the
> operation of H.
>
> Please claify what is the behavior of H(P,P):
>
> 1) Does H(P,P) return the value 0 in finite time, or
>
> 2) Does H(P,P) simulate P(P) which calls H(P,P) which simulate P(P) and
> so on in infinite recursion and thus never return,
>
> It can't do both, at least not and be a Computation, which is a
> requirement to be a Halt Deciddr.
>
>
> Failure to give a straight answer will be considered an admission that
> you argument is incorrect.

--
Copyright 2021 Pete Olcott

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

On 11/11/21 10:05 AM, olcott wrote:
> On 11/11/2021 8:56 AM, Richard Damon wrote:
>> On 11/11/21 9:10 AM, olcott wrote:
>>> On 11/11/2021 8:01 AM, Richard Damon wrote:
>>>> On 11/10/21 8:25 PM, olcott wrote:
>>>>> Within the definition of the x86 language H(P,P)==0 is a necessary
>>>>> consequence for every simulating halt decider H.
>>>>
>>>> Nope, and you simulation doesn't follow the definition of x86
>>>> assembly language,
>>>>
>>>> FAIL.
>>>>
>>>>>
>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>> // Strachey(1965) CPL translated to C
>>>>> void P(u32 x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00000c36](01)  55          push ebp
>>>>> [00000c37](02)  8bec        mov ebp,esp
>>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>>> [00000c3c](01)  50          push eax
>>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>>> [00000c40](01)  51          push ecx
>>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>>> [00000c46](03)  83c408      add esp,+08
>>>>> [00000c49](02)  85c0        test eax,eax
>>>>> [00000c4b](02)  7402        jz 00000c4f
>>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>>> [00000c4f](01)  5d          pop ebp
>>>>> [00000c50](01)  c3          ret
>>>>> Size in bytes:(0027) [00000c50]
>>>>>
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [00000c56][0010172a][00000000] 55          push ebp
>>>>> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
>>>>> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
>>>>> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
>>>>> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call
>>>>> H(P,P)
>>>>>
>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>>> H(P,P)
>>>>>
>>>>> As Flibble pointed out the first time that the simulated P calls
>>>>> H(P,P) would seem to indicate infinite recursion because the
>>>>> currently running H is being called again with identical parameters.
>>>>>
>>>>> Flibble's comment caused me to accept the truth  these words that I
>>>>> had previously written: (Before his comment I was not quite sure)
>>>>>
>>>>>     Because H knows that it is a simulating halt decider it can
>>>>>     know that the first time that its input calls itself with
>>>>>     the same parameters this would be infinitely nested simulation.
>>>>>
>>>>
>>>> Except that is a false statment.
>>>>
>>>
>>> Actually H only need see that its simulated input is calling itself
>>> with the same parameters that it was called with to realize that this
>>> call is infinitely recursive.
>>
>> No, that is a FALSE statement.
>>
>> If H IS a proper halt decider, then we KNOW that a call to it will
>> always be finite, and thus CAN'T be infinitely recurcive.
>>
>
> Every time the input P never reaches its final state the input P never
> halts even if it stops running.

Not-Halted-Yet is NOT non-halting.

Your 'Never Halts' is not the same as Non-Halting.

You have the wrong definitions of the words.

In Computation Theory, Non-Halting is a technical term, it means that
the computation will NEVER HALT IF ALLOWED TO RUN FOREVER.

You are just talking POOP.

>
> When H(P,P) aborts the simulation of P, P never halts.

WRONG Meaning for never halts.

POOP.

> When H(P,P) does not abort the simulation of P, P never halts and H
> never returns.

Yes, If H is Hn that never aborts its simulatioon, the Pn, the one
derived from Hn will not halt when we try to compute Pn(Pn) but
unfortunately for your Hn(Pn,Pn) never gives an answer.

Yes, H(Pn,Pn) == 0 would be the right answer, but Hn never gives it.
>
> P never halts under every possible case thus H(P,P)==0 under every
> possible case.

WRONG.

If H is Ha which DOES abort its simulation and returns 0 (Non-Halting)
the the Pa built from that is Halting when computing Pa(Pa).

You have agreed to that Pa(Pa) when run as an independent machine will halt.

Since the DEFINITION of the Halting Problem is asking H what the
computation the input represents will do, and that is agreed to halts,
the right answer that H needs to give for looking at Pa(Pa) is Halting.

You are confusin your dog with your neighbors cat and think that you
have a cat that barks.

Ha needs to answer for Pa, and it needs to analyse that Pa as Pa and the
H inside it as Ha, not see it as Pn and the H inside it as Hn.

You make that mistake and get things wrong.

As I have said elsewhere, you are just proving how bad this logic system
you are claiming people need to use actually is.

>
> Of these two cases where P never halts if H never halts then H is not a
> halt decider.
>
> Of the other case where H returns 0 H has correctly decided that its
> input never halts.

Nope. Yes Ha(Pn,Pn) is correct in deciding non-halting, but that isn't
the case it need to get right to refute Linz.

Since we KNOW that Pa(Pa) is halting, the right answer for H(Pa,Pa) is 1
(Halting) but Ha(Pa,Pa) says 0, which is wrong.

I think you arguments are just showing how BAD the logic system you are
trying to propose needs to be use work.

>
>> PERIOD.
>>
>> Your logic is based on an inconsistent assumption/definition of the
>> operation of H.
>>
>> Please claify what is the behavior of H(P,P):
>>
>> 1) Does H(P,P) return the value 0 in finite time, or
>>
>> 2) Does H(P,P) simulate P(P) which calls H(P,P) which simulate P(P)
>> and so on in infinite recursion and thus never return,
>>
>> It can't do both, at least not and be a Computation, which is a
>> requirement to be a Halt Deciddr.
>>
>>
>> Failure to give a straight answer will be considered an admission that
>> you argument is incorrect.
>
>

Note, you still haven't defined which behavior of H you are talking about.