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

_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)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

We can perfectly know that H(P,P) does precisely simulate the first
seven instructions of P when it simulates the first seven instructions of P.

We can also know that when it perfectly repeats this sequence again that
it has acted as a pure simulator for the execution of these two sequences.

That it is a pure simulator up to this point conclusively proves that
it is a pure simulator up to this point and conclusively proves that
a pure simulation would never halt.

2021-11-03 Update to Halt Decider Criteria
It is impossible for any halt decider to be incorrect when the correct
pure simulation of its input never halts and it reports not halting.

Halting problem undecidability and infinitely nested simulation
May 2021 PL Olcott (above is from pages 4 and 5)

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

olcott <NoOne@NoWhere.com> writes:

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

But H(P,P) == 0 is not correct if P(P) halts and you have told us that
both are the case (for the specific H you are touting). That false is
the wrong return for inputs that represent halting computations comes
from the definition of the problem you claim to be addressing.

--
Ben.

On 11/3/21 7:14 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;
> }
>
> _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)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> We can perfectly know that H(P,P) does precisely simulate the first
> seven instructions of P when it simulates the first seven instructions
> of P.
>

Except it does NOT correctly simulate the call instruction, and just ONE
error makes it unrelaible.

> We can also know that when it perfectly repeats this sequence again that
> it has acted as a pure simulator for the execution of these two sequences.

WRONG. It has ignored the behavior or H, which if H(P,P) returns
non-halting at the top level, will do so here when the machine this
input is actually run or this input is given to a UTM (as the DEFINITION
of the answer a Halt Decider is supposed to answer), we KNOW this call
will return that same non-halting and the transform that H has used was
invalid.

>
> That it is a pure simulator up to this point conclusively proves that
> it is a pure simulator up to this point and conclusively proves that
> a pure simulation would never halt.

Which means it is NOT a pure simulator.

Being a pure simulator up to ... is like claiming to be immortal up to
the point you die. If H will abort the simulation, it NEVER was a pure
simulator (maybe it played one on TV) just like a person who will die
was never immortal.

>
> 2021-11-03 Update to Halt Decider Criteria
> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.

And the CORRECT pure simulation of the input MUST do exactly the same
thing as the running of the computation that the input represents, which
if H(P,P) returns non-halting (which you claim it does as the right
answer) then this computation WILL Halt, as you even admit.

Only your INCORRECT, and thus NOT PURE simulation of the input implies
non-halting behavior.

>
> Halting problem undecidability and infinitely nested simulation
> May 2021 PL Olcott  (above is from pages 4 and 5)
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

On 11/3/2021 6:21 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>
> But H(P,P) == 0 is not correct if P(P) halts and you have told us that
> both are the case (for the specific H you are touting). That false is
> the wrong return for inputs that represent halting computations comes
> from the definition of the problem you claim to be addressing.
>

I provided all of the details to prove that I am correct and you simply
ignored and erased them. This is apparently because you realized that my
proof is irrefutable thus realize any attempt at rebuttal could only
seem foolish. Alternatively you are clueless about the x86 language.

--
Copyright 2021 Pete Olcott

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

On 11/4/21 12:50 AM, olcott wrote:
> On 11/3/2021 6:21 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>
>> But H(P,P) == 0 is not correct if P(P) halts and you have told us that
>> both are the case (for the specific H you are touting).  That false is
>> the wrong return for inputs that represent halting computations comes
>> from the definition of the problem you claim to be addressing.
>>
>
> I provided all of the details to prove that I am correct and you simply
> ignored and erased them. This is apparently because you realized that my
> proof is irrefutable thus realize any attempt at rebuttal could only
> seem foolish. Alternatively you are clueless about the x86 language.
>

Except that you 'proof' is totally baseless since it is built on false
assumptions.

You simulator is NOT even an accurate simulation of what the input
machine does, since your H skips the behavior of the copy of H inside
the machine it is simulating, and has replaced H with a DIFFERENT
function that always just calls (by simulation) the machine given as the
input. This substitution would be valid if H actual did the equivalanet
of it, but it doesn't since H will stop its simulation and return
non-halting instead of the assumed simulate forever.

Since H is NOT a accurate simulation, your whole basis is wrong.

Please note the DEFINITION of a simulation, an accurate recreation of
what the reality would do.

We KNOW that H is not an accurate simulation as when we look at the
simulation, the simulation has determined that H(P,P) is a non-halting
operation, that this function will NEVER return an answer, but you also
claim that H(P,P) returns in finite time that its input represents a
non-halting computation.

H(P,P) can not both return an answer and be non-halting, so the
simulation of H, and thus the simulation of P which includes the
simulation of H can not be accurate.

The only way for the simulation to be accurate is for H to NOT actually
be the computation it claims, so that one copy of H does return an
answer of non-halting and another copy is non-halting, but then we get
the problem that a correct simulation BY DEFINITION is a pure
computation, being a function dependent only on its defined input, so if
H isn't actually a computation it can't be an accurate simulator.

FAIL.

olcott <NoOne@NoWhere.com> writes:

> On 11/3/2021 6:21 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>> But H(P,P) == 0 is not correct if P(P) halts and you have told us that
>> both are the case (for the specific H you are touting). That false is
>> the wrong return for inputs that represent halting computations comes
>> from the definition of the problem you claim to be addressing.
>
> I provided all of the details to prove that I am correct and you
> simply ignored and erased them.

That you are wrong is matter of the definition of the problem. Other
people seen keen to discuss the way in which you code traces are also
wrong, but that seems superfluous to me.

> This is apparently because you realized that my proof is irrefutable
> thus realize any attempt at rebuttal could only seem
> foolish.

Any "proof" that does not start from the correct definition of the
problem is irrelevant. Mind you, you still think that if {A,B,C} ⊦ X
then {A,B,C,~A} ⊬ X, so what you mean by "proof" is anyone's guess.

I'm struggling to think you don't know how silly rejecting the
definition of the problem is. For one thing, your original delusion was
that you had an H that everyone said was impossible, but an H that has
H(P,P) == 0 and P(P) halting is utterly trivial. Surely you know
everyone here could write such an H in a few seconds.

> Alternatively you are clueless about the x86 language.

You really, really want people to get into the traces, and all the other
junk, just to distract from the fact that after 14 years of work on the
halting problem, your "solution" is a H that give the wrong answer!

--
Ben.

On 11/4/2021 7:36 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/3/2021 6:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>> But H(P,P) == 0 is not correct if P(P) halts and you have told us that
>>> both are the case (for the specific H you are touting). That false is
>>> the wrong return for inputs that represent halting computations comes
>>> from the definition of the problem you claim to be addressing.
>>
>> I provided all of the details to prove that I am correct and you
>> simply ignored and erased them.
>
> That you are wrong is matter of the definition of the problem. Other
> people seen keen to discuss the way in which you code traces are also
> wrong, but that seems superfluous to me.
>

If that was correct then you would have been able to point out the error
in my complete proof instead of just erasing it all.

You did not point out the error and erased it all only because you knew
that it was totally correct.

2021-11-03 Halt Deciding Criteria
It is impossible for any halt decider to be incorrect when the correct
pure simulation of its input never halts and it reports not halting.

>> This is apparently because you realized that my proof is irrefutable
>> thus realize any attempt at rebuttal could only seem
>> foolish.
>
> Any "proof" that does not start from the correct definition of the
> problem is irrelevant. Mind you, you still think that if {A,B,C} ⊦ X
> then {A,B,C,~A} ⊬ X, so what you mean by "proof" is anyone's guess.
>
> I'm struggling to think you don't know how silly rejecting the
> definition of the problem is. For one thing, your original delusion was
> that you had an H that everyone said was impossible, but an H that has
> H(P,P) == 0 and P(P) halting is utterly trivial. Surely you know
> everyone here could write such an H in a few seconds.
>
>> Alternatively you are clueless about the x86 language.
>
> You really, really want people to get into the traces, and all the other
> junk, just to distract from the fact that after 14 years of work on the
> halting problem, your "solution" is a H that give the wrong answer!
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 11/4/2021 7:36 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/3/2021 6:21 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>> But H(P,P) == 0 is not correct if P(P) halts and you have told us that
>>>> both are the case (for the specific H you are touting). That false is
>>>> the wrong return for inputs that represent halting computations comes
>>>> from the definition of the problem you claim to be addressing.
>>>
>>> I provided all of the details to prove that I am correct and you
>>> simply ignored and erased them.
>>
>> That you are wrong is matter of the definition of the problem. Other
>> people seen keen to discuss the way in which you code traces are also
>> wrong, but that seems superfluous to me.
>
> If that was correct then you would have been able to point out the
> error in my complete proof instead of just erasing it all.

I think you've lost the plot. The error is at the very start: H(P,P) ==
0 is wrong because P(P) halts. If you don't start from the right idea
of what a halt decider is, everything that follows is irrelevant.
Importantly, it may also be 100% correct. Irrelevant does not mean
wrong, but it does mean no one needs to bother looking at it.

> You did not point out the error and erased it all only because you
> knew that it was totally correct.

I have pointed out your mistake in every recent post: H(P,P) == 0 is
wrong because P(P). It is perfectly possible that everything you say
after this is 100% correct. There is no point in looking for an error
that might not be there.

> 2021-11-03 Halt Deciding Criteria
> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.

That's only half the story. If simulation of the input does halt, a
halt decider must return true. When you put both halves together you
get the much simpler definition that H(M,I) == true if an only if M(I)
halts. That's why your H is wrong. P(P) halts but H(P,P) == false.

(I keep saying this because you like to pretend that I am not pointing
out your errors.)

>>> This is apparently because you realized that my proof is irrefutable
>>> thus realize any attempt at rebuttal could only seem
>>> foolish.
>>
>> Any "proof" that does not start from the correct definition of the
>> problem is irrelevant. Mind you, you still think that if {A,B,C} ⊦ X
>> then {A,B,C,~A} ⊬ X, so what you mean by "proof" is anyone's guess.
>>
>> I'm struggling to think you don't know how silly rejecting the
>> definition of the problem is. For one thing, your original delusion was
>> that you had an H that everyone said was impossible, but an H that has
>> H(P,P) == 0 and P(P) halting is utterly trivial. Surely you know
>> everyone here could write such an H in a few seconds.

I'll leave this because both points are instructive to newcomers: your
not knowing what logical entailment is, and the idea that anyone could
think that an H with H(P,P) == 0 and P(P) halting was interesting let
along impossible.

--
Ben.

On 11/4/2021 5:59 AM, Richard Damon wrote:
> On 11/4/21 12:50 AM, olcott wrote:
>> On 11/3/2021 6:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>
>>> But H(P,P) == 0 is not correct if P(P) halts and you have told us that
>>> both are the case (for the specific H you are touting).  That false is
>>> the wrong return for inputs that represent halting computations comes
>>> from the definition of the problem you claim to be addressing.
>>>
>>
>> I provided all of the details to prove that I am correct and you
>> simply ignored and erased them. This is apparently because you
>> realized that my proof is irrefutable thus realize any attempt at
>> rebuttal could only seem foolish. Alternatively you are clueless about
>> the x86 language.
>>
>
> Except that you 'proof' is totally baseless since it is built on false
> assumptions.
>
_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)

Verified facts:
(1) The above 14 simulated lines are a correct pure simulation of P(P)
for every possible encoding of simulating halt decider H.

(2) The above 14 simulated lines conclusively prove that the pure
simulation of the input to H(P,P) would never reach its final state of
c50 for every possible encoding of simulating halt decider H.

(1) and (2) conclusively prove that H(P,P) meets this criteria:

2021-11-03 Halt Deciding Criteria
It is impossible for any halt decider to be incorrect when the correct
pure simulation of its input never halts and it reports not halting.

--
Copyright 2021 Pete Olcott

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

On 11/4/21 11:19 AM, olcott wrote:
> On 11/4/2021 5:59 AM, Richard Damon wrote:
>> On 11/4/21 12:50 AM, olcott wrote:
>>> On 11/3/2021 6:21 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>> }
>>>>
>>>> But H(P,P) == 0 is not correct if P(P) halts and you have told us that
>>>> both are the case (for the specific H you are touting).  That false is
>>>> the wrong return for inputs that represent halting computations comes
>>>> from the definition of the problem you claim to be addressing.
>>>>
>>>
>>> I provided all of the details to prove that I am correct and you
>>> simply ignored and erased them. This is apparently because you
>>> realized that my proof is irrefutable thus realize any attempt at
>>> rebuttal could only seem foolish. Alternatively you are clueless
>>> about the x86 language.
>>>
>>
>> Except that you 'proof' is totally baseless since it is built on false
>> assumptions.
>>
> _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)
>
> Verified facts:
> (1) The above 14 simulated lines are a correct pure simulation of P(P)
> for every possible encoding of simulating halt decider H

Incorrect, a PURE simulation would trace teh call at C41 to 966 and show
what happens at 966.

This is NOT a pure simultion.

>
> (2) The above 14 simulated lines conclusively prove that the pure
> simulation of the input to H(P,P) would never reach its final state of
> c50 for every possible encoding of simulating halt decider H.

INCORRECT.

>
> (1) and (2) conclusively prove that H(P,P) meets this criteria:

INCORRECT.

>
> 2021-11-03 Halt Deciding Criteria
> It is impossible for any halt decider to be incorrect when the correct
> pure simulation of its input never halts and it reports not halting.
>
>
FAIL.