Path: ...!news-out.netnews.com!s1-1.netnews.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!nntp.club.cc.cmu.edu!news.nk.ca!rocksolid2!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 21:24:21 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v33bo5$29def$4@i2pn2.org>
References: <v2nsvh$1rd65$2@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>
 <v337r0$29dee$2@i2pn2.org> <v338c5$94g8$1@dont-email.me>
 <v339kr$29dee$3@i2pn2.org> <v33aj7$9f3u$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 01:24:22 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2405839"; 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: <v33aj7$9f3u$1@dont-email.me>
X-Received-Bytes: 11751
Bytes: 11922
Lines: 253

On 5/27/24 9:04 PM, olcott wrote:
> On 5/27/2024 7:48 PM, Richard Damon wrote:
>> On 5/27/24 8:26 PM, olcott wrote:
>>> On 5/27/2024 7:17 PM, Richard Damon wrote:
>>>> 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.
>>>>
>>>
>>> I totally do. Can you please write down the
>>> "completely specified state transition/tape operation table."
>>> of this specific (thus uniquely identifiable) machine I would
>>> really like to see it.
>>>
>>
>> But it was proven that no such machine exists!
>>
>> Remember, the proof starts with the hypothetical that such a machine 
>> exists. Such a machine WOULD HAVE a completely specified state 
>> transition/tape operation table.
>>
> 
> That is not what you said.
>  >>>>> There doesn't need to be a unique finite string, but it is a 100%
>  >>>>> completely specified state transition/tape operation table.
> 
> "a 100% completely specified state transition/tape operation table"
> of a non-existent machine.

========== REMAINDER OF ARTICLE TRUNCATED ==========