On 12/31/2021 7:37 PM, André G. Isaak wrote:
> On 2021-12-31 18:17, olcott wrote:
>> On 12/31/2021 7:11 PM, André G. Isaak wrote:
>>> On 2021-12-31 17:05, olcott wrote:
>>>> On 12/31/2021 5:33 PM, André G. Isaak wrote:
>>>>> On 2021-12-31 16:02, olcott wrote:
>>>>>> On 12/31/2021 4:06 PM, André G. Isaak wrote:
>>>>
>>>>>> An actual computer scientist will understand that embedded_H does
>>>>>> compute the mapping from these inputs finite strings ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>> this final state Ĥ.qn on the basis that the actual input would
>>>>>> never halt.
>>>>>
>>>>> You're not really in a position to state what an actual computer
>>>>> scientist would understand. Only an actual computer scientist can
>>>>> do that.
>>>>>
>>>>
>>>> It is a self-evident truth that:
>>>> (a) The pure simulation of the Turing machine description of a
>>>> machine is computationally equivalent to the direct execution of
>>>> this machine.
>>>>
>>>> (b) The pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never halt.
>>>>
>>>> (c) If the pure simulation of the input to a halt decider would
>>>> never halt then the halt decider correctly decides that this input
>>>> does not halt.
>>>>
>>>> A computer scientist would understand these things.
>>>
>>> It would appear that you ignored (and cut) all the actual points in
>>> my post.
>>>
>>> Why don't we simplify things a bit. When Ĥ ⟨Ĥ⟩ is called, how does Ĥ
>>> determine that its input describes itself? You claim this is done by
>>> string comparisons, but which strings are being compared? The only
>>> string Ĥ has access to its input string. What does it compare this
>>> string with?
>>>
>>> André
>>>
>>
>> So far I have not gotten to any point of closure on anything that I
>> have said. I must insist on points of closure for continued dialogue.
>>
>> Do you agree that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>> never halt?
>
> Of course I don't, since that claim is simply false.
>
> Now why don't you actually answer the question I asked?
>
> André
>

Showing how the Linz Ĥ can be correctly decided as non-halting

Revised Linz H halt deciding criteria (My criteria Ben's notation)
H.q0 wM w ⊢* H.qy iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn iff UTM(wM, w) does not halt

For simplicity we will refer to the copy of Linz H at Ĥ.qx embedded_H.
embedded_H correctly determines that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

Simplified syntax adapted from bottom of page 319:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

If embedded_H would never stop simulating its input ⟨Ĥ⟩ ⟨Ĥ⟩
this input would never reach a final state and stop running.

These steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...

computation that halts
....the Turing machine will halt whenever it enters a final state
(Linz:1990:234)

That the pure simulation of an input would never reaches its final state
conclusively proves that this input specifies a non-halting computation.

This proves that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H maps to Ĥ.qn

Peter Linz HP Proof
https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 1/3/22 9:27 PM, olcott wrote:
> On 12/31/2021 7:37 PM, André G. Isaak wrote:
>> On 2021-12-31 18:17, olcott wrote:
>>> On 12/31/2021 7:11 PM, André G. Isaak wrote:
>>>> On 2021-12-31 17:05, olcott wrote:
>>>>> On 12/31/2021 5:33 PM, André G. Isaak wrote:
>>>>>> On 2021-12-31 16:02, olcott wrote:
>>>>>>> On 12/31/2021 4:06 PM, André G. Isaak wrote:
>>>>>
>>>>>>> An actual computer scientist will understand that embedded_H does
>>>>>>> compute the mapping from these inputs finite strings ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>> this final state Ĥ.qn on the basis that the actual input would
>>>>>>> never halt.
>>>>>>
>>>>>> You're not really in a position to state what an actual computer
>>>>>> scientist would understand. Only an actual computer scientist can
>>>>>> do that.
>>>>>>
>>>>>
>>>>> It is a self-evident truth that:
>>>>> (a) The pure simulation of the Turing machine description of a
>>>>> machine is computationally equivalent to the direct execution of
>>>>> this machine.
>>>>>
>>>>> (b) The pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never halt.
>>>>>
>>>>> (c) If the pure simulation of the input to a halt decider would
>>>>> never halt then the halt decider correctly decides that this input
>>>>> does not halt.
>>>>>
>>>>> A computer scientist would understand these things.
>>>>
>>>> It would appear that you ignored (and cut) all the actual points in
>>>> my post.
>>>>
>>>> Why don't we simplify things a bit. When Ĥ ⟨Ĥ⟩ is called, how does Ĥ
>>>> determine that its input describes itself? You claim this is done by
>>>> string comparisons, but which strings are being compared? The only
>>>> string Ĥ has access to its input string. What does it compare this
>>>> string with?
>>>>
>>>> André
>>>>
>>>
>>> So far I have not gotten to any point of closure on anything that I
>>> have said. I must insist on points of closure for continued dialogue.
>>>
>>> Do you agree that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>> never halt?
>>
>> Of course I don't, since that claim is simply false.
>>
>> Now why don't you actually answer the question I asked?
>>
>> André
>>
>
>
> Showing how the Linz Ĥ can be correctly decided as non-halting
>
> Revised Linz H halt deciding criteria (My criteria Ben's notation)
> H.q0 wM w ⊢* H.qy iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn iff UTM(wM, w) does not halt
>
> For simplicity we will refer to the copy of Linz H at Ĥ.qx embedded_H.
> embedded_H correctly determines that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

Really, no need for a new name, just gives you cover for making H and
embedded_H seem like they could do something different, which they can't

>
> Simplified syntax adapted from bottom of page 319:
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> If embedded_H would never stop simulating its input ⟨Ĥ⟩ ⟨Ĥ⟩
> this input would never reach a final state and stop running.

RETHORITCAL QUESTION, so by this do you mean it WON'T Halt.

Remember, H^ is based on the H that you claim is getting the right
answer, not the 'rethorical' embedded_H that you are thinking of but
don't actually mean H to be.

Also remember, Halting is defined by the actually running of the
machine, or equivalently by putting the input into a REAL UTM, that
means one that NEVER stops.

>
> These steps would keep repeating:
> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...

Only if H actually never aborts is simulation.

>
> computation that halts
> ...the Turing machine will halt whenever it enters a final state
> (Linz:1990:234)
>
> That the pure simulation of an input would never reaches its final state
> conclusively proves that this input specifies a non-halting computation.

Only if H never aborts its simulation.

>
> This proves that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H maps to Ĥ.qn

But that is a different H with a different H^. If you H actually does
abort then your looking at the system built with a H that doesn't is
incorrect.

Also, you are ASSUMING that H/embedded_H is correct,

In the beginning you were talking about Hn that doesn't abort, ans
showed that Hn^(<Hn^> doesn't halt, but failed to point out that the
problem that Hn(<Hn^>,<Hn^>) never gives an answer

Then you start to talk about an Ha that DOES abort an go to H.Qn, but
unfortunately for you when H -> H.Qn, then so does H^ -> H^.Qn and
Halts, so we have that since Ha(<Ha^>) -> H.Qn we can show that it is
true that Ha^(<Ha^>) also goes to H^.Qn and Halts, so Ha was wrong.

You confuse the fact that at any give time you only can have H be ONE
machine (either Ha or Hn) and then H^ is the copy based on it.

This means that your logic on Hn does carry over to your Ha case.

FAIL

>
> Peter Linz HP Proof
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>

It seems YOU are the one stuck in the infinite loop.

Forty Six version of this and you are STILL making exactly the same sort
of mistakes.