// 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));
}

We can analyze H(P,P) at the very high level of abstraction of its two
possible behaviors relative to its input allows us to concisely prove
that not halting <is> the correct decision for this input. No matter how
H works internally the only thing that counts is the behavior of its
input for the two possible behaviors that H can have.

Since the input to H(P,P) never reaches its final state for the two
possible behaviors that every H can possibly have (abort the input or do
not abort the input) then we can conclude that not halting is the
correct decision for every possible simulating halt decider H.

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/1/2021 7:46 AM, Malcolm McLean wrote:
> On Monday, 1 November 2021 at 03:45:47 UTC, olcott wrote:
>> // 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));
>> }
>>
>> We can analyze H(P,P) at the very high level of abstraction of its two
>> possible behaviors relative to its input allows us to concisely prove
>> that not halting <is> the correct decision for this input. No matter how
>> H works internally the only thing that counts is the behavior of its
>> input for the two possible behaviors that H can have.
>>
>> Since the input to H(P,P) never reaches its final state for the two
>> possible behaviors that every H can possibly have (abort the input or do
>> not abort the input) then we can conclude that not halting is the
>> correct decision for every possible simulating halt decider H.
>>
> I can see where the confusion lies. If H never aborts, it simulates P forever.
> If it aborts, then it aborts because it has detected that otherwise P would
> simulate forever.
>
> What you are forgetting is that P depends on H. If H aborts, the P would also
> abort i.e. terminate. So if H aborts P, it aborts incorrectly, despite the fact
> that if it didn't abort, P would run forever.
> That seems like a contradiction, but it isn't really, because we are talking
> about two Ps, one with an H which never aborts, one with an H that aborts.
>

void Infinite_Loop()
{ HERE: goto HERE;
}

_Infinite_Loop()
[00000ab0](01) 55 push ebp
[00000ab1](02) 8bec mov ebp,esp
[00000ab3](02) ebfe jmp 00000ab3
[00000ab5](01) 5d pop ebp
[00000ab6](01) c3 ret
Size in bytes:(0007) [00000ab6]

If H allows Infinite_Loop() to continue then Infinite_Loop() never
reaches its final state of 0xab6. If H aborts its simulation of
Infinite_Loop() then it stops at 0xab3 and never reaches its final state
of 0xab6. H(P,P) is the same situation:

We are talking about this case shown below which conclusively proves
that every simulating halt decider H must abort its simulation its input
otherwise (just like the infinite loop shown above) its input never halts.

Aborting the input does not count as halting because the input never
reaches its final state no matter what H does. Any input that never
reaches its final state NO MATTER WHAT is an input that never halts.

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

_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36 // push P
[00000c5e](05) 68360c0000 push 00000c36 // push P
[00000c63](05) e8fefcffff call 00000966 // call H(P,P)
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]

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)

[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

The above if from pages 4 and 5
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/1/2021 5:50 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2
>
> No. H(P,P) == 0 is correct if, and only if, P(P) does not halt. But
> (according to you -- we are not allowed to see the full code) P(P)
> halts:
>

No matter what the code is for H every possible H must abort its
simulation of (P,P) otherwise this input never halts.

> || Here's the key question: do you still assert that H(P,P) == false is
> || the "correct" answer even though P(P) halts?
>

H(P,P) reports that its input never halts.
It is indeed a verified fact that its input never halts.
When you argue with verified facts you diverge from rationality.

H1(P,P) reports that P(P) halts.

Both are correct.

> | Yes that is the correct answer even though P(P) halts.
>
> No waffle can alter the fact that false (or 0 etc.) is the wrong return.
>

--
Copyright 2021 Pete Olcott

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

On 11/1/2021 9:28 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Monday, 1 November 2021 at 03:45:47 UTC, olcott wrote:
>>> // 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));
>>> }
>>>
>>> We can analyze H(P,P) at the very high level of abstraction of its two
>>> possible behaviors relative to its input allows us to concisely prove
>>> that not halting <is> the correct decision for this input. No matter how
>>> H works internally the only thing that counts is the behavior of its
>>> input for the two possible behaviors that H can have.
>>>
>>> Since the input to H(P,P) never reaches its final state for the two
>>> possible behaviors that every H can possibly have (abort the input or do
>>> not abort the input) then we can conclude that not halting is the
>>> correct decision for every possible simulating halt decider H.
>>>
>> I can see where the confusion lies. If H never aborts, it simulates P forever.
>> If it aborts, then it aborts because it has detected that otherwise P would
>> simulate forever.
>>
>> What you are forgetting is that P depends on H.
>
> What makes you think he's forgetting that? Having (at least) two
> different Hs without changing H^ (now called P) has been the ruse for
> months and months.
>
> His Halts function was declared correct because of what would happen if
> line 15 were commented out. It has always been some variation of the
> theme of "the wrong answer is right because of what would happen if H
> (but not H^) were not the function it really is".
>

No matter what the code is for H every possible H must abort its
simulation of (P,P) otherwise this input never halts.

Whether or not H(P,P) aborts its simulation of its input this input
reaches its final state, thus in all cases the input to H(P,P) never
reaches its final state thus in all cases the input to H(P,P) matches
the definition of not halting.

Now that I have generalized my proof such that this proof can be
directly applied to the Linz it is in a form that is in the ballpark of
what academic journals would accept.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ reaches Ĥ.qy

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach
Ĥ.qy or Ĥ.qn

Halting problem undecidability and infinitely nested simulation
May 2021 PL Olcott

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

>> If H aborts, the P would also
>> abort i.e. terminate. So if H aborts P, it aborts incorrectly, despite the fact
>> that if it didn't abort, P would run forever.
>> That seems like a contradiction, but it isn't really, because we are talking
>> about two Ps, one with an H which never aborts, one with an H that
>> aborts.
>
> Do you think the change of name from a dependent one (H^) to one that
> hides the dependence (P) is an accident? Might is not be part of the
> scheme to find words that make the wrong answer, H(P,P) == false, seem
> less wrong despite the fact that P(P) halts?
>

--
Copyright 2021 Pete Olcott

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

On 11/1/2021 5:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>>> || Here's the key question: do you still assert that H(P,P) == false is
>>> || the "correct" answer even though P(P) halts?
>
> To which you replied (but have for some reason cut from this post)
>
>>> | Yes that is the correct answer even though P(P) halts.
>
>> H(P,P) reports that its input never halts.
>
> H(P,P) should report on whether P(P) halts. Stating that the wrong
> answer is the right one is not how mathematics is done.
>

H1(P,P) is computationally equivalent to P(P).
H(P,P) is not computationally equivalent to P(P).

--
Copyright 2021 Pete Olcott

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

On 11/2/2021 8:19 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/1/2021 5:38 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>> || Here's the key question: do you still assert that H(P,P) == false is
>>>>> || the "correct" answer even though P(P) halts?
>>> To which you replied (but have for some reason cut from this post)
>>>
>>>>> | Yes that is the correct answer even though P(P) halts.
>>>
>>>> H(P,P) reports that its input never halts.
>>> H(P,P) should report on whether P(P) halts. Stating that the wrong
>>> answer is the right one is not how mathematics is done.
>>
>> H1(P,P) is computationally equivalent to P(P).
>> H(P,P) is not computationally equivalent to P(P).
>
> H(P,P) == false is wrong if P(P) halts.

The input to H(P,P) really does never halt this has been conclusively
proven. That you keep ignoring the verified fact that the input to
H(P,P) has been totally proven to never reaches its final state sure
seems to be an irrational break from reality to me.

It really seems that P(P) should have behavior consistent with H(P,P).
Intuitively they seem to be the same computation. When they don't have
behavior that is consistent with each other this merely proves that
intuition was wrong. Intuition is not infallible. Running the actual
code does infallibly show what the code actually does.

Since a halt decider is supposed to report what its input actually does
we still have H1(P,P) that does just that.

The whole issue with the halting problem proofs is that an input was
intentionally designed to thwart the halt decider. This has always been
understood to be an input that does the opposite of whatever the halt
decider decides.

One of the two halt deciders does get an answer that is consistent with
the behavior of its input.

> This comes from the definition
> of the problem you have been studying for more than 14 years. I think
> it's time you did something else. It seems such a waste...
>

H1(P,P) is computationally equivalent to P(P) and and reports that P(P)
halts. This is the same as applying H to ⟨Ĥ⟩ ⟨Ĥ⟩ which was something
that Linz "proved" was impossible.

--
Copyright 2021 Pete Olcott

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

On 11/2/2021 10:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/2/2021 8:19 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 11/1/2021 5:38 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>> || Here's the key question: do you still assert that H(P,P) == false is
>>>>>>> || the "correct" answer even though P(P) halts?
>>>>> To which you replied (but have for some reason cut from this post)
>>>>>
>>>>>>> | Yes that is the correct answer even though P(P) halts.
>>>>>
>>>>>> H(P,P) reports that its input never halts.
>>>>> H(P,P) should report on whether P(P) halts. Stating that the wrong
>>>>> answer is the right one is not how mathematics is done.
>>>>
>>>> H1(P,P) is computationally equivalent to P(P).
>>>> H(P,P) is not computationally equivalent to P(P).
>>> H(P,P) == false is wrong if P(P) halts.
>>
>> The input to H(P,P) really does never halt this has been conclusively
>> proven.
>
> P(P) halts. H(P,P) == false is the wrong answer if P(P) halts.
>
>> That you keep ignoring the verified fact that the input to H(P,P) has
>> been totally proven to never reaches its final state sure seems to be
>> an irrational break from reality to me.
>
> You want me to get sucked into discussing your other errors, but really
> only one counts: H(P,P) == false is the wrong answer if P(P) halts.
>

As long as H(P,P)==0 is correct none of my other "errors" are of any
consequence what-so-ever. I have conclusively proved that the input to
H(P,P) cannot possibly ever reach its final state for every possible
encoding of 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
======== ======== ======== ========= =============
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)

There are only two possible behaviors for every possible encoding of
simulating halt decider H and only one of these behaviors is correct:

(1) Continue to act as a pure simulator that never aborts the simulation
of its input. This causes the first seven instructions of P to
infinitely repeat. (You might not know the x86 language well enough to
see this).

(2) Abort the simulation of P at one of the machine addresses of P
between 0xc36 to 0xc41 at some point in the simulation of P.

Those are the only two possibilities for every possible encoding of
simulating halt decider H.

Because we applied categorically exhaustive reasoning to H(P,P) we know
that there are no gaps in this reasoning. Every possible encoding of
simulating halt decider H either aborts its simulation of its input or
fails to abort the simulation of its input. There is no third option.

Since for every possible encoding of simulating halt decider H for every
possible abort versus not abort behavior of H(P,P) the input never
reaches its final state we know know with logically justified complete
certainty that the input to H(P,P) never halts thus H(P,P)==0 is correct.

The fact that correct logic contradicts your intuition merely proves
that your intuition is incorrect.

--
Copyright 2021 Pete Olcott

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

On 11/2/2021 3:04 PM, André G. Isaak wrote:
> On 2021-11-02 11:32, olcott wrote:
>> On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>>>>> consequence what-so-ever.
>>>>>
>>>>> That's why I said one error really count: H(P,P)==0 is not correct
>>>>> because P(P) halts.  How is it that you can keep ignoring this?
>>>>
>>>> It is a verified fact that for every possible (abort / do not abort)
>>>> behavior of every possible encoding of simulating halt decider H that
>>>> the input to H(P,P) never reaches its final state.
>>>
>>> H(P,P)==0 is wrong because P(P) halts.  You keep trying to explain some
>>> other decision problem that you think H is getting right.  For the
>>> halting problem -- the one you've been "studying" for more than 14 years
>>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
>>> that is does.
>>>
>>>> It is like I am telling there are no integers between 1 and 2 and you
>>>> just don't believe it.
>>>
>>> No, its like you are tell me that H(P,P)==false is the right answer from
>>> a halt decider when P(P) is a halting computation.  In fact it's very
>>> much like that.  Almost exactly like that in fact.
>>>
>>>> It seems to be intuitively true that H(P,P) should report that its
>>>> input halts because P(P) halts.
>>>
>>> No.  I have no intuition about what you even mean because inputs don't
>>> do anything.  What is true by definition (no intuition required) is that
>>> H(P,P) should be false only if P(P) does not halt.
>>>
>>>> This intuition
>>>
>>> I don't have that intuition.  What "the input" does is meaningless.
>>
>> Every halt decider is ONLY tasked with determining the behavior of its
>> input. That you say otherwise is very stupid.
>
> Why don't you go back and reread definition of Halt Decider given in
> 12.1 in Linz.
>
> Let w_M be a string that describes a Turing machine M, and let w be a
> string in M’s alphabet. A solution of the halting problem is a Turing
> machine H, which for any w_M and w performs the computation:
>
> q_0 w_M w ⊢* x_1 q_y x_2 if M applied to w halts, and
> q_0 w_M w ⊢* x_1 q_n x_2 if M applied to w does not halt
>
> The input to this machine is w_M plus the input string w. The conditions
> specified to the two final states make no mention whatsoever of w_M.
> They talk about *M* applied to w.
>

By saying it that way people can be confused (the same way that Linz
himself was confused) into believing that the question is about whether
or not the halt decider itself at Ĥ.qx halts.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The behavior of the input to the halt decider after Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
has nothing to do with whether or not the halt decider itself halts.

The fact that the input to H(P,P) never reaches its final state under
both aborting and not aborting behaviors for every possible encoding of
simulating halt decider H conclusively proves that the input to H(P,P)
never halts and H(P,P)==0 is correct.

Shown on pages 4 and 5 of this paper:
Halting problem undecidability and infinitely nested simulation
May 2021 PL Olcott

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

The key part to pay attention to it the execution trace of the first
seven lines of the x86 code for P:

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)

--
Copyright 2021 Pete Olcott

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

On 2021-11-02 14:24, olcott wrote:
> On 11/2/2021 3:04 PM, André G. Isaak wrote:
>> On 2021-11-02 11:32, olcott wrote:
>>> On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>>>>>> consequence what-so-ever.
>>>>>>
>>>>>> That's why I said one error really count: H(P,P)==0 is not correct
>>>>>> because P(P) halts.  How is it that you can keep ignoring this?
>>>>>
>>>>> It is a verified fact that for every possible (abort / do not abort)
>>>>> behavior of every possible encoding of simulating halt decider H that
>>>>> the input to H(P,P) never reaches its final state.
>>>>
>>>> H(P,P)==0 is wrong because P(P) halts.  You keep trying to explain some
>>>> other decision problem that you think H is getting right.  For the
>>>> halting problem -- the one you've been "studying" for more than 14
>>>> years
>>>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
>>>> that is does.
>>>>
>>>>> It is like I am telling there are no integers between 1 and 2 and you
>>>>> just don't believe it.
>>>>
>>>> No, its like you are tell me that H(P,P)==false is the right answer
>>>> from
>>>> a halt decider when P(P) is a halting computation.  In fact it's very
>>>> much like that.  Almost exactly like that in fact.
>>>>
>>>>> It seems to be intuitively true that H(P,P) should report that its
>>>>> input halts because P(P) halts.
>>>>
>>>> No.  I have no intuition about what you even mean because inputs don't
>>>> do anything.  What is true by definition (no intuition required) is
>>>> that
>>>> H(P,P) should be false only if P(P) does not halt.
>>>>
>>>>> This intuition
>>>>
>>>> I don't have that intuition.  What "the input" does is meaningless.
>>>
>>> Every halt decider is ONLY tasked with determining the behavior of
>>> its input. That you say otherwise is very stupid.
>>
>> Why don't you go back and reread definition of Halt Decider given in
>> 12.1 in Linz.
>>
>> Let w_M be a string that describes a Turing machine M, and let w be a
>> string in M’s alphabet. A solution of the halting problem is a Turing
>> machine H, which for any w_M and w performs the computation:
>>
>> q_0 w_M w ⊢* x_1 q_y x_2 if M applied to w halts, and
>> q_0 w_M w ⊢* x_1 q_n x_2 if M applied to w does not halt
>>
>> The input to this machine is w_M plus the input string w. The
>> conditions specified to the two final states make no mention
>> whatsoever of w_M. They talk about *M* applied to w.
>>
>
> By saying it that way people can be confused (the same way that Linz

Saying it that way is how halt decider is *defined*. Not just by Linz,
but by *everyone* who has ever discussed this problem.

If you want to discuss the halting problem, this is the definition you
must use.

> himself was confused) into believing that the question is about whether
> or not the halt decider itself at Ĥ.qx halts.

(A) There is no halt decider at Ĥ.qx
(B) There is nothing to get confused about. The input to the submachine
at Ĥ.qx is the string ⟨Ĥ⟩ ⟨Ĥ⟩. Any decision made by Ĥ.qx (which is not a
halting decision) makes a decision about Ĥ applied to ⟨Ĥ⟩.

Ĥ, Ĥ.qx, and w_Ĥ (or ⟨Ĥ⟩ to use your notion) are three different things.
Why would anyone confuse w_Ĥ with Ĥ.qx?

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> The behavior of the input to the halt decider after Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
> has nothing to do with whether or not the halt decider itself halts.

Nor does the definition given above claim that it does. Any comfusion
here is purely confusion on your part.

André

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

On 11/2/2021 3:38 PM, André G. Isaak wrote:
> On 2021-11-02 14:24, olcott wrote:
>> On 11/2/2021 3:04 PM, André G. Isaak wrote:
>>> On 2021-11-02 11:32, olcott wrote:
>>>> On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of
>>>>>>>> any
>>>>>>>> consequence what-so-ever.
>>>>>>>
>>>>>>> That's why I said one error really count: H(P,P)==0 is not correct
>>>>>>> because P(P) halts.  How is it that you can keep ignoring this?
>>>>>>
>>>>>> It is a verified fact that for every possible (abort / do not abort)
>>>>>> behavior of every possible encoding of simulating halt decider H that
>>>>>> the input to H(P,P) never reaches its final state.
>>>>>
>>>>> H(P,P)==0 is wrong because P(P) halts.  You keep trying to explain
>>>>> some
>>>>> other decision problem that you think H is getting right.  For the
>>>>> halting problem -- the one you've been "studying" for more than 14
>>>>> years
>>>>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
>>>>> that is does.
>>>>>
>>>>>> It is like I am telling there are no integers between 1 and 2 and you
>>>>>> just don't believe it.
>>>>>
>>>>> No, its like you are tell me that H(P,P)==false is the right answer
>>>>> from
>>>>> a halt decider when P(P) is a halting computation.  In fact it's very
>>>>> much like that.  Almost exactly like that in fact.
>>>>>
>>>>>> It seems to be intuitively true that H(P,P) should report that its
>>>>>> input halts because P(P) halts.
>>>>>
>>>>> No.  I have no intuition about what you even mean because inputs don't
>>>>> do anything.  What is true by definition (no intuition required) is
>>>>> that
>>>>> H(P,P) should be false only if P(P) does not halt.
>>>>>
>>>>>> This intuition
>>>>>
>>>>> I don't have that intuition.  What "the input" does is meaningless.
>>>>
>>>> Every halt decider is ONLY tasked with determining the behavior of
>>>> its input. That you say otherwise is very stupid.
>>>
>>> Why don't you go back and reread definition of Halt Decider given in
>>> 12.1 in Linz.
>>>
>>> Let w_M be a string that describes a Turing machine M, and let w be a
>>> string in M’s alphabet. A solution of the halting problem is a Turing
>>> machine H, which for any w_M and w performs the computation:
>>>
>>> q_0 w_M w ⊢* x_1 q_y x_2 if M applied to w halts, and
>>> q_0 w_M w ⊢* x_1 q_n x_2 if M applied to w does not halt
>>>
>>> The input to this machine is w_M plus the input string w. The
>>> conditions specified to the two final states make no mention
>>> whatsoever of w_M. They talk about *M* applied to w.
>>>
>>
>> By saying it that way people can be confused (the same way that Linz
>
> Saying it that way is how halt decider is *defined*. Not just by Linz,
> but by *everyone* who has ever discussed this problem.
>
> If you want to discuss the halting problem, this is the definition you
> must use.
>

If everyone "defines" that the halt decider is wrong when it correctly
reports what the actual behavior of its actual input would be then
everyone (besides me) is wrong.

--
Copyright 2021 Pete Olcott

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

On 11/2/2021 4:05 PM, André G. Isaak wrote:
> On 2021-11-02 14:43, olcott wrote:
>
>> If everyone "defines" that the halt decider is wrong when it correctly
>> reports what the actual behavior of its actual input would be then
>> everyone (besides me) is wrong.
>
> The definition tells you what a halt decider *is*. It doesn't define it
> as 'wrong'. It defines what question it is supposed to answer.
>
> The input to a halt decider is a string. Strings don't *have* halting
> behaviour so your position above is entirely incoherent.
>

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

A halt decider only need answer whether or not the correct simulation of
its input would ever reach a final state of this input by a simulating
halt decider.

In every case where the answer is "no" every encoding of any simulating
halt decider would correctly decide the halt status of this input as
"not halting".

> The string w_Ĥ w_Ĥ describes the computation where the Turing Machine Ĥ
> is applied to the string w_Ĥ. That computation halts. And it is the
> behaviour of that computation that a halting decider must report when
> given w_Ĥ w_Ĥ as an input BECAUSE THAT'S WHAT A HALT DECIDER IS DEFINED
> TO DO.
>
> Your claim that the "input" doesn't halt even though the actual machine
> does simply illustrates that you are clueless about what the actual
> halting problem is.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 11/2/2021 4:49 PM, André G. Isaak wrote:
> On 2021-11-02 15:41, olcott wrote:
>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>> On 2021-11-02 14:43, olcott wrote:
>>>
>>>> If everyone "defines" that the halt decider is wrong when it
>>>> correctly reports what the actual behavior of its actual input would
>>>> be then everyone (besides me) is wrong.
>>>
>>> The definition tells you what a halt decider *is*. It doesn't define
>>> it as 'wrong'. It defines what question it is supposed to answer.
>>>
>>> The input to a halt decider is a string. Strings don't *have* halting
>>> behaviour so your position above is entirely incoherent.
>>>
>>
>> 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
>
> The definition of 'halting problem' is what it is.
>
> Note that the above definition doesn't make any mentions of
> 'simulations' just as the more formal definition used by Linz's does not.
>
>> A halt decider only need answer whether or not the correct simulation
>> of its input would ever reach a final state of this input by a
>> simulating halt decider.
>
> A 'correct simulation', presumably, would be one that acts identically
> to the actual TM being simulated. That means that if the actual TM halts
> the simulation also must halt. Which means that your simulation is not a
> 'correct simulation'.
>

There are no freaking presumptions about it. As long as the simulation
of P(P) matches its x86 source code then the simulation is correct.

If you don't agree with this then you are either:
(a) A liar
(b) Stupid
(c) Clueless

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

A correct simulation of P on input P can be empirically validated by the
simulation of the first seven x86 instruction of P.

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)

Because the simulation of P(P) matches its x86 source-code it is
necessarily correct and impossibly incorrect.

The only possibility for every encoding of simulating halt decider H is:

(a) H fails to abort its simulation (and thus fails to be a decider) and
the first seven instructions of P infinitely repeat in which case P
never reaches its final state of 0xc50.

(b) H aborts its simulation of P at some address of P between 0xc36 and
0xc41 in which case the input P fails to every reach its final state of
0xc50.

One the basis of the correct simulation of the x86 source-code of P(P)
we can see that it is utterly impossible for P to ever reach its final
state of 0xc50.

> If a simulation can have a different behaviour then the actual program,
> then that simulation can't be used to answer the question which a halt
> decider is supposed to answer.
>
> You really ought to consider a different line of 'work'. Have you
> thought of maybe inventing a perpetual motion machine or of squaring the
> circle? Maybe you'd have more luck with those.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 11/3/2021 11:00 AM, André G. Isaak wrote:
> On 2021-11-03 09:47, olcott wrote:
>
>> THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
>> A halt decider only need answer whether or not the correct pure
>> simulation of its input would ever reach a final state of this input
>> by a simulating halt decider.
>
> The halting problem already defines what the criterion used by a halt
> decider must be. You don't get to update it if that's the problem you
> want to work on.
>
> André
>

No one here seems capable of understanding is that when a halt decider
does correctly decide the halt status of its input then its input has
had its halt status correctly decided.

Even Linz got confused about this.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
It does not matter whether or not the halt decider at Ĥ.qx halts or not
the only thing that matters is whether or not the simulation of the
input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ever reaches a final state.

The mistake is just like putting Bill Smith in jail for robbing a liquor
store because Bill Jones did Rob a liquor store.

As long as a halt decider does correctly decide the halt status of its
input nothing else in the universe can show that the halt decider is
incorrect.

--
Copyright 2021 Pete Olcott

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

On 11/3/2021 5:10 PM, André G. Isaak wrote:
> On 2021-11-03 15:18, olcott wrote:
>> On 11/3/2021 4:03 PM, André G. Isaak wrote:
>
>>> But your halt decider doesn't implement a 'pure simulation' under any
>>> reasonable definition of the term.
>>
>> _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)
>>
>> 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.
>
> And so what? Somethings either a pure simulator or it isn't.

That it is a pure simulator 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.

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