Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

[olcott]

On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> Ĥ applied to ⟨Ĥ⟩ halts.
>
> Yes.
>
> And on the 12th Aug you said, and I quote
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> This is incorrect. You need to correct that statement so you can go on
> to investigate the consequences. It's not a trivial error. It's
> absolutely central to the case under investigation.
>
>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>
> We are both saying that -- you said it above and of course I agree. The
> point of disagreement is that you said
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
> computation.
>
>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>
> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
> string that encodes a halting computation" (I think its does mean the
> same, just poorly worded), but obviously I want to correct the clear and
> unambiguously wrong version from Aug 12th. So long as you refuse to
> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
> discussion is pointless.
>

You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
halts yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
never halts.

Because of the pathological self-reference that Flibble objected to
exists whether or not ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation depends on
its placement in the execution trace.

If Ĥ is applied to ⟨Ĥ⟩ at the beginning of the execution trace then this
Ĥ halts because of its dependency on the other instances at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩.

The inputs to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ have no such dependency thus specify an
entirely different computation.


--
Copyright 2021 Pete Olcott

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

[olcott]

On 8/20/2021 10:45 AM, Malcolm McLean wrote:
> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>
>>> You are not going to stay focused on the most serious error you have yet
>>> posted?
>> You have to go though the following reasoning and point out the specific
>> error. Making a blanket assertion that there is an error somewhere does
>> not count as any rebuttal at all.
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>> that do not have a dependency on the first Ĥ, this makes their position
>> in the execution trace have an effect on their behavior.
>>
>> Perhaps this is simply beyond your capacity to understand?
>>
>> From this we can conclude that while the simulating halt decider at
>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>
>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>> halting computation.
>> You have to find the specific error in my rebuttal of this. Making a
>> blanket assertion that there is an error somewhere does not count as any
>> rebuttal at all.
>>
> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>
> H gets H_Hat wrong, as Linz says it must do. No surprise there.
> 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 order to show that the above definition has been satisfied we only
have to show that halt decider Ĥ.qx does correctly decide whether or not
its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
⟨Ĥ2⟩.

// ⟨Ĥ1⟩ Input to Ĥ
// ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and Ĥ

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.

Key halt deciding theorem that applies to every simulating halt decider
(SHD):
(a) Every input to a SHD that never stops running unless its simulation
is aborted, or
(b) Every input that never stops running while the SHD is in pure
simulation mode.
Is an input that is correctly decided as never halting.

> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
> non halting as well. So did H_Hat(H_Hat) not halt all along, and we are too
> sinful to see it? Or is there something wrong with the execution trace?
>
> Obviously the only sane conclusion anyone can draw is that there is something
> wrong with the execution trace. So exactly what? If a function's position in the
> execution trace has an effect on its behaviour, this suggests what might be wrong.
> But whilst people can and have made sensible, informed guesses as to what is
> wrong, you're either unwilling or unable to answer some pretty basic questions
> about H. So it remains a conjecture.

[olcott]

On 8/20/2021 11:36 AM, Ben Bacarisse wrote:

> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>>
>>>> You are not going to stay focused on the most serious error you have yet
>>>> posted?
>>> You have to go though the following reasoning and point out the specific
>>> error. Making a blanket assertion that there is an error somewhere does
>>> not count as any rebuttal at all.
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>>> that do not have a dependency on the first Ĥ, this makes their position
>>> in the execution trace have an effect on their behavior.
>>>
>>> Perhaps this is simply beyond your capacity to understand?
>>>
>>> From this we can conclude that while the simulating halt decider at
>>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>>
>>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>>> halting computation.
>>> You have to find the specific error in my rebuttal of this. Making a
>>> blanket assertion that there is an error somewhere does not count as any
>>> rebuttal at all.
>>>
>> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>>
>> H gets H_Hat wrong, as Linz says it must do. No surprise there.
>>

>> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
>> non halting as well.
>

> At least one trace, explicitly of H_Hat(H_Hat), shows it halting. And
> when PO pretended that his H might meet the specification I gave for B
> (a "function return decider") it showed B_hat(B_hat) returning after a
> separate top-level call to B(B_hat, B_hat) returned 0.

>

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 order to show that the above definition has been satisfied we only
have to show that halt decider Ĥ.qx does correctly decide whether or not
its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
⟨Ĥ2⟩.

// ⟨Ĥ1⟩ Input to Ĥ
// ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞

if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.
Key halt deciding theorem that applies to every simulating halt decider
(SHD):
(a) Every input to a SHD that never stops running unless its simulation
is aborted, or
(b) Every input that never stops running while the SHD is in pure
simulation mode.
Is an input that is correctly decided as never halting.

[olcott]

On 8/20/2021 3:40 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>

>>>> I am not going to bother to answer all of this so that you can stay
>>>> focused on one key point:

>
>>> You are not going to stay focused on the most serious error you have yet
>>> posted?
>>
>> You have to go though the following reasoning and point out the
>> specific error.
>

> The specific error is that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of
> Ĥ applied to ⟨Ĥ⟩ which, everyone agrees, is a halting computation. Your
> statement of Aug 12th that

>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>

> is simply wrong in the simplest factual way. I don't have to look
> anywhere else to point out the specific error.

>

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The executed Ĥ in the above expression only halts because of its
computational dependence on the halt status decision of the simulating
halt decider on its input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩.

The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational dependence
on the executed Ĥ.

That the computational dependence of one computation on other
conclusively proves that the dependent computation is not
computationally equivalent to the independent computation may be beyond
your capacity to understand.

None-the-less the paradox is finally resolved.

[olcott]

On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/20/2021 3:32 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>

>>>> // ⟨Ĥ1⟩ Input to Ĥ
>>>> // ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ
>>>>

>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

>>>> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>

>>> Pure poetry. What does it mean to apply a string to a string? And all
>>> the ⟨Ĥi⟩ are identical to each other (and to ⟨Ĥ⟩) so I can write this as
>>>
>>>> Ĥ.q0 ⟨Ĥ2⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ1⟩ ⊢* Ĥ.qn
>>>> if ⟨Ĥ2⟩ applied to ⟨Ĥ1⟩ does not halt
>>>
>>> and it must mean exactly the same thing. You really have no idea how to
>>> use any mathematical notation.
>>
>> The point is that you are simply ignoring the dependency that the
>> executed Ĥ has on the status decision of the simulated inputs to Ĥ.qx
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>
> I am pointing out that your notation above is silly and meaningless. Of
> course you will be wrong about other things as well, but wouldn't it be
> useful to correct things one step at a time? The six supposedly clear
> symbolic lines above contain numerous errors.
>

My notion seems to be silly and meaningless in the same way that
calculus would seem silly and meaningless to a two year old. There was a
very smart four year old that could perform calculus quite well.

void P2(u32 x)
{
if (H1(x, x))
HERE: goto HERE;
}

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

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

Because H1 has identical machine code to H and the input to both of
these instances is the same the fact that they derive different results
conclusively proves that an identical function with the same input can
derive a different results when one function has computational
dependence on the other identical function.

_P2()
[00000e52](01) 55 push ebp
[00000e53](02) 8bec mov ebp,esp
[00000e55](03) 8b4508 mov eax,[ebp+08]
[00000e58](01) 50 push eax
[00000e59](03) 8b4d08 mov ecx,[ebp+08]
[00000e5c](01) 51 push ecx
[00000e5d](05) e8b0fcffff call 00000b12 // call H1
[00000e62](03) 83c408 add esp,+08
[00000e65](02) 85c0 test eax,eax
[00000e67](02) 7402 jz 00000e6b
[00000e69](02) ebfe jmp 00000e69
[00000e6b](01) 5d pop ebp
[00000e6c](01) c3 ret
Size in bytes:(0027) [00000e6c]

_main()
[00000e72](01) 55 push ebp
[00000e73](02) 8bec mov ebp,esp
[00000e75](05) 68520e0000 push 00000e52 // push P2
[00000e7a](05) 68520e0000 push 00000e52 // push P2
[00000e7f](05) e84efeffff call 00000cd2 // call H
[00000e84](03) 83c408 add esp,+08
[00000e87](01) 50 push eax
[00000e88](05) 6823030000 push 00000323
[00000e8d](05) e8c0f4ffff call 00000352
[00000e92](03) 83c408 add esp,+08
[00000e95](02) 33c0 xor eax,eax
[00000e97](01) 5d pop ebp
[00000e98](01) c3 ret
Size in bytes:(0039) [00000e98]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00000e72][00101a94][00000000] 55 push ebp
...[00000e73][00101a94][00000000] 8bec mov ebp,esp
...[00000e75][00101a90][00000e52] 68520e0000 push 00000e52 // push P2
...[00000e7a][00101a8c][00000e52] 68520e0000 push 00000e52 // push P2
...[00000e7f][00101a88][00000e84] e84efeffff call 00000cd2 // call H

Begin Local Halt Decider Simulation at Machine Address:e52
...[00000e52][00211b34][00211b38] 55 push ebp
...[00000e53][00211b34][00211b38] 8bec mov ebp,esp
...[00000e55][00211b34][00211b38] 8b4508 mov eax,[ebp+08]
...[00000e58][00211b30][00000e52] 50 push eax // push P2
...[00000e59][00211b30][00000e52] 8b4d08 mov ecx,[ebp+08]
...[00000e5c][00211b2c][00000e52] 51 push ecx // push P2
...[00000e5d][00211b28][00000e62] e8b0fcffff call 00000b12 // call H1

Begin Local Halt Decider Simulation at Machine Address:e52
...[00000e52][0025c55c][0025c560] 55 push ebp
...[00000e53][0025c55c][0025c560] 8bec mov ebp,esp
...[00000e55][0025c55c][0025c560] 8b4508 mov eax,[ebp+08]
...[00000e58][0025c558][00000e52] 50 push eax // push P2
...[00000e59][0025c558][00000e52] 8b4d08 mov ecx,[ebp+08]
...[00000e5c][0025c554][00000e52] 51 push ecx // push P2
...[00000e5d][0025c550][00000e62] e8b0fcffff call 00000b12 // call H1
...[00000e52][002a6f84][002a6f88] 55 push ebp
...[00000e53][002a6f84][002a6f88] 8bec mov ebp,esp
...[00000e55][002a6f84][002a6f88] 8b4508 mov eax,[ebp+08]
...[00000e58][002a6f80][00000e52] 50 push eax // push P2
...[00000e59][002a6f80][00000e52] 8b4d08 mov ecx,[ebp+08]
...[00000e5c][002a6f7c][00000e52] 51 push ecx // push P2
...[00000e5d][002a6f78][00000e62] e8b0fcffff call 00000b12 // call H1
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

...[00000e62][00211b34][00211b38] 83c408 add esp,+08
...[00000e65][00211b34][00211b38] 85c0 test eax,eax
...[00000e67][00211b34][00211b38] 7402 jz 00000e6b
...[00000e6b][00211b38][00000d8f] 5d pop ebp
...[00000e6c][00211b3c][00000e52] c3 ret
...[00000e84][00101a94][00000000] 83c408 add esp,+08
...[00000e87][00101a90][00000001] 50 push eax
...[00000e88][00101a8c][00000323] 6823030000 push 00000323
---[00000e8d][00101a8c][00000323] e8c0f4ffff call 00000352
Input_Halts = 1
...[00000e92][00101a94][00000000] 83c408 add esp,+08
...[00000e95][00101a94][00000000] 33c0 xor eax,eax
...[00000e97][00101a98][00100000] 5d pop ebp
...[00000e98][00101a9c][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(617658)

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

[olcott]

On 8/21/2021 8:27 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/21/2021 6:14 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>

>>>> It is trivially easy for me to understand that the simulation of ⟨Ĥ1⟩
>>>> ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops running unless
>>>> this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>>>
>>> You are reduced to saying things not in dispute as if they change any of
>>> the facts you are wrong about.
>>
>> You never agreed to this before.
>
> Don't be silly. I even gave this problem a name: "PO's Other Halting"
> problem. You remember the POOH problem? What happens "unless" (rather
> than what actually happens) is the same silly ruse you've been pulling
> for years.
>
>> Now we apply this Theorem:
>> Simulating Halt Decider Theorem (Olcott 2020):
>> A simulating halt decider correctly decides that any input that never
>> halts unless the simulating halt decider aborts its simulation of this
>> input is an input that never halts.
>
> This is not a theorem but the definition of what "correct" means for the
> POOH problem. A problem no one else cares about.
>

You have already agreed to it:

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

[olcott]

On 8/22/2021 9:45 AM, Ben Bacarisse wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:

>> I think you just got him too confused at some point and he made a
>> misstatement. You abuse the language enough that this is quite
>> possible.
>
> Excuse me! I was not at all confused. Something is lost by removing
> the context (and the rest if the paragraph that PO cuts helps to make
> the meaning clearer) but any algorithm that can decide that a simulation
> would never stop is a halt decider. The irony is that if he uses that
> algorithm to turn the simulator into a partial one, the result is not a
> halt decider!
>
> I don't really know what PO thinks I meant by these words, but since you
> are sane and knowledgeable and you think I made a mistake, my words can
> obviously be misunderstood. What did you think I was saying?
>

While a simulating halt decider is in simulation mode it cannot possibly
have any effect on the behavior of its input. While it cannot possibly
have any effect on the behavior of its input it is computationally
equivalent to a pure simulator's effect on the behavior of its input.

While a simulating halt decider is computationally equivalent to a pure
simulator and this simulation would never stop unless it stops it at
some point we can know that this input specifies infinite execution.

There may be some double-talk "rebuttal" that will fool the ignorant and
gullible if you try hard enough. The ignorant and gullible are not in my
target audience.

[olcott]

On 8/22/2021 11:14 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>>> Yes, I have agreed that you get to define what the correct answer is for
>>> any instance of the POOH problem. The wold continues to spin and no one
>>> gives a flying fig about it.

>>>
>>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> Truism:
>>>>>> Every simulation that would never stop unless Halts() stops
>>>>>> it at some point specifies infinite execution.
>>>>>
>>>>> Any algorithm that implements this truism is, of course, a halting
>>>>> decider.

>>> I find your endless quoting of this peculiar because you disagree with
>>> it! You adamantly state that you don't have a halt decider (as I and
>>> the world defines is). Are your really saying that you have such an
>>> algorithm? We know you have a partial POOH decider, but that's not what
>>> I mean when I talk of a halt decider.
>>>
>>> No comment of course on your mistake. It's too serious and too obvious
>>> to do anything but deflect attention from it. Your "⟨Ĥ⟩ ⟨Ĥ⟩ does not
>>> encode a halting computation" can not be justified.
>>
>> It is justified on the basis that it meets the

>> Simulating Halt Decider Theorem (Olcott 2020)

>> non halting criteria that you agreed to.
>
> But not on the basis of what a halt decider is.
>

You already agreed that it <is> a halting decider, any reversal on this
can only be construed as deception.

> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.

>

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The difference in the behavior of the Ĥ at the beginning of the above
template and the behavior of the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is accounted
for by the fact that these are distinctly different computations that
are not computationally equivalent.

This is much more easily understood by the H(P,P) model where every
detail is explicitly specified and no details are left to the
imagination. The very preliminary very rough draft of this analysis is
currently on page 7 of this paper.

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


The basic idea that two distinctly different computations are not
required to have the same behavior is very obviously correct common
knowledge.

The analysis of how these intuitively identical computations are
actually distinctly different is the only difficult aspect of this. The
verified fact that their correct x86 execution trace is not the same
conclusively proves that they are distinctly different computations,
thus can have different behavior without contradiction.

The same function with the same input must derive identical results or
the results are not a pure function of its inputs.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

In the above computation the computational distinction between Ĥ.qx that
transitions to its final state of Ĥ.qn and its input ⟨Ĥ1⟩ ⟨Ĥ2⟩ that
never transitions to any final state is that the execution of Ĥ.qx is
the outer-most instance of what would otherwise be an infinite set of
nested simulations.

It is the only instance of Ĥ.qx that is not under the dominion of
another instance of Ĥ.qx. This makes this outermost instance
computationally distinct from the inner instances.

>> Are you going to try to doubletalk your way out of that one?
>
> It would be a waste of everyone's time but would serve you well as a
> distraction from a, b and c. What matters (or should matter to you) is
> that you are obviously wrong. That remains true even if I were to agree
> with everything you have ever said.

[olcott]

The executed instances of H(P,P) are distinctly different computations
than the simulated instances in that the executed instances are not
under the dominion of a halt decider. It is this difference that enables
them to have different behavior.

// 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((u32)P);

[olcott]

On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:

> (anything to avoid addressing the incontrovertible facts)

>
>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>
>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>

>>> I take it you agree with a, b and c since you make no comment about
>>> them. If you do not agree, you need to say which ones you disagree
>>> with.
>
> You have not said which of a, b or c you deny. I don't want to put
> words in your mouth (what sort of person would do that, eh?) but I will
> have to assume you agree with them all if you don't say.
>

As I have already explained in complete detail your simplistic analysis
conflates together two distinctly different computations:
(1) Executed Ĥ applied to ⟨Ĥ⟩ // can't be aborted

(2) Simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ by a simulating halt decider
// can be and is aborted.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The execution of Ĥ is computationally distinct from the simulation of
⟨Ĥ1⟩ ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx so the fact that Ĥ.qx
transitions to its final state of Ĥ.qn does not contradict the fact that
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ correctly decides that its input never halts.

THIS SEEMS BEYOND YOUR CAPACITY TO COMPREHEND:
The executed instances of Ĥ are not under the dominion of a simulating
halt decider that can abort them before they get started. This
conclusively proves that they can have different behavior without
forming any contradiction.

[olcott]

On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/23/2021 8:16 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>

>>>> When a computation is forced to stop running this is an entirely
>>>> different thing than a computation that stops running because it is
>>>> has completed all of its steps. If we allow this ambiguity to remain
>>>> then disingenuous double talk seems more plausible.
>>> How is a TM "forced" to do anything?
>>
>> You aready know this,
>
> Nope. I have no idea. TM's halt or they don't and they are never
> forced to do anything. You don't really know what it means either or
> you would have addressed the question of what it means seriously.
>
>> you are merely being tediously nit picky about my choice of words.
>
> As any journal editor or article reviewer would be. Be assured that I
> am being very generous is the errors I /don't/ pick up on. Your vague
> and undefined words will be absolutely shredded by anyone who has to
> read a paper should you ever think you can write one.

>
>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>

>>>> Truism:
>>>> Every simulation that would never stop unless Halts() stops
>>>> it at some point specifies infinite execution.
>>>
>>> Any algorithm that implements this truism is, of course, a halting
>>> decider.
>>

>> You must be an atheist because a Christian knows the penalty for
>> lying.
>
> You still won't answer my question will you? Avoid, avoid, avoid! You
> quote me approvingly -- does that mean you have changed your mind and
> you are now claiming to have an algorithm that decides halting (in
> general)? You have studiously avoided making that claim so far.
>

Whether or not I have an algorithm that correctly decides halting for
all inputs is a dishonest dodge away from the point at hand.

The point at hand is that when the above criteria is used by a partial
halt decider to decide the conventional halting problem counter-examples
then it does correctly decide that these counter-examples never halt.

>>> This is, despite the absurdity, a serious question. If I gave you a TM
>>> and an input, how could you tell the difference between it simply
>>> halting ("completing all of its steps") and being "forced to stop
>>> running"? If you can't do that (and I know you can't), you should be
>>> able to show me two TM computations, one which just halts and one which
>>> is forced to stop.
>
>> When any x86/TM machine...
>
> We are talking about TMs. You probably don't know what your words games
> mean anymore than I do which is why you avoided the question. (Avoid,
> avoid, avoid!)
>

I ignore dishonest dodges away from the point at hand.

>>> And for anyone else, here's why you are wrong about your H in two
>>> sentences. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
>>> applied to ⟨Ĥ⟩. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
>>> fact, accept it.
>>
>> That is a ridiculously foolish thing to say:
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>
>> By accepting the ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does halt) the input
>> never halts.
>
> By Jove, I think you've got it!! If I can stomach using your
> non-technical terms for once the converse also holds: By rejecting the
> ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does not halt) the input halts.


>>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
>>> applied to ⟨Ĥ⟩. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
>>> fact, accept it.

Which causes it to never halts thus your:

>>> Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in fact, accept it.
Is very stupidly incorrect.

> The only question is in which way your Ĥ (and thus your H) is wrong, and
> you've told us enough times: it's wrong because it rejects ⟨Ĥ⟩ ⟨Ĥ⟩. But
> ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation precisely because H rejects ⟨Ĥ⟩
> ⟨Ĥ⟩.
>
> But thanks (seriously) for pointing out my own bad wording. You are not
> wrong because H should accept the string ⟨Ĥ⟩ ⟨Ĥ⟩, you are wrong because
> your H rejects it. I'll try to be more careful in future.

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to

⟨Ĵ⟩ never halts. There is an infinite cycle from Ĵ.qx to Ĵ.q0.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn

When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
state of H.qn

Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩ ?

[olcott]

On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> I ignore dishonest dodges away from the point at hand.

>>> OK, let's do that:

>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"

>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>> error.

>>>
>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>> ⟨Ĵ⟩ never halts.

>>> The details are mess, but basically, yes. Detail errors (that would get
>>> your paper rejected out of hand) available if you ask really nicely.
>>
>> Which details do you think are incorrect?
>
> A UTM is not a decider so the hat construction can't be applied to it.
> And if we make a "UTM-decider" (a TM that is a pure simulator except
> that is accepts those computations whose simulations terminate) we still
> can't apply the hat construction because it won't have a rejecting
> state. Thus your use of "exactly like Ĥ except..." is, at best,
> disingenuous. The differences must be greater than the "except..."
> clause suggests.
>

My whole purpose was to simply show what happens when the simulating
halt decide at Ĥ.qx only simulates its input.

We can still have the same final states, except now that are unreachable
dead code.

>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.

>>> No, but that's just because you've never written a UTM so you don't know
>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]

>>>
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>

>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting. Do you know
>>> what this notation means?
>>> And you have another problem which shows how shallow your thinking is.
>>> What is the state qn supposed to mean when J is a UTM?

>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞

>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>
>> Is it really that difficult to understand that I merely swapped Ĵ for
>> Ĥ in the Ĥ template to create the Ĵ tempate?
>
> I understand that you think you can just say that, but I also understand
> the "template" better than you appear to.
>
>>> Presumably you
>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>> simulating halting computations. So what's qn doing there? (J must
>>> have a qn for Ĵ to have qn.)

>>
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>

> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
> halts?

I am not claiming that. I am making a single change to Ĥ that now has
some unreachable dead code states.

> You just claimed the opposite. I think you are just typing
> symbols because they look good.
>
>> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the ⟨Ĵ2⟩ copy then
>> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the ⟨Ĵ3⟩ copy then
>> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
>> ⟨Ĵ4⟩ copy then ...
>
> No. Totally wrong. Your understanding of how a UTM works is
> embarrassingly shallow and I simply don't have time to explain it to
> you. In addition, you appear resistant to learning, so it would also be
> pointless. I can only suggest you change you attitude to learning and
> then read a book, Linz for example.

If the Ĥ template stipulates that those actions occur then they occur
when Ĥ has the one single modification of changing the simulating halt
decider at Ĥ.qx to a UTM.

>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn

>>> Typo: H.qn not Ĥ.qn.
>>
>> Yes, typo.

>>
>>>> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
>>>> state of H.qn

>>> If you say so. I can't know because you are hiding H
>>
>> It is the Linz H.
>
> Since, against my repeated advice, you chose to use the same symbol for
> your actual TM as Linz does for his empty class of TMs you need to be
> more careful distinguishing them.

Apparently most all of the textbooks call this H.

> "The original H" is not clear and
> discussion of it should be phrased hypothetically. You should talk
> about what Linz's H is specified to do, not what it does.
>

Yes that makes sense.

> But since you brought up Linz's H, here's a question (get your avoidance
> waffle ready!). What is Linz's H specified to do when applied to your
> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
> after the ⊢* here:
>

I am breaking that analysis down to its simpler components. We take the
Linz Ĥ and change the simulating halt decider at Ĥ.qx to a UTM and
rename this new machine Ĵ. The new machine has come dead code staes that
are never reached.

Now we apply the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩ and H transitions to its final state
of H.qn indicating that Ĵ applied to ⟨Ĵ⟩ never halts.

> L.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ?
>
> I really expect an answer to this. If you can't answer, be honest and
> say you can't.

Maybe it is easier now.

>
>>> (well, you don't
>>> actually have a TM H we are just playing pretend here). For all I know,
>>> your H gets this case wrong as well, but I am prepared to accept what
>>> you say about it.
>>
>> It is the Linz H: Nitwit !!!
>
> You should give some thought to being more respectful.

I only call people a nitwit when they seem to being too disrespectful to
me. Richard disrespectfully fails to distinguish between the words
"before" and "after" so I gave up on him.

I cannot believe that he actually fails to understand what all grade
school kids understand, he is merely playing head games beyond my
tolerance threshold.

>
>>>> Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>>>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩
>>>> ⟨Ĵ⟩ ?
>>>

>>> I am not going to answer trivial, patronising questions.
>>
>> It it a mandatory prerequisite to the next step of my proof that you
>> are persistently (intentionally ?) failing to understand.
>
> Don't be daft. You can present your argument whether or not I answer
> your patronising questions. If you choose not to, that suits me better
> because there will be fewer errors to point out if you keep it to
> yourself.
>
>> If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not

>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩
>>

>> then you should be able to understand that
>>
>> the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally
>> equivalent to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> That is beyond absurd. I leave it to you spot the silly error in your
> reasoning (though you almost certainly won't be able to). And you will
> need to account for the fact that both
>

My only "error" is that you very persistently and thus disrespectfully
fail to bother to pay attention to my proof that this is correct.

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

Output("Input_Halts = ", H1((u32)P, (u32)P));
P((u32)P);
}

The fact that the first line of main() does produce different results
than the second line of main conclusively proves that these two
computations are computationally distinct different computations.

The first line of main() decides that its input never halts. Because it
is the only halt decider it must abort the simulation of its input or
its input never halts.

The second line of main() uses an exact copy H1 of H and reports that
its input halts. It can see that another halt decider will abort its input.

The third lines of main() halts.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn (via Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩)
>
> and

>
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>

> and how that can be true of computations that are not "computationally
> equivalent". (You don't give the final state of the tape but it will be
> the same in both cases.) Let me be clear: the reasoning is silly (how
> you go from one assertion to the next) and the conclusion is wrong.
> This is not "failing to understand" it is "knowing more about the
> subject than you do".
>
> Your understanding of TM computations is woefully inadequate to discuss
> these matters. Almost everything you say contains errors, many of them
> huge errors that render your arguments null and void. Even so, nothing
> you say addresses the reason why your H is not a halt decider. Your H
> (not Linz's H) rejects a string that encodes a halting computation.
> It's as simple as that.
>

TM's always leave most of their behavior to the imagination.
The C code that I referenced is fully operational and shows every step.

[olcott]

> I know, but you wanted to know what details you'd got wrong.
>

If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
and then rename this machine to Ĵ and I did swap swap the simulating
halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it is
a God damned lie that I got anything wrong.

>> We can still have the same final states, except now that are
>> unreachable dead code.
>

> Except you show below this unreachable state being reached:
>

No I do frigging not. The code is still there but the infinite cycle
from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.

> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>

> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
> Do you see why I don't think you know what you are saying?

The you imagine what I mean to say instead of examining what I actually
say is your mistake.

This machine

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

is transformed into this machine:
Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
infinitely nested simulation

>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>
>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>
>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>

> This needs to be addressed.

That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is flatly
wrong. The design of Ĥ as a simulating halt decider stipulates that
there is a cycle from Ĥ.qx to Ĥ.q0. Changing the simulating halt decider
at Ĥ.qx to a UTM at Ĵ.qx makes this cycle infinite.

>>>>> And you have another problem which shows how shallow your thinking is.
>>>>> What is the state qn supposed to mean when J is a UTM?
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>
>>>> Is it really that difficult to understand that I merely swapped Ĵ for
>>>> Ĥ in the Ĥ template to create the Ĵ tempate?
>>> I understand that you think you can just say that, but I also understand
>>> the "template" better than you appear to.
>>>
>>>>> Presumably you
>>>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>>>> simulating halting computations. So what's qn doing there? (J must
>>>>> have a qn for Ĵ to have qn.)
>>>>
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>
>>> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
>>> halts?
>>
>> I am not claiming that.
>

> So why did you write Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn?

Because that <is> the Ĥ code with the single adaptation of swapping the
simulating halt decider at Ĥ.qx with a UTM at Ĵ.qx.

> You wrote a
> formal description of something that is impossible (qn is unreachable if
> it exists at all) and which even if it were possible is not what Ĵ
> applied to ⟨Ĵ⟩ does? No, you wrote something daft without thinking or
> maybe without know what it meant.

I wanted to make a single change to Ĥ so that I could show that the
input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ really does specify an infinite cycle that must
be aborted by its simulating halt decider. You seemed to be having an
impossibly difficult time understanding this.

>> I am making a single change to Ĥ that now has some unreachable dead
>> code states.
>

> Which state? Ĵ.qn? The one you show Ĵ.q0 ⟨Ĵ⟩ transitioning to? Yeah,
> sure.

>
>>>> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the ⟨Ĵ2⟩ copy then
>>>> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the ⟨Ĵ3⟩ copy then
>>>> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
>>>> ⟨Ĵ4⟩ copy then ...
>>> No. Totally wrong. Your understanding of how a UTM works is
>>> embarrassingly shallow and I simply don't have time to explain it to
>>> you. In addition, you appear resistant to learning, so it would also be
>>> pointless. I can only suggest you change you attitude to learning and
>>> then read a book, Linz for example.
>>
>> If the Ĥ template stipulates that those actions occur then they occur
>> when Ĥ has the one single modification of changing the simulating halt
>> decider at Ĥ.qx to a UTM.
>

> No. Give this up. You don't understand what a UTM is, and I can't
> possibly teach you. You have the result you want: the "other TM
> computation" is non-halting but it does not do that in the way you
> think, but if you keep giving details, I'll have to keep replying that
> you are wrong.

>
>>>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>>>>> Typo: H.qn not Ĥ.qn.
>>>>
>>>> Yes, typo.

> ...

>>>> It is the Linz H.
>>>
>>> Since, against my repeated advice, you chose to use the same symbol for
>>> your actual TM as Linz does for his empty class of TMs you need to be
>>> more careful distinguishing them.
>>
>> Apparently most all of the textbooks call this H.
>

> Which is further evidence that you should not. These books use H to
> refer to a hypothetical member of an empty class of TMs. Your H is
> real. It does stuff. It is not a member of an empty set. And gets at
> least one instance of the halting problem wrong because your H rejects
> the string ⟨Ĥ⟩ ⟨Ĥ⟩.
>

When I refer to the Linz H it is still hypothetical because I do not
show all of the steps.

>>> But since you brought up Linz's H, here's a question (get your avoidance
>>> waffle ready!). What is Linz's H specified to do when applied to your
>>> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
>>> after the ⊢* here:
>>>
>>
>> I am breaking that analysis down to its simpler components.
>

> So you are not going to answer. OK, it was a lot to expect -- a direct
> answer to a simple question.
>

Do you think that the Linz H might possibly do what Linz specified or do
you think that maybe I mean for it to go to the store and buy some
groceries? It is a very disingenuous question. Beside that I am freaking
applying the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩, not ⟨Ĥ⟩ ⟨Ĥ⟩.

If you want to see the result of applying a halt decider to a machine
with its own halt decider look at:

// 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 = ", H1((u32)P, (u32)P));
}

H1 is an exact copy of H and in the above configuration decides that P
halts.

>> We take the Linz Ĥ and change the simulating halt decider at Ĥ.qx to a
>> UTM and rename this new machine Ĵ. The new machine has come dead code
>> staes that are never reached.
>

> That won't help you say what Linz's H specified to do when applied to
> /your/ ⟨Ĥ⟩ ⟨Ĥ⟩. Note: to your ⟨Ĥ⟩ ⟨Ĥ⟩.
>

The question is off-topic.
I am only applying Ĥ to ⟨Ĥ⟩ or H to ⟨Ĵ⟩.

Because of my recent empirical analysis with H1/P it would seem that H
applied to ⟨Ĥ⟩ would transition to its final state of H.qy. Prior to
this empirical analysis I had no way to verify what would happen.

>> Now we apply the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩ and H transitions to its final
>> state of H.qn indicating that Ĵ applied to ⟨Ĵ⟩ never halts.
>

> Which is not what I was asking about.

I just answered that.

>
>>> L.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ?
>>>
>>> I really expect an answer to this. If you can't answer, be honest and
>>> say you can't.
>>
>> Maybe it is easier now.
>

> For who? I already know the answer. I am asking you because you can't
> (or dare not) say.

>
>>>> If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>>>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩
>>>>
>>>> then you should be able to understand that
>>>>
>>>> the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally
>>>> equivalent to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>> That is beyond absurd. I leave it to you spot the silly error in your
>>> reasoning (though you almost certainly won't be able to).
>>

>> My only "error" is that you very persistently and thus disrespectfully
>> fail to bother to pay attention to my proof that this is correct.
>

> I have never seen anything remotely resembling a proof from you. And
> you reasoning above is absurd. It's absurd and it results in an
> incorrect conclusion.

The proofs are what the H/P code actually does and why it does this.
It is true that the input to H(P,P) would never halt unless H aborts the
simulation of its input. This is easily verified by the execution trace
of the code.

It is true that whenever the input to a simulating halt decider would
never halt unless this simulating halt decider aborts the simulation of
this input that this simulating halt decider does correctly decide that
this input never halts. You already agreed to this.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

This leaves no legitimate basis for rebuttal.
This leaves no legitimate basis for rebuttal.
This leaves no legitimate basis for rebuttal.
This leaves no legitimate basis for rebuttal.

int main() { H1(P,P); }
int main() { P(P); }

The fact that the above pair agree also eliminates the illegitimate
basis for rebuttal.

> <aside>
> Part of the problem is that you don't know what a proof is. I mean that

Valid deduction on the basis of verifiably true premises <is> a proof
anyone that does not understand this is a numbskull.

> literally. Your ancient error about entailment suggests that you think
> you can just add "stipulations" that make theorems into non-theorems.

This is my only theorem, the rest is simply seeing what actual code
actually does and why it does it:

Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.

> It means you think you don't need to address the original argument
> because you think you can invalidate it with other "true" things. You
> may not know it, but this makes your "arguments" laughable in the eyes
> of educated readers. Some will find not paying attention to them the
> most respectful thing they can do.
> </aside>
>

That your "rebuttals" merely side step key points might seem to be valid
for ignorant gullible people not understanding the material well enough
to see that you simply dodged the actual reasoning.

> Not only have you no proof, there is a trivial and concrete argument
> that you are wrong: ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ applied
> to ⟨Ĥ⟩. H incorrectly reject that string.
>

By this same reasoning we could say that P(P) encodes a halting
computation yet in this case we can directly see all of the details of
how you are proved wrong.

Gullible ignorance people take emotionally charged rhetoric as
equivalent to proof. They need not see any actual evidence. As long as
someone in their reference group displays great confidence that their
baseless accusation is correct then take this as proof that it is correct.

Donald Trump's best approval rating ever was an election losing -3.9%
This is such a large election losing margin that it could not have been
overturned by the electoral college.

Gullible fools that don't believe in approval ratings need to ask
themselves if approval ratings can be manipulated then why didn't their
people manipulate an approval rating to counter the many different
scientific polls that were against Trump?

> I've cut the waffle about C code. The theorem, and the error we are
> currently discussing are about the behaviour or TMs.
>

The x86 code generated from the C code can be verified to do what its
specifies and it can also be verified that its decision basis is
correct. Most of the details of TM proofs can at best only be imagined.
These leaves huge gaps such that what is imagined does not correspond to
what actually occurs.

The C/x86 model of computation is known to be Turing equivalent on the
basis of the RASP model for all computations that have all of the memory
that they need. As long as an x86 function is a pure function of its
inputs the C/x86 model of computation can be fully relied upon as a much
higher level of abstraction of the behavior of actual Turing machines.

> And I've moved some quoted material to help with the context:

>
>>> And you will need to account for the fact that both
>>>

>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn (via Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩)
>>> and
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> and how that can be true of computations that are not "computationally
>>> equivalent". (You don't give the final state of the tape but it will be
>>> the same in both cases.)
>

> See? Every important question you just duck. Your claim that

>
> "execution of Ĥ on input ⟨Ĥ⟩ is not computationally equivalent to
> simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩"
>

Ĥ applied to ⟨Ĥ⟩ is equivalent to int main() { P(P); } both halt.

Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is equivalent to H(P,P) booth abort the
simulation of their inputs.

> is simply wrong based on facts you keep posting. I suspect you just
> don't know what any of this means and you are totally out of your
> depth. Mind you, you flop about on this issue. Elsewhere you only
> claim that the computations are distinct. Of course they are distinct.
> But here you talk about computational equivalence without, I suspect,
> knowing what that means for TMs.

>
>>> Your understanding of TM computations is woefully inadequate to discuss
>>> these matters. Almost everything you say contains errors, many of them
>>> huge errors that render your arguments null and void. Even so, nothing
>>> you say addresses the reason why your H is not a halt decider. Your H
>>> (not Linz's H) rejects a string that encodes a halting computation.
>>> It's as simple as that.
>>
>> TM's always leave most of their behavior to the imagination.
>

> No, you've just never written one or even understood one that someone
> else wrote.
>

Show me a halting problem proof that has a simulating halt decider that
is written in the Turing machine description language that has every
single detail 100% fully specified such that a Turing machine
interpreter could directly execute all of this code.

No one ever did this because:
(1) It never occurred to them that a simulating halt decider would work.
(2) without direct memory addressing it would take at least hundreds of
thousands of pages of code.

>> The C code that I referenced is fully operational and shows every
>> step.
>

> And that's a lie. You very carefully don't show the code or the
> critical steps. They are all hidden.

The steps that the halt decider performs are very obviously
self-evidently correct on the basis of the execution trace that is shown.
It is very obvious that when P calls H with its own machine address and
H is a simulating halt decider that this specifies infinitely nested
simulation.

Dishonest people can disingenuously disagree or simply fail to have the
required prerequisite knowledge.

It is also true that a simulating halt decider cannot possibly have any
effect on the behavior of its input while it remains in pure simulation
mode. Because H remains in pure simulation mode until after it makes its
halt status decision we only need to examine that it had a correct basis
and sued this correct basis correctly. 14 lines of the execution trace
of P shows this.

Dishonest people can disingenuously disagree or simply fail to have the
required prerequisite knowledge.

We can tell if a rebuttal is dishonest or the respondent simply fails to
have the required prerequisite knowledge by the fact that their
"rebuttal" is a mere dogmatic assertion without any supporting reasoning
(liar) or sidesteps rather than directly addressed the key points (liar
or ignorant).

> It's unfortunate for you that we
> can still work out that your code is wrong despite your efforts to hide
> it and to obscure its behaviour.
>
> I gave you an opportunity to write C code that is incontrovertibly
> "interesting" in that the specification is for a different undecidable
> problem, but your response was to post output showing that your (again
> hidden) code did not meet the specification. Then you declared that my
> "opinion" of what I wanted the code to do was wrong! It's hard to see
> how you expect these postings to be treated with respect. I, for one,
> am constantly biting my tongue.

[olcott]

On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/27/2021 7:01 PM, Ben Bacarisse wrote:
>>> André G. Isaak <agi...@gm.invalid> writes:
>>>
>>>> On 2021-08-27 10:18, olcott wrote:
>>>>> On 8/27/2021 10:57 AM, André G. Isaak wrote:
>>>
>>>>>> Ben never made any claims that it didn't perform some operation
>>>>>> which could be construed as the functional equivalent of copying a
>>>>>> string. He claimed that there was no *literal* copying involved
>>>>>> except in the first instance.
>>> Indeed. I see in my absence there's been a flurry of "Ben is wrong"
>>> posts from PO. Thanks, to you and RD, for stepping in.
>>>
>>>>> So in other words he said that my high level abstraction was wrong on
>>>>> the basis that it was a high level abstraction and did not delve into
>>>>> the tedious details of how this high level abstraction is
>>>>> implemented.
>>>>
>>>> No, he was claiming that your high level abstraction was *misleading*
>>>> and belied a lack of understanding of UTMs on your part.
>>> At the time I was actually calling out hard errors of fact, not just
>>> misleading abstractions. I was (dangerously) prepared to go along with
>>> the abstract view, as I (and others) have done for some time, because,
>>> whilst I agree it is potentially misleading, it's not actually wrong.
>>> But PO did not think he was talking about abstractions at the time I
>>> called him out on the mistake. He really did think that if you do the
>>> "hat" construction on a TM that is little more that a UTM, then it --
>>> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
>>> it to go from what he calls qx (the UTM's q0) back (via other states of
>>> course) to UTM^'s q0. And he thought that this loop is what wrote the
>>> endless literal copies. He used Linz's notation for TM configurations
>>> to show the strings right there on the tape next to each other, mid
>>> computation, with q0 being entered again and again.
>>
>> It does have literal endless copies and no one besides you has claimed
>> otherwise.
>
> (1) Of something, yes, but of what? Not of what you claimed.
>

When the TM copies a string the UTM must perform the functional
equivalent of copying a string. It could be as simple as a literal copy
of a string (with the additional overhead of simulation). From the
simulated TM's perspective it is a literal copy of a string.

> (2) Are you backing down from your claim about the loop in the state
> transition graph?
>

The loop in the state transition graph applies to the template as I
explicitly showed in the execution trace:

Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its
input ⟨Ĵ2⟩
which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with
its input ⟨Ĵ3⟩
which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with
its input ⟨Ĵ4⟩ ...

Ĵ copies Ĵ.qx simulates which essentially transitions to Ĵ1.q0.
This is not the conventional notion of a state transition within the
same machine. It is a more figurative use of the term so the gist of the
behavior can be understood. I changed my paper so that it no longer
refers to this cycle because the unconventional use of a term could be
more difficult to understand.

H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy

The bottom line of all of this is that H could recognize the infinitely
nested simulation of Ĵ applied to ⟨Ĵ⟩ and correctly decide that Ĵ

applied to ⟨Ĵ⟩ never halts.

> (3) You have it backwards. I only see posters agreeing with me on this
> topic.

They are careful to use double-talk that does not directly contradict
what you said. Since it is possible that the simulated Ĵ could perform a
literal string copy (having the additional overhead of simulation) your
statement that this is not what is occurring is flat out incorrect.

>>> Even if he now tries to suggest that he was using the notation in some
>>> sort of abstract way, the explicit cycle in the states gives a lie to
>>> that. He thought it was actual, literal, symbol by symbol copying every
>>> time, exactly as the extra states added by the hat construction do it.