Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: =?UTF-8?Q?Re=3A_A_simulating_halt_decider_applied_to_the_The_Peter_?=
 =?UTF-8?Q?Linz_Turing_Machine_description_=E2=9F=A8=C4=A4=E2=9F=A9_--_key_d?=
 =?UTF-8?Q?etails?=
Date: Mon, 3 Jun 2024 20:56:12 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3lonc$2uv04$4@i2pn2.org>
References: <v2nsvh$1rd65$2@dont-email.me> <v331mf$84p2$1@dont-email.me>
 <v332ci$29def$2@i2pn2.org> <v33790$8u5p$1@dont-email.me>
 <v337r0$29dee$2@i2pn2.org> <v338c5$94g8$1@dont-email.me>
 <v339kr$29dee$3@i2pn2.org> <v33aj7$9f3u$1@dont-email.me>
 <v33bo5$29def$4@i2pn2.org> <v33dt7$dlnv$1@dont-email.me>
 <v33f6d$29dee$4@i2pn2.org> <v33g9j$e3ug$1@dont-email.me>
 <v33gss$29def$6@i2pn2.org> <v33hbf$e6qn$1@dont-email.me>
 <v34fg0$2bb65$2@i2pn2.org> <v36pgt$12lh7$1@dont-email.me>
 <v379la$159q4$2@dont-email.me> <v398hu$1j7to$1@dont-email.me>
 <v39ue9$1mtd9$3@dont-email.me> <v3chls$280e0$1@dont-email.me>
 <v3cqnm$29gdk$1@dont-email.me> <v3ek0l$2maau$1@dont-email.me>
 <v3fbme$2qsgd$1@dont-email.me> <v3fqkp$2o13h$7@i2pn2.org>
 <v3fsm0$2uah1$1@dont-email.me> <v3h7pv$38up4$1@dont-email.me>
 <v3hrlk$3bkv5$3@dont-email.me> <v3jt7u$3qf1g$1@dont-email.me>
 <v3kdbg$3stk9$4@dont-email.me> <v3kmo4$3umuf$1@dont-email.me>
 <cc67f0766be6e157114996e37910f7d60564e2c5.camel@gmail.com>
 <v3l20k$5d3$8@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 4 Jun 2024 00:56:12 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3111940"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v3l20k$5d3$8@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8575
Lines: 148

On 6/3/24 2:28 PM, olcott wrote:
> On 6/3/2024 10:27 AM, wij wrote:
>> On Mon, 2024-06-03 at 18:16 +0300, Mikko wrote:
>>> On 2024-06-03 12:36:00 +0000, olcott said:
>>>
>>>> On 6/3/2024 3:01 AM, Mikko wrote:
>>>>> On 2024-06-02 13:21:56 +0000, olcott said:
>>>>>
>>>>>> On 6/2/2024 2:42 AM, Mikko wrote:
>>>>>>> On 2024-06-01 19:26:55 +0000, olcott said:
>>>>>>>
>>>>>>>> On 6/1/2024 1:52 PM, joes wrote:
>>>>>>>>> Am Sat, 01 Jun 2024 09:37:01 -0500 schrieb olcott:
>>>>>>>>>> On 6/1/2024 2:52 AM, Mikko wrote:
>>>>>>>>>>> On 2024-05-31 15:35:18 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>>>> *A quick summary of the reasoning provided below*
>>>>>>>>>>>> The LHS is behavior that embedded_H is allowed to report on.
>>>>>>>>>>> There is no restrictions on what embedded_H is allowed to 
>>>>>>>>>>> report on.
>>>>>>>>>>
>>>>>>>>>> embedded_H is only allowed to report on the behavior that its 
>>>>>>>>>> finite
>>>>>>>>>> string Turing Machine Description specifies to a UTM.
>>>>>>>>>>
>>>>>>>>>> embedded_H <is> a UTM except that it stops simulating and reports
>>>>>>>>>> non-halting as soon as it correctly recognizes a non-halting 
>>>>>>>>>> behavior
>>>>>>>>>> pattern that is specified by its input.
>>>>>>>>> "Except". So it is not an UTM.
>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>>>>>>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>> (g) goto (d)
>>>>>>>>>>
>>>>>>>>>> embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because 
>>>>>>>>>> inputs can
>>>>>>>>>> only be finite strings and Ĥ is not a finite string. This means
>>>>>>>>>> that embedded_H is not allowed to report on its own actual 
>>>>>>>>>> behavior.
>>>>>>>>> I can't read that notation. What is H^ and what does it look like?
>>>>>>>>>
>>>>>>>>
>>>>>>>> *Here is the whole Linz proof*
>>>>>>>> I simplified the Linz notation at the bottom of page 2 of the 
>>>>>>>> proof.
>>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>
>>>>>>> You are right, that is a sufficient proof. You may change the 
>>>>>>> presentation
>>>>>>> but then you must prove that your presentation is equivalent to 
>>>>>>> Linz'.
>>>>>>
>>>>>> The proof was removed until Joe could understand what Linz was saying
>>>>>> Here is my actual proof.
>>>>>
>>>>> Linz' proof is Linz' proof, not yours.
>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> The above does not say what Linz said and hardly anything else, 
>>>>> either.
>>>>> It is not a sentence. If you remove the second last or the last line
>>>>> or add some conjunction between them and add a point to the end then
>>>>> you would have a sentence.
>>>>>
>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> (g) goto (d)
>>>>>>
>>>>>> Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ derives a different result than
>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> Irrelevant as embedded_H is not a part of Linz' proof. The part
>>>>> of Linz' Ĥ that corresponds to your embedded_H does produce the
>>>>> same result as Linz H does.
>>>>>
>>>>
>>>> https://www.liarparadox.org/Linz_Proof.pdf top of page 3
>>>> Linz named his embedded_H "Ĥq0" and has input Wm Wm
>>>> because this is a second start state in the same machine
>>>> Ben agrees that the Linz notation is wrong.
>>>
>>> I don't know (and don't expect to find out with a reasonable effort)
>>> whay Linz uses the notation he uses. It does not really matter as
>>> the meaning is clear from the text. You may use a better notation if
>>> you know one but constructing a good notation is not easy. As a
>>> test case you may cosider pair of Turing machines that are otherwise
>>> identical but start at different states.
>>>
>>>>> Turns out that you can prove that the result produced by Linz' H is
>>>>> different from the result produced by linz' H. This is sufficient to
>>>>> prove that Linz' H does not exist.
>>>>>
>>>>>> This is because the in the latter case embedded_H must determine that
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly stop 
>>>>>> running
>>>>>> after 1 to ∞ steps of correct simulation. Thus (as we can all see)
>>>>>> embedded_H meets its abort simulation criteria.
>>>>>
>>>>> Those criteria are not mentioned in Linz' proof and are therefore
>>>>> irrelevant to it.
>>>>>
>>>>
>>>> They are not mentioned because like everyone else Linz rejects
>>>> the notion of a simulating halt decider out-of-hand without review.
>>>
>>> The topic is halt deciders, not simulating halt deciders. If a
>>> simulating halt decider is a halt decider then eerything that
>>> is true about all halt deciders is true about all simulating
>>> halt deciders. The proof that the set of halt deciders is empty
>>> clearly prves the the set of simulating halt deciders is a
>>> subset of an empty set (or the empty set, as there is only one).
>>>
>>>> When you look for "simulating halt decider" or
>>>> "simulating termination analyzer" you only find me.
>>>
>>> Apparently people do not find subsets of the empty set
>>> very interessting.
>>>
>>
>> I think this may be one major reason olcott keeps repeating his claim.
>>
> 
> We cannot move on to the mathematics of this while everyone lies about 
> the arithmetic of it.
> 
> DD correctly simulated by HH does not halt. After you acknowledge
> the truth of this then we can move on to the next step that depends
> on this step as its basis.
> 

Which has been proven wrong, and your repeating it just proves that you 
are an ignorant pathological liar with a reckless disregard for the 
truth, which you seem to just not understand what it is.