After many reviews no one has pointed out any error in this claim:
There is no possible simulating halt decider H such that the correct
pure simulation of the input to H(P,P) ever reaches the final
instruction of P.

I suspect that the reason for this is that no one here has a sufficient
understanding of the x86 language.

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

When each instruction of the x86 source code of P is simulated in the
exact same sequence that it is specified in the above source code then
we know that this aspect of the pure simulation the input to H(P,P) is
perfectly correct.

We also know that when H is a pure simulator of its input that the
seventh line of the correct pure simulation execution trace shown below
would result in another identical sequence of seven lines.

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)

We don't need to see the 350 pages of the simulation of H to know that
if this H performs a pure simulation of its input that the above seven
lines will be repeated in the subsequent nested simulation.

Every simulating halt decider H has two possible actions:
(a) Allow the infinitely nested simulation of its input to continue (and
thus fail to be a decider).

(b) Recognized the infinitely nested simulation of its input and abort
this simulation of this input.

Anyone having the mandatory prerequisite knowledge of the x86 language
can see that there is no possible simulating halt decider H such that
the correct pure simulation of the input to H(P,P) ever reaches its
final state.

After many reviews no one has pointed out any error in this claim:
There is no possible simulating halt decider H such that the correct
pure simulation of the input to H(P,P) ever reaches the final
instruction of P.

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

If you had the mandatory prerequisite knowledge of the x86 language
(which apparently no one here does) then you would see that

On 11/7/2021 3:59 PM, Mr Flibble wrote:
> On Sun, 07 Nov 2021 20:52:58 +0000
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> On Sun, 07 Nov 2021 13:57:26 +0000
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> After many reviews no one has pointed out any error in this
>>>>> claim: There is no possible simulating halt decider H such that
>>>>> the correct pure simulation of the input to H(P,P) ever reaches
>>>>> the final instruction of P.
>>>>
>>>> As you know, there are no halt deciders
>>>
>>> Not true. As long as the decider can recognize pathological self
>>> reference and has infinite resources it can decide if a program
>>> halts.
>>
>> That's not what a halt decider is.
>
> Sure it is.
>
> /Flibble
>

....As long as the decider can... decide if a program halts:
Then we know it must be a halt decider for this program.

Because they are so highly motivated to disagree here are the key points
that no one else yet understands:

(A) If the simulated input of H(P,P) never halts then it is correct for
H to report that its simulated input never halts.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

--
Copyright 2021 Pete Olcott

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

On 11/7/2021 6:39 PM, André G. Isaak wrote:
> On 2021-11-07 17:25, olcott wrote:
>> On 11/7/2021 3:59 PM, Mr Flibble wrote:
>>> On Sun, 07 Nov 2021 20:52:58 +0000
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>>
>>>>> On Sun, 07 Nov 2021 13:57:26 +0000
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> After many reviews no one has pointed out any error in this
>>>>>>> claim: There is no possible simulating halt decider H such that
>>>>>>> the correct pure simulation of the input to H(P,P) ever reaches
>>>>>>> the final instruction of P.
>>>>>>
>>>>>> As you know, there are no halt deciders
>>>>>
>>>>> Not true. As long as the decider can recognize pathological self
>>>>> reference and has infinite resources it can decide if a program
>>>>> halts.
>>>>
>>>> That's not what a halt decider is.
>>>
>>> Sure it is.
>>>
>>> /Flibble
>>>
>>
>> ...As long as the decider can... decide if a program halts:
>> Then we know it must be a halt decider for this program.
>>
>> Because they are so highly motivated to disagree here are the key
>> points that no one else yet understands:
>>
>> (A) If the simulated input of H(P,P) never halts then it is correct
>> for H to report that its simulated input never halts.
>
> Not when you claim that the simulation can differ from the actual
> execution.

So you are saying that sometimes a cat is not a cat.
Arguing with semantic tautologies makes you look stupid.

>
>> (B) Because of the one-way dependency relationship between the
>>      executed P and the simulation of itself that it invokes: H(P,P)
>>      [ P only halts because H(P,P) returns 0 ]
>>      the executed P has different behavior than its simulated P.
>
> Putting aside your strange use of the term 'simulate', a halt decider

So again you are saying that a cat is not a cat except that you are
saying that a correct simulation is not a correct simulation.

When each instruction of the x86 source code of P is simulated in the
exact same sequence that it is specified in the above source code then
we know that this aspect of the pure simulation the input to H(P,P) is
perfectly correct.

We also know that when H is a pure simulator of its input that the
seventh line of the correct pure simulation execution trace shown below
would result in another identical sequence of seven lines.

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)

> must accurately describe the behaviour of "executed P". That's the

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

--
Copyright 2021 Pete Olcott

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

On 11/7/2021 7:24 PM, André G. Isaak wrote:
> On 2021-11-07 18:17, olcott wrote:
>> On 11/7/2021 6:39 PM, André G. Isaak wrote:
>>> On 2021-11-07 17:25, olcott wrote:
>>>> On 11/7/2021 3:59 PM, Mr Flibble wrote:
>>>>> On Sun, 07 Nov 2021 20:52:58 +0000
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>
>>>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>>>>
>>>>>>> On Sun, 07 Nov 2021 13:57:26 +0000
>>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> After many reviews no one has pointed out any error in this
>>>>>>>>> claim: There is no possible simulating halt decider H such that
>>>>>>>>> the correct pure simulation of the input to H(P,P) ever reaches
>>>>>>>>> the final instruction of P.
>>>>>>>>
>>>>>>>> As you know, there are no halt deciders
>>>>>>>
>>>>>>> Not true. As long as the decider can recognize pathological self
>>>>>>> reference and has infinite resources it can decide if a program
>>>>>>> halts.
>>>>>>
>>>>>> That's not what a halt decider is.
>>>>>
>>>>> Sure it is.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> ...As long as the decider can... decide if a program halts:
>>>> Then we know it must be a halt decider for this program.
>>>>
>>>> Because they are so highly motivated to disagree here are the key
>>>> points that no one else yet understands:
>>>>
>>>> (A) If the simulated input of H(P,P) never halts then it is correct
>>>> for H to report that its simulated input never halts.
>>>
>>> Not when you claim that the simulation can differ from the actual
>>> execution.
>>
>> So you are saying that sometimes a cat is not a cat.
>
> I never mentioned cats. I am saying that a "simulation" which differs
> from the actual execution is not actually a simulation at all.
>
>> Arguing with semantic tautologies makes you look stupid.
>
> I'm not arguing with a semantic tautology. I'm arguing against your
> rather ridiculous claims.

You are saying that when the correct pure simulation of the input to
H(P,P) never halts it is incorrect for H to report that the simulation
of its input never halts which is the same thing as saying that it is
incorrect to say that a cat is a cat.

>
>>>
>>>> (B) Because of the one-way dependency relationship between the
>>>>      executed P and the simulation of itself that it invokes: H(P,P)
>>>>      [ P only halts because H(P,P) returns 0 ]
>>>>      the executed P has different behavior than its simulated P.
>>>
>>> Putting aside your strange use of the term 'simulate', a halt decider
>>
>> So again you are saying that a cat is not a cat except that you are
>> saying that a correct simulation is not a correct simulation.
>
> If it doesn't behave identically to the actual computation then it is
> not a correct simulation.
>
> André
>
>

If there is a correct pure simulation of the input to H1(P,P) that does
behave the same as the direct execution of its input and there is
another verifiably correct pure simulation H(P,P) that does not behave
the same way as the above two then we have conclusive proof that this
latter computation is entirely different than the first two.

(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.

Because there is no such dependency relationship in H1(P,P) the pure
simulation of its input corresponds to the direct execution of this same
input.

--
Copyright 2021 Pete Olcott

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

On 11/8/2021 10:32 AM, André G. Isaak wrote:
> On 2021-11-08 08:26, olcott wrote:
>> On 11/7/2021 11:51 PM, André G. Isaak wrote:
>>> On 2021-11-07 22:00, olcott wrote:
>>>> On 11/7/2021 10:46 PM, André G. Isaak wrote:
>>>>> On 2021-11-07 20:19, olcott wrote:
>>>
>>>>>> Yet you cannot point to a single error in any of the details below
>>>>>> because there are no errors in any of the details below.
>>>>>
>>>>> I don't *need* to point out any errors in the below.
>>>>
>>>> If is it not simulated correctly then at least one of the simulated
>>>> instructions is not simulated correctly. If all of the simulated
>>>> instructions are simulated correctly then the simulation is correct.
>>>
>>> If it were being simulated correctly, the simulation would have the
>>> exact same behaviour as P(P). It does not. It is therefore not being
>>> simulated correctly. BY DEFINITION.
>>>
>>> And your trace don't show anything being simulated. If it did, the
>>> actual simulator code would be part of the trace.
>>>
>>
>> Even if I was merely simulating it in my head and writing it down
>> using cut-and-paste the fact that
>>
>> Each instruction of the x86 source code of P is simulated in the exact
>> same sequence that it is specified in the above source code then we
>> know that this aspect of the pure simulation the input to H(P,P) is
>> perfectly correct.
>
> We know that P(P) halts. Therefore you are not correctly simulating the
> instruction which causes it to halt. Therefore you are not "correctly"
> simulating it.
>

We verify that H(P,P) does perform a correct pure simulation the first
seven instructions of its input on the basis of the one-to-one mapping
of the first seven instructions of the x86 source-code of P to the first
seven steps of the listed simulation of P.

Since the seventh instruction of P simply calls H(P,P) again we know
that these same seven steps would be repeated in this nested simulation.

From these 14 correctly simulated steps we can see that the nested
simulation never stops unless H aborts it.

Because we know that the correctly simulated input to H(P,P) never
reaches its final state whether or not H(P,P) aborts the simulation of
its input we know that H(P,P)==0 is correct for every simulating halt
decider H.

--
Copyright 2021 Pete Olcott

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

On 11/8/2021 2:47 PM, André G. Isaak wrote:
> On 2021-11-08 12:52, olcott wrote:
>> On 11/8/2021 10:32 AM, André G. Isaak wrote:
>>> On 2021-11-08 08:26, olcott wrote:
>>>> On 11/7/2021 11:51 PM, André G. Isaak wrote:
>>>>> On 2021-11-07 22:00, olcott wrote:
>>>>>> On 11/7/2021 10:46 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-07 20:19, olcott wrote:
>>>>>
>>>>>>>> Yet you cannot point to a single error in any of the details
>>>>>>>> below because there are no errors in any of the details below.
>>>>>>>
>>>>>>> I don't *need* to point out any errors in the below.
>>>>>>
>>>>>> If is it not simulated correctly then at least one of the
>>>>>> simulated instructions is not simulated correctly. If all of the
>>>>>> simulated instructions are simulated correctly then the simulation
>>>>>> is correct.
>>>>>
>>>>> If it were being simulated correctly, the simulation would have the
>>>>> exact same behaviour as P(P). It does not. It is therefore not
>>>>> being simulated correctly. BY DEFINITION.
>>>>>
>>>>> And your trace don't show anything being simulated. If it did, the
>>>>> actual simulator code would be part of the trace.
>>>>>
>>>>
>>>> Even if I was merely simulating it in my head and writing it down
>>>> using cut-and-paste the fact that
>>>>
>>>> Each instruction of the x86 source code of P is simulated in the
>>>> exact same sequence that it is specified in the above source code
>>>> then we know that this aspect of the pure simulation the input to
>>>> H(P,P) is perfectly correct.
>>>
>>> We know that P(P) halts. Therefore you are not correctly simulating
>>> the instruction which causes it to halt. Therefore you are not
>>> "correctly" simulating it.
>>>
>
> You do not address the critical point: P(P) halts.

I have addressed it many times and you make sure to always ignore the
fact that P(P) and H(P,P) are proven to be entirely different
computations by the fact of the one-way dependency of P(P) on the return
value of its invocation of H(P,P).

--
Copyright 2021 Pete Olcott

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

On 11/8/2021 7:40 PM, André G. Isaak wrote:
> On 2021-11-08 17:47, olcott wrote:
>> On 11/8/2021 6:12 PM, André G. Isaak wrote:
>>> On 2021-11-08 16:41, olcott wrote:
>>>> On 11/8/2021 5:11 PM, André G. Isaak wrote:
>>>>> On 2021-11-08 15:54, olcott wrote:
>>>>>> On 11/8/2021 2:47 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-08 12:52, olcott wrote:
>>>>>>>> On 11/8/2021 10:32 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-08 08:26, olcott wrote:
>>>>>>>>>> On 11/7/2021 11:51 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-07 22:00, olcott wrote:
>>>>>>>>>>>> On 11/7/2021 10:46 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-07 20:19, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>> Yet you cannot point to a single error in any of the
>>>>>>>>>>>>>> details below because there are no errors in any of the
>>>>>>>>>>>>>> details below.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't *need* to point out any errors in the below.
>>>>>>>>>>>>
>>>>>>>>>>>> If is it not simulated correctly then at least one of the
>>>>>>>>>>>> simulated instructions is not simulated correctly. If all of
>>>>>>>>>>>> the simulated instructions are simulated correctly then the
>>>>>>>>>>>> simulation is correct.
>>>>>>>>>>>
>>>>>>>>>>> If it were being simulated correctly, the simulation would
>>>>>>>>>>> have the exact same behaviour as P(P). It does not. It is
>>>>>>>>>>> therefore not being simulated correctly. BY DEFINITION.
>>>>>>>>>>>
>>>>>>>>>>> And your trace don't show anything being simulated. If it
>>>>>>>>>>> did, the actual simulator code would be part of the trace.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Even if I was merely simulating it in my head and writing it down
>>>>>>>>>> using cut-and-paste the fact that
>>>>>>>>>>
>>>>>>>>>> Each instruction of the x86 source code of P is simulated in
>>>>>>>>>> the exact same sequence that it is specified in the above
>>>>>>>>>> source code then we know that this aspect of the pure
>>>>>>>>>> simulation the input to H(P,P) is perfectly correct.
>>>>>>>>>
>>>>>>>>> We know that P(P) halts. Therefore you are not correctly
>>>>>>>>> simulating the instruction which causes it to halt. Therefore
>>>>>>>>> you are not "correctly" simulating it.
>>>>>>>>>
>>>>>>>
>>>>>>> You do not address the critical point: P(P) halts.
>>>>>>
>>>>>> I have addressed it many times and you make sure to always ignore
>>>>>> the fact that P(P) and H(P,P) are proven to be entirely different
>>>>>
>>>>> Of course P(P) and H(P, P) are different computations. But what I
>>>>> *think* you are trying to say is that independent P(P) is different
>>>>> from what happens inside the simulator. At least *try* to say what
>>>>> you mean.
>>>>>
>>>>>> computations by the fact of the one-way dependency of P(P) on the
>>>>>> return value of its invocation of H(P,P).
>>>>>
>>>>> And you keep ignoring the fact that the computation which H(P, P)
>>>>> is supposed to be answering about is P(P).
>>>>
>>>> The pure simulation of the input to H1(P,P) is computationally
>>>> equivalent to the direct execution of P(P).
>>>>
>>>> The pure simulation of the input to H(P,P) is NOT computationally
>>>> equivalent to the direct execution of P(P).
>>>
>>> And the halt decider is being asked to describe the behaviour of the
>>> DIRECT EXECUTION of P(P). That's what halt deciders are defined to do.
>>>
>>
>> If H directly executed its input in debug step mode the result would
>> be the same. The one-way dependency that P(P) has on the return value
>> of its execution of H(P,P) makes P(P) and H(P,P) entirely different
>> computations that are not equivalent.
>
> You seem to have rather serious reading comprehension problems since you
> keep coming back to what happens inside H. The correct answer for H(P,
> P) to give is the one that corresponds to the ACTUAL DIRECT EXECUTION of
> P(P). And P(P) HALTS.
>

Even when we talk about direct execution the result is the same:

If H(P,P) directly executes its input then H simply calls P(P) in
infinite recursion instead of infinitely nested simulation. The result
is the same the input to H(P,P) never reaches its final state thus never
halts.

> And no one ever claimed P(P) and H(P, P) are equivalent. They are not
> supposed to be equivalent. H(P, P) is supposed to describe the halting
> behaviour of P(P) WHICH DOES IN FACT HALT. It isn't being asked about
> the halting behaviour of H(P, P).
>
> The question which your halt decider must answer is "does P(P) halt?"
> because that is how the halting problem is DEFINED.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

On 11/8/2021 8:25 PM, Richard Damon wrote:
> On 11/8/21 8:46 PM, olcott wrote:
>> On 11/8/2021 7:40 PM, André G. Isaak wrote:
>>> On 2021-11-08 17:47, olcott wrote:
>>>> On 11/8/2021 6:12 PM, André G. Isaak wrote:
>>>>> On 2021-11-08 16:41, olcott wrote:
>>>>>> On 11/8/2021 5:11 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-08 15:54, olcott wrote:
>>>>>>>> On 11/8/2021 2:47 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-08 12:52, olcott wrote:
>>>>>>>>>> On 11/8/2021 10:32 AM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-08 08:26, olcott wrote:
>>>>>>>>>>>> On 11/7/2021 11:51 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-07 22:00, olcott wrote:
>>>>>>>>>>>>>> On 11/7/2021 10:46 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2021-11-07 20:19, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet you cannot point to a single error in any of the
>>>>>>>>>>>>>>>> details below because there are no errors in any of the
>>>>>>>>>>>>>>>> details below.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't *need* to point out any errors in the below.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If is it not simulated correctly then at least one of the
>>>>>>>>>>>>>> simulated instructions is not simulated correctly. If all
>>>>>>>>>>>>>> of the simulated instructions are simulated correctly then
>>>>>>>>>>>>>> the simulation is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If it were being simulated correctly, the simulation would
>>>>>>>>>>>>> have the exact same behaviour as P(P). It does not. It is
>>>>>>>>>>>>> therefore not being simulated correctly. BY DEFINITION.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And your trace don't show anything being simulated. If it
>>>>>>>>>>>>> did, the actual simulator code would be part of the trace.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Even if I was merely simulating it in my head and writing it
>>>>>>>>>>>> down
>>>>>>>>>>>> using cut-and-paste the fact that
>>>>>>>>>>>>
>>>>>>>>>>>> Each instruction of the x86 source code of P is simulated in
>>>>>>>>>>>> the exact same sequence that it is specified in the above
>>>>>>>>>>>> source code then we know that this aspect of the pure
>>>>>>>>>>>> simulation the input to H(P,P) is perfectly correct.
>>>>>>>>>>>
>>>>>>>>>>> We know that P(P) halts. Therefore you are not correctly
>>>>>>>>>>> simulating the instruction which causes it to halt. Therefore
>>>>>>>>>>> you are not "correctly" simulating it.
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You do not address the critical point: P(P) halts.
>>>>>>>>
>>>>>>>> I have addressed it many times and you make sure to always
>>>>>>>> ignore the fact that P(P) and H(P,P) are proven to be entirely
>>>>>>>> different
>>>>>>>
>>>>>>> Of course P(P) and H(P, P) are different computations. But what I
>>>>>>> *think* you are trying to say is that independent P(P) is
>>>>>>> different from what happens inside the simulator. At least *try*
>>>>>>> to say what you mean.
>>>>>>>
>>>>>>>> computations by the fact of the one-way dependency of P(P) on
>>>>>>>> the return value of its invocation of H(P,P).
>>>>>>>
>>>>>>> And you keep ignoring the fact that the computation which H(P, P)
>>>>>>> is supposed to be answering about is P(P).
>>>>>>
>>>>>> The pure simulation of the input to H1(P,P) is computationally
>>>>>> equivalent to the direct execution of P(P).
>>>>>>
>>>>>> The pure simulation of the input to H(P,P) is NOT computationally
>>>>>> equivalent to the direct execution of P(P).
>>>>>
>>>>> And the halt decider is being asked to describe the behaviour of
>>>>> the DIRECT EXECUTION of P(P). That's what halt deciders are defined
>>>>> to do.
>>>>>
>>>>
>>>> If H directly executed its input in debug step mode the result would
>>>> be the same. The one-way dependency that P(P) has on the return
>>>> value of its execution of H(P,P) makes P(P) and H(P,P) entirely
>>>> different computations that are not equivalent.
>>>
>>> You seem to have rather serious reading comprehension problems since
>>> you keep coming back to what happens inside H. The correct answer for
>>> H(P, P) to give is the one that corresponds to the ACTUAL DIRECT
>>> EXECUTION of P(P). And P(P) HALTS.
>>>
>>
>> The direct execution of the input to H(P,P) does not halt therefore
>> H(P,P)==0 is correct.
>
> SO you LIE?
>
> The closest thing to 'direct execution of the input to H(P,P)' would be

int H(u32 P, u32 I)
{ ((int(*)(int))P)(I);
return 1;
}

int main()
{ H((u32)P, (u32)P);
}

--
Copyright 2021 Pete Olcott

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

On 11/9/2021 12:26 PM, Mr Flibble wrote:
> On Mon, 8 Nov 2021 07:33:44 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/8/21 12:00 AM, olcott wrote:
>>> On 11/7/2021 10:46 PM, André G. Isaak wrote:
>>>> On 2021-11-07 20:19, olcott wrote:
>>>>> On 11/7/2021 8:57 PM, André G. Isaak wrote:
>>>>>> On 2021-11-07 19:00, olcott wrote:
>>>>>>> On 11/7/2021 7:24 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-07 18:17, olcott wrote:
>>>>>>>>> On 11/7/2021 6:39 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-07 17:25, olcott wrote:
>>>>>>>>>>> On 11/7/2021 3:59 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Sun, 07 Nov 2021 20:52:58 +0000
>>>>>>>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, 07 Nov 2021 13:57:26 +0000
>>>>>>>>>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>> After many reviews no one has pointed out any error in
>>>>>>>>>>>>>>>> this claim: There is no possible simulating halt
>>>>>>>>>>>>>>>> decider H such that
>>>>>>>>>>>>>>>> the correct pure simulation of the input to H(P,P)
>>>>>>>>>>>>>>>> ever reaches
>>>>>>>>>>>>>>>> the final instruction of P.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As you know, there are no halt deciders
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not true. As long as the decider can recognize
>>>>>>>>>>>>>> pathological self
>>>>>>>>>>>>>> reference and has infinite resources it can decide if a
>>>>>>>>>>>>>> program halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's not what a halt decider is.
>>>>>>>>>>>>
>>>>>>>>>>>> Sure it is.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ...As long as the decider can... decide if a program halts:
>>>>>>>>>>> Then we know it must be a halt decider for this program.
>>>>>>>>>>>
>>>>>>>>>>> Because they are so highly motivated to disagree here are
>>>>>>>>>>> the key points that no one else yet understands:
>>>>>>>>>>>
>>>>>>>>>>> (A) If the simulated input of H(P,P) never halts then it is
>>>>>>>>>>> correct for H to report that its simulated input never
>>>>>>>>>>> halts.
>>>>>>>>>>
>>>>>>>>>> Not when you claim that the simulation can differ from the
>>>>>>>>>> actual execution.
>>>>>>>>>
>>>>>>>>> So you are saying that sometimes a cat is not a cat.
>>>>>>>>
>>>>>>>> I never mentioned cats. I am saying that a "simulation" which
>>>>>>>> differs from the actual execution is not actually a simulation
>>>>>>>> at all.
>>>>>>>>
>>>>>>>>> Arguing with semantic tautologies makes you look stupid.
>>>>>>>>
>>>>>>>> I'm not arguing with a semantic tautology. I'm arguing against
>>>>>>>> your rather ridiculous claims.
>>>>>>>
>>>>>>> You are saying that when the correct pure simulation of the
>>>>>>> input to H(P,P) never halts it is incorrect for H to report
>>>>>>> that the simulation of its input never halts which is the same
>>>>>>> thing as saying that it is incorrect to say that a cat is a
>>>>>>> cat.
>>>>>>
>>>>>> No. I am saying that H(P, P) does not perform a 'correct pure
>>>>>> simulation' of its input. A halt decider must accurately
>>>>>> describe the behaviour of the *actual* computation P(P).
>>>>
>>>>> Yet you cannot point to a single error in any of the details
>>>>> below because there are no errors in any of the details below.
>>>>
>>>> I don't *need* to point out any errors in the below.
>>>
>>> If is it not simulated correctly then at least one of the simulated
>>> instructions is not simulated correctly. If all of the simulated
>>> instructions are simulated correctly then the simulation is
>>> correct.
>>
>> The Call 966 is not simulated correctly.
>>
>> That has been pointed out before and you have ignored it, so you LIE
>> when you say that all the instructions are simulated correctly.
>>
>> You put a deciteful disclaimer that limits the correctness to only
>> the 'simulated instructions' but that is just a dishonest dodge as a
>> pure simulation must simulate ALL the instructions it come to, not
>> just some select set.
>>
>> It isn't even an equivalent simulation, as the substitution of
>> substituion of the code being simulated for the simulation of the
>> simulator is a valid transform only for an unconditional simulator,
>> and thus by doing so you are building into your precondition set that
>> H will NEVER abort its simulation. When you then decide to have H
>> abort its simulation you violate your conditions.
>>
>> That is like making a transform on an equation that is based on the
>> fact that x > x+1, because there is no such x, just as there is no H
>> that both never aborts it simulation and also aborts its simulation.
>>
>> This equivalence IS valid for just one case, the case when H actually
>> doesn't ever abort its simulation. In this case you proof does work,
>> and you do show that the P based on that H is non-halting, but
>> unfortunately for you, you also prove that in that case, H never
>> actually gives that answer, so this H isn't correct either.
>>
>> A lot of you 'logic' is just a smoke screen to try and decive the
>> reader to think that it is ok for the H that aborts its simulation to
>> be used to decide on the P based on the H that doesn't. It does get
>> that case right, but it isn't the case you need to show, you need to
>> show that an H can get the H^/P based on itself correctly.
>>
>> You seem to regularly like to reuse notation for different cases,
>> which appears to just be again part of your pattern to deceive.Even
>> you switch from H^ to P is an example of this.
>>
>>>
>>>> The fact that P(P) halts whereas your simulation does not is
>>>> sufficient to know that it is not an accurate simulation. An
>>>> accurate simulation behaves *identically* to the thing being
>>>> simulated. Yours does not. That's a simple matter of definition.
>>>>
>>>> That no one has pointed out the specific error in your trace is
>>>> because the trace omits the relevant details
>>>
>>> It does not omit any relevant details.
>>
>> WRONG. LIAR.
>>
>>>
>>>> (i.e. the point at which it decides to abort or not to abort). And
>>>> the trace is meaningless because the result of the test eax, eax
>>>> instruction depends on that omitted code.
>>>>
>>>> André
>>>>
>>>
>>> Do you understand that if H(P,P) aborts the simulation of its input
>>> that its input never reaches its final state and thus never halts?
>>>
>>
>> WRONG. The fact that H(P,P) aborts ITS Simulation of its input does
>> not affect what the PURE SIMULATION of that input would do.
>>
>> UTM(P,P) Halts whenever H(P,P) == 0, that is a simple provable fact.
>>
>> You just show you total IGNORANCE by your claim.
>>
>> H, if it returns 0, is NOT a PURE SIMULATOR, you should know it,
>> either you are a LIAR or an IDIOT.
>>
>> Which is it.
>
> (Attacking the person): This fallacy occurs when, instead of addressing
> someone's argument or position, you irrelevantly attack the person or
> some aspect of the person who is making the argument.
>
> Olcott's halt decider either decides if a program halts or does not
> halt or it throws an exception if pathological self reference occurs;
> it is thus a valid halt decider -- the third result of exception is
> perfectly valid result as it only occurs if you are DELIBERATELY trying
> to defeat the decider but I still contend the decider needs to be a
> black box to legitimately enable this behavior.
>
> /Flibble
>
> --
> This message is a troll.
>

On 11/9/2021 7:53 PM, André G. Isaak wrote:
> On 2021-11-09 14:49, olcott wrote:
>> On 11/9/2021 1:57 PM, André G. Isaak wrote:
>>> On 2021-11-09 11:10, olcott wrote:
>>>> On 11/9/2021 11:56 AM, André G. Isaak wrote:
>>>>> On 2021-11-09 10:00, olcott wrote:
>>>>>> On 11/9/2021 10:42 AM, André G. Isaak wrote:
>>>>>>> On 2021-11-09 09:09, olcott wrote:
>>>>>>>> On 11/9/2021 9:56 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-08 20:34, olcott wrote:
>>>>>>>>>
>>>>>>>>>> None-the-less I have utterly refuted the idea that H(P,P) must
>>>>>>>>>> report what the direct execution of what P(P) does. Whether
>>>>>>>>>> its input is simulated or directly executed the input to
>>>>>>>>>> H(P,P) never halts.
>>>>>>>>>
>>>>>>>>> Look, I realize that you and reality aren't exactly on speaking
>>>>>>>>> terms, but the above claim is going into lalaland even for you.
>>>>>>>>>
>>>>>>>>> To claim that you have "utterly refuted the idea that H(P,P)
>>>>>>>>> must report what the direct execution of what P(P) does." is
>>>>>>>>> tantamount to saying that you have refuted the idea that an add
>>>>>>>>> function ADD(x, y) must return the sum of x and y. You can't
>>>>>>>>> refute the idea that a program must answer the question which
>>>>>>>>> it purports to answer
>>>>>>>>>
>>>>>>>>> If H is a halt decider, then H(P, P) must BY THE DEFINITION OF
>>>>>>>>> HALT DECIDER return true if and only if P(P) halts. What a
>>>>>>>>> simulation of P(P) by H does, or what the "direct execution of
>>>>>>>>> the input to H(P, P)" (whatever the hell that means) aren't
>>>>>>>>> what a halt decider is being asked about. A halt decider is
>>>>>>>>> being asked about P(P) which you acknowledge halts. Halt
>>>>>>>>> decider is a well-defined term. You don't get to redefine the
>>>>>>>>> question which a halt decider must answer.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> To refute the claim that the direct execution of P(P) halts thus
>>>>>>>> its simulation is incorrect H(P,P) directly executes its input
>>>>>>>> instead of simulating it. The result is the infinitely nested
>>>>>>>> simulation becomes infinite recursion. In no case does the
>>>>>>>> following directly executed P ever reach its final state of c50.
>>>>>>>
>>>>>>> But the halting problem doesn't ask what happens when you call
>>>>>>> P(P) from within H. It asks what happens when you run P(P). And
>>>>>>> that computation halts.
>>>>>>>
>>>>>>
>>>>>>       the Turing machine halting problem. Simply stated, the problem
>>>>>>       is: given the description of a Turing machine M and an input w,
>>>>>>       does M, when started in the initial configuration q0w, perform
>>>>>>       a computation that eventually halts?   (Linz:1990:317).
>>>>>>
>>>>>>       In computability theory, the halting problem is the problem of
>>>>>>       determining, from a description of an arbitrary computer
>>>>>> program
>>>>>>       and an input, whether the program will finish running, or
>>>>>> continue
>>>>>>       to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> Those two references say exactly the same thing that I did. They
>>>>> CONFIRM my position.
>>>>>
>>>>
>>>> Not quite. Those two references imply that it is only the behavior
>>>> of the input to H that counts everything else is out-of-scope.
>>>
>>> You might want to take a course on remedial reading comprehension.
>>>
>>> The input to the Halt Decider is a *description* of Turing Machine M.
>>>
>>
>> The x86 equivalent of this is some description of an x86 unit of
>> computation.
>
> What exactly is a 'unit of computation"? Is that like a meter or a yen?

It is self explanatory. I use a C function as my unit of computation

>
>> The key detail that you keep missing is that it only has to decide the
>> behavior of its actual input. Some other computation that is somewhere
>> else makes not one damn bit of difference to the correctness of its
>> decision of its actual input.
>
> That "key detail" falls into the category of "not even wrong". Why don't

If you are looking for everyone that comes in the front door and Bill
comes in the back door then Bill doesn't count.

If you are analyzing the behavior of the input then anything that is not
an input doesn't count.

It is really not that hard.

> you try rereading the definitions of the halting problem that you
> posted, only this time try to actually *understand* them.
>
>> I am only focusing on the logical necessity that H(P,P)==0 is correct
>> for every simulating halt decider H until 100% complete closure of
>> this point is obtained. I will simply ignore all attempts to change
>> the subject Away from this point as a dishonest dodge.
>
> Pointing out your errors hardly counts as "changing the subject".
>
> André
>

--
Copyright 2021 Pete Olcott

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