Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
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?=
Date: Mon, 27 May 2024 20:17:36 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v337r0$29dee$2@i2pn2.org>
References: <v2nsvh$1rd65$2@dont-email.me> <v2v79q$25ell$2@i2pn2.org>
 <v2vg1g$3e8pb$4@dont-email.me> <v2vo5h$26570$3@i2pn2.org>
 <v2vpt6$3g0m3$3@dont-email.me> <v2vqou$26570$5@i2pn2.org>
 <v2vrcl$3gakv$1@dont-email.me> <v2vslp$26570$6@i2pn2.org>
 <v301m6$3hcgb$1@dont-email.me> <v305j9$26571$1@i2pn2.org>
 <v30e5l$3lerc$1@dont-email.me> <v30fbr$26570$9@i2pn2.org>
 <v30hiq$3lv80$1@dont-email.me> <v30jb5$26571$2@i2pn2.org>
 <v30pr8$3r67p$1@dont-email.me> <v30rvv$3riij$1@dont-email.me>
 <v30t8u$26571$6@i2pn2.org> <v30u04$3rour$1@dont-email.me>
 <v30upc$26571$7@i2pn2.org> <v30vp3$3s4od$1@dont-email.me>
 <v321o0$28n58$1@i2pn2.org> <v3255k$2pkb$2@dont-email.me>
 <v326fd$28n59$2@i2pn2.org> <v327h8$3a17$1@dont-email.me>
 <v328l1$28n58$2@i2pn2.org> <v329t8$3mh0$2@dont-email.me>
 <v32ait$28n58$4@i2pn2.org> <v32bvc$48pj$1@dont-email.me>
 <v32cko$2937i$1@i2pn2.org> <v32nsa$6fo3$1@dont-email.me>
 <v32tfs$29dee$1@i2pn2.org> <v331mf$84p2$1@dont-email.me>
 <v332ci$29def$2@i2pn2.org> <v33790$8u5p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 28 May 2024 00:17:36 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2405838"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v33790$8u5p$1@dont-email.me>
Bytes: 7468
Lines: 134

On 5/27/24 8:08 PM, olcott wrote:
> On 5/27/2024 5:44 PM, Richard Damon wrote:
>> On 5/27/24 6:32 PM, olcott wrote:
>>> On 5/27/2024 4:21 PM, Richard Damon wrote:
>>>> On 5/27/24 3:45 PM, olcott wrote:
>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote:
>>>>>> On 5/27/24 12:22 PM, olcott wrote:
>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote:
>>>>>>>> On 5/27/24 11:46 AM, olcott wrote:
>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote:
>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>>>>>>>> 00       int H(ptr p, ptr i);
>>>>>>>>> 01       int D(ptr p)
>>>>>>>>> 02       {
>>>>>>>>> 03         int Halt_Status = H(p, p);
>>>>>>>>> 04         if (Halt_Status)
>>>>>>>>> 05           HERE: goto HERE;
>>>>>>>>> 06         return Halt_Status;
>>>>>>>>> 07       }
>>>>>>>>> 08
>>>>>>>>> 09       int main()
>>>>>>>>> 10       {
>>>>>>>>> 11         H(D,D);
>>>>>>>>> 12         return 0;
>>>>>>>>> 13       }
>>>>>>>>>
>>>>>>>>> The above template refers to an infinite set of H/D pairs where 
>>>>>>>>> D is
>>>>>>>>> correctly simulated by either pure simulator H or pure function 
>>>>>>>>> H. This
>>>>>>>>> was done because many reviewers used the shell game ploy to 
>>>>>>>>> endlessly
>>>>>>>>> switch which H/D pair was being referred to.
>>>>>>>>>
>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>>     This is provided because many reviewers had a different 
>>>>>>>>> notion of
>>>>>>>>>     correct simulation that diverges from this notion.
>>>>>>>>>
>>>>>>>>>     A simulator is an x86 emulator that correctly emulates 1 to 
>>>>>>>>> N of the
>>>>>>>>>     x86 instructions of D in the order specified by the x86 
>>>>>>>>> instructions
>>>>>>>>>     of D. This may include M recursive emulations of H 
>>>>>>>>> emulating itself
>>>>>>>>>     emulating D.
>>>>>>>>
>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define what 
>>>>>>>> a call H means (as it could be any of the infinite set of Hs 
>>>>>>>> that you can instantiate the template on)?
>>>>>>>>
>>>>>>>
>>>>>>> *Somehow we got off track of the subject of this thread*
>>>>>>
>>>>>> I note that YOU keep on switching between your C program and 
>>>>>> Turing Machines.
>>>>>>
>>>>>> Note, per the implications that you implicitly agreed to (by not 
>>>>>> even trying to refute) the two systems are NOT equivalents of each 
>>>>>> other.
>>>>>>
>>>>>
>>>>> (1) I think you are wrong. I have not seen any of your
>>>>> reasoning that was not anchored in false assumptions.
>>>>> Your make fake rebuttal is to change the subject.
>>>>>
>>>>> (2) It does not matter my proof is anchored in the Linz
>>>>> proof and the H/D pairs are only used to have a 100% concrete
>>>>> basis to perfectly anchor things such as the correct meaning
>>>>> of D correctly simulated by H so that people cannot get away
>>>>> with claiming that an incorrect simulation is correct.
>>>>>
>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY SIMULATED 
>>>>> BY H.
>>>>> One cannot simply ignore the pathological relationship between H 
>>>>> and D.
>>>>>
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>>   Ĥ copies its own Turing machine description: ⟨Ĥ⟩
>>>>>>>   then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>>>>>>>
>>>>>>> For the purposes of the above analysis we hypothesize that
>>>>>>> embedded_H is either a UTM or a UTM that has been adapted
>>>>>>> to stop simulating after a finite number of steps of simulation.
>>>>>>
>>>>>> And what you do mean by that?
>>>>>>
>>>>>> Do you hypothesize that the original H was just a pure UTM,
>>>>>
>>>>> The original proof does not consider the notion of a simulating
>>>>> halt decider so I have to begin the proof at an earlier stage
>>>>> than any definition of H.
>>>>
>>>> The biggest problem is that the input to the Turing machine decider 
>>>> H is the description of a Turing Machine H^, which is a SPECIFIC 
>>>> machine, 
>>>
>>> When you say "specific machine" you don't mean anything like a
>>> 100% completely specified sequence of state transitions encoded
>>> as a single unique finite string.
>>
>> Mostly.
>>
>> There doesn't need to be a unique finite string, but it is a 100% 
>> completely specified state transition/tape operation table.
>>
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> In other words Linz did not prove that there are no set
> of state transitions specified by ⊢* that derives the
> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
> 
> He only said there there is one specific machine that
> gets the wrong answer.
> 

He STARTS with a proof that one specific (but arbitrary) machine gets 
the wrong answer.

Then he shows that the same proof can be applied to ANY such machine 
(becaue the proof didn't depend on any specific details of the machine, 
just the general properties of that machine)

I guess you don't understand how to do categorical proofs.