Path: ...!weretis.net!feeder9.news.weretis.net!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 17:21:00 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v32tfs$29dee$1@i2pn2.org>
References: <v2nsvh$1rd65$2@dont-email.me> <v2u2uf$23vgp$4@i2pn2.org>
 <v2u5a0$349br$2@dont-email.me> <v2u6if$23vgo$3@i2pn2.org>
 <v2u7fj$38fjo$1@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 27 May 2024 21:21:00 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2405838"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v32nsa$6fo3$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8275
Lines: 148

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, 
(built from the specific H it is to refute) and NOT your "Template" D, 
that changes itself based on who looks at it.

Then we need that H^ / D has a COPY of H, not using the same H (which is 
one of the sources of your biggest problem) as they are a seperate 
machine from the decider H, and thus have seperate "code bases", as they 
are separate machines. (in equivalency space, you might be able to get 
away with the sharing if it doesn't affect the operation of the two 
machines, but in your case it does, so it makes them non-equivalent)

The smaller problem is that if H was the equivalent of a Turing Machine, 
then you could actually make that required copy of it to put in H^/D, 
and all copies will give the exact same answer for the same input. This 
is a fundamental property of Turing Machines

> 
>> in which case we have previously shown that H (H^) (H^) will never 
>> answer, and thus isn't a correct decider. 
> 
> I include UTM embedded_H and adapted UTM embedded_H so that every
> simulation of 1 to ∞ steps can be reviewed. At this point embedded_H
> is not a decider, it either either a UTM or a UTM that has been
> adapted to stop simulating after a finite number of steps.

And thus you have LIED that D was built by the Linz or Sipser template 
that required an EXACT copy of H in H^.

> 
> As you already acknowledged neither UTM embedded_H nor ⟨Ĥ⟩ ⟨Ĥ⟩
> correctly simulated by UTM embedded_H would ever halt.

Right, *IF* H and embedded_H are BOTH UTMs (and it one is the other MUST 
be or you have lied about H^ / D being built by the provided template) 
then BOTH H (H^) (H^) and H^ (H^) are non-halting machines, but then H 
never gives that answer, so it isn't a correct decider.

> 
> The key point that you keep trying to avoid by perpetual
> attempts to change the subject is that when we know that
> 
> when ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H for an
> infinite number of steps never halts that less than an
> infinite number of steps will not halt either.

Right, but change H / embedded_H to not be that UTM, and you now have a 
DIFFERENT H^, so the answer for this new H^ can be different.

> 
> In other words NO MATTER WHAT ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
> by embedded_H DOES NOT HALT.
> 

Nope. That was only shown for the H^ build on a H that was a UTM.

You confuse yourself by trying to give all the input the same name, in 
an attempt to confuse the reader, but you get yourself too.