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

This is the assembly language of the above function after it has been
translated by the Microsoft C compiler.

_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]

Begin Local Halt Decider Simulation at Machine Address:c36

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[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)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)

The above conclusively proves that the pure simulation of the input to
H(P,P) never reaches its final state.

We don't even have to see that the first seven x86 instructions of P
actually repeat. We can know by logical necessity that a pure simulation
of the input to H(P,P) by H never reaches any final state of P on the
basis of the x86 source code of P and the fact that the seventh
instruction of P calls H.

This conclusively proves that H(P,P)==0 is the correct return value for
its input even if H never returns.

If there is no simulating halt decider H in the universe that correctly
decides that its input (P,P) never reaches its final state then the
input (P,P) remains undecidable, none-the-less H(P,P)==0 is still correct.

Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (318-320)

Halting problem undecidability and infinitely nested simulation
May 2021 PL Olcott

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

--
Copyright 2021 Pete Olcott

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

On 11/6/21 1:30 PM, olcott wrote:
> // Simplified Linz Ĥ (Linz:1990:319)
>  // Strachey(1965) CPL translated to C
>  void P(u32 x)
>  {
>   if (H(x, x))
>     HERE: goto HERE;
>  }
>
> This is the assembly language of the above function after it has been
> translated by the Microsoft C compiler.
>
> _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]
>
> Begin Local Halt Decider Simulation at Machine Address:c36
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
>  [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)
>
>  [00000c36][0025c1f2][0025c1f6] 55          push ebp
>  [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>  [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>  [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>  [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>  [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>  [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> The above conclusively proves that the pure simulation of the input to
> H(P,P) never reaches its final state.
>

No, it doesn't

A Call to 0966 does not go to 0C36.

Unless H is LITERALLY just the equivalent of calling P agian, this is
not a proper trace.

If H IS that function, then H(P,P) will never return an answer and thus
fail.

> We don't even have to see that the first seven x86 instructions of P
> actually repeat. We can know by logical necessity that a pure simulation
> of the input to H(P,P) by H never reaches any final state of P on the
> basis of the x86 source code of P and the fact that the seventh
> instruction of P calls H.

Thus, if H IS a pure simulation, then P(P) is non-halting but H(P,P)
never answers

If H(P,P) ever answers non-Halting, then H is NOT a pure simulator, and
your simulation is incorrect and does not prove the results you claim.

FAIL.

>
> This conclusively proves that H(P,P)==0 is the correct return value for
> its input even if H never returns.
>

Yes, if H actually never returns, then 0 would have been the right answer.

But if H does return, that logic doesn't work.

> If there is no simulating halt decider H in the universe that correctly
> decides that its input (P,P) never reaches its final state then the
> input (P,P) remains undecidable, none-the-less H(P,P)==0 is still correct.
>

But since no H(P,P) ever gives that answer, H was never correct.

It doesn't matter that we know the answer for this particular case, what
matters is that H could never have given it.

You have failed to prove what you need to prove. Maybe you mean to be
proving something different, but your statement does not prove what you
seem to be claiming.

I think you just don't know exactly what the terms you are using mean.

>
>
>
> Strachey, C 1965.  An impossible program The Computer Journal, Volume 7,
> Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (318-320)
>
> Halting problem undecidability and infinitely nested simulation
> May 2021 PL Olcott
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>
>
>

olcott <NoOne@NoWhere.com> writes:

Another thread! This will be the one, will it?

> This conclusively proves that H(P,P)==0 is the correct return value
> for its input even if H never returns.

The fact is that H /does/ return. H(P,P) returns 0 which, because P(P)
halts, makes H not meet Linz's specs:

"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."

Message-ID: <JbydneYGrrpProjBnZ2dnUU7-X3NnZ2d@giganews.com>

Those were the days, eh? You could just boast about having such a
Turing machine and how you have almost finished the UTM to execute it on
(Ĥ, Ĥ). That was all before you told the world that H was wrong.

--
Ben.

On 11/6/2021 3:04 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> Another thread! This will be the one, will it?
>
>> This conclusively proves that H(P,P)==0 is the correct return value
>> for its input even if H never returns.
>
> The fact is that H /does/ return.

In this thread I am not assuming that. In this thread I prove that
H(P,P)==0 is the correct return value even if H never returns.

This proof requires a good knowledge of the x86 language as a mandatory
prerequisite.

> H(P,P) returns 0 which, because P(P)
> halts, makes H not meet Linz's specs:
>
> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
> specs does not exist. I now have a fully encoded pair of Turing
> Machines H / Ĥ proving them wrong."
>
> Message-ID: <JbydneYGrrpProjBnZ2dnUU7-X3NnZ2d@giganews.com>
>
> Those were the days, eh? You could just boast about having such a
> Turing machine and how you have almost finished the UTM to execute it on
> (Ĥ, Ĥ). That was all before you told the world that H was wrong.
>

--
Copyright 2021 Pete Olcott

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

On 11/6/21 4:15 PM, olcott wrote:
> On 11/6/2021 3:04 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>> Another thread!  This will be the one, will it?
>>
>>> This conclusively proves that H(P,P)==0 is the correct return value
>>> for its input even if H never returns.
>>
>> The fact is that H /does/ return.
>
> In this thread I am not assuming that. In this thread I prove that
> H(P,P)==0 is the correct return value even if H never returns.

It is agreed that if H really doesn't abort its simulation of P EVER,
then Not_Halting is the right answer.

To say H(P,P) == 0 is correct is a bit of a problematic statement, as
this H(P,P) never returns that 0 to be correct.

The Truth of an impossible condition isn't really relevent. I thought
you didn't like that sort of statement.

>
> This proof requires a good knowledge of the x86 language as a mandatory
> prerequisite.

No, it doesn't

>
>
>>  H(P,P) returns 0 which, because P(P)
>> halts, makes H not meet Linz's specs:
>>
>>    "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>    specs does not exist. I now have a fully encoded pair of Turing
>>    Machines H / Ĥ proving them wrong."
>>
>>    Message-ID: <JbydneYGrrpProjBnZ2dnUU7-X3NnZ2d@giganews.com>
>>
>> Those were the days, eh?  You could just boast about having such a
>> Turing machine and how you have almost finished the UTM to execute it on
>> (Ĥ, Ĥ).  That was all before you told the world that H was wrong.
>>
>
>

olcott <NoOne@NoWhere.com> writes:

> On 11/6/2021 3:04 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> Another thread! This will be the one, will it?
>>
>>> This conclusively proves that H(P,P)==0 is the correct return value
>>> for its input even if H never returns.
>>
>> The fact is that H /does/ return.
>
> In this thread I am not assuming that.

So H does not meet Linz's specs. Ten-a-penny... (You know there are
other names. You don't have to call you dog H.)

>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>> specs does not exist. I now have a fully encoded pair of Turing
>> Machines H / Ĥ proving them wrong."
>> Message-ID: <JbydneYGrrpProjBnZ2dnUU7-X3NnZ2d@giganews.com>

--
Ben.

On 11/6/2021 8:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/6/2021 3:04 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> Another thread! This will be the one, will it?
>>>
>>>> This conclusively proves that H(P,P)==0 is the correct return value
>>>> for its input even if H never returns.
>>>
>>> The fact is that H /does/ return.
>>
>> In this thread I am not assuming that.
>
> So H does not meet Linz's specs. Ten-a-penny... (You know there are
> other names. You don't have to call you dog H.)
>

I did not say that H meets the Linz specs or fails to meet the Linz
specs. I am saying that the pure simulation of the input to H(P,P) never
reaches its final state either way. This claim is very easily
empirically verifiable if you had the mandatory prerequisite knowledge.

>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>> specs does not exist. I now have a fully encoded pair of Turing
>>> Machines H / Ĥ proving them wrong."
>>> Message-ID: <JbydneYGrrpProjBnZ2dnUU7-X3NnZ2d@giganews.com>
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 11/6/2021 8:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/6/2021 3:04 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> Another thread! This will be the one, will it?
>>>>
>>>>> This conclusively proves that H(P,P)==0 is the correct return value
>>>>> for its input even if H never returns.
>>>>
>>>> The fact is that H /does/ return.
>>>
>>> In this thread I am not assuming that.
>> So H does not meet Linz's specs. Ten-a-penny... (You know there are
>> other names. You don't have to call you dog H.)
>
> I did not say that H meets the Linz specs or fails to meet the Linz
> specs.

I know. I'm just pointing it out so you know that whatever you say
about it can be safely ignored -- at least in the context of the subject
line of the post.

--
Ben.