Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Can you see that D correctly simulated by H remains stuck in
 recursive simulation?
Date: Thu, 23 May 2024 22:06:38 -0500
Organization: A noiseless patient Spider
Lines: 244
Message-ID: <v2p07v$25aq3$1@dont-email.me>
References: <v2nsvh$1rd65$2@dont-email.me> <v2oreb$1tsmo$4@i2pn2.org>
 <v2otlq$24vfk$1@dont-email.me> <v2oupf$1tsmn$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 May 2024 05:06:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="853a48eea7a3e841565c364baea8e5bf";
	logging-data="2272067"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18x/9LlIbhQJwWICRmIgjTf"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:jo9RTn8lIHNMKrYha9arajhHE3Y=
Content-Language: en-US
In-Reply-To: <v2oupf$1tsmn$1@i2pn2.org>
Bytes: 10427

On 5/23/2024 9:41 PM, Richard Damon wrote:
> On 5/23/24 10:22 PM, olcott wrote:
>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>> On 5/23/24 1:04 PM, 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 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 every reviewer had a different notion of
>>>>     correct simulation that diverges from this notion.
>>>>
>>>>     A simulator is an x86 emulator that correctly emulates at least one
>>>>     of the x86 instructions of D in the order specified by the x86
>>>>     instructions of D.
>>>>
>>>>     This may include correctly emulating the x86 instructions of H in
>>>>     the order specified by the x86 instructions of H thus calling 
>>>> H(D,D)
>>>>     in recursive simulation.
>>>>
>>>> *Execution Trace*
>>>>     Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, 
>>>> and 03
>>>>     of D. This invokes H(D,D) again to repeat the process in endless
>>>>     recursive simulation.
>>>>
>>>
>>> Questions:
>>>
>>> By your definiton of "Correct Simulation", you do realize that you 
>>> have broken connection between the simulaiton not completing and the 
>>> program described by the input not halting?
>>>
>>
>> In other words you are requiring that the x86 instructions of D
>> (and possibly H) be simulated incorrectly and/or in the wrong order.
> 
> No, they must be simulated COMPLETELY.
> 

(a) *Clearly you are terrible at reading a spec*
(b) *non terminating computations cannot be simulated completely*

> That is the only simulation that Computation Theory recognises as 
> showing halting status.
> 

*Infinite loops need not be simulated completely to show a halt status*

> You should know that, so you are just showing you are deflecting.
> 

DUMB MISTAKE ON YOUR PART
*Infinite loops need not be simulated completely to show a halt status*

>>
>>> Also, you do realize that by your requirement on H just being a "pure 
>>> function" that does NOT say that you H qualified to be the 
>>> computational equivalent for a Turing Machine?
>>>
>>
>> That I require it to be a pure function
>> (a) Disallows you use of static local data.
>> (b) Does mean that H is Turing computable even if you don't understand 
>> this.
>>
> 
> Nope.
> 
> It is neither suffient or required.
> 

*So you don't even know what a spec is*

> Your H1 being claimed to be a "copy" but giving a different value is a 
> proof of the insufficiency.
> 

THAT IS OFF-TOPIC FOR THE SUBJECT OF THIS THREAD.

>>> That due to your "strange" definition of what D is, you are putting 
>>> yourself outside of the grounds of "Computation Theory", as that 
>>> deals with the behavior of specific PROGRAMS, and not the "Program 
>>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>>
>>
>> How you can fail to understand that this <is> such a template?
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> Nope, not a "template" as H (from which you built your embedded H) is a 
> SPEICIF (but arbitary) machine that meets that specification, and thus, 
> so is H^.
> 

Arbitrary MEANS template.

> You don't seem to understand the maning of the terms.
> 

You are the one the directly contradicted yourself
It cannot be {A SPECIFIC MACHINE} and {AN ARBITRARY MACHINE}

>>
>>> Also, your "templagte D" is NOT built per either the Linz or Sipser 
>>> rules, as both of those had D built with a COPY of H, which is one of 
>>> your problems with a "Pure Function" as the equivelent. You have 
>>> shown that your H fails to meet the requirements of a Turing Machine 
>>
>> This post is only talking about the above specified H, you keep
>> forgetting that.
> 
> Which my question are trying to confirm exactly what you means by that, 
> and that you understand the implications of it.
> 

My spec if clear and you clearly keep ignoring it.

> Clearly you don't.
> 
>>
>>> equivalent, as you can't (or it seems you can't) make equivalent 
>>> copies, where all copies always give the same answer for the same 
>>> inputs. This is a fundamental property of Turing Machines, which is 
>>> why just bing a "Pure Function" isn't good enough.
>>>
>>
>> For simulator H it is plenty good enough.
> 
> Nope.
> 

We know that simulation is Turing computable on the basis of UTMs

Are you going to try and get away with pretending that you don't know this?

>>
>>> These issus need to be handled or acknowledged, before agreement on 
>>> your question, as you have shown a history of taking a statement and 
>>> twisting it (perhaps not intentionally, but because you don't 
>>> understand what was being communicated) so we need to have a firm 
>>> understand of what you mean and evidence that you accept the 
>>> limititation causes by your altered definitions from the problem that 
>>> you initially claimed to have started on.
>>>
>>
>> You just claimed that you do not understand that the Linz example is a 
>> template. That does not seem like an honest mistake to me.
> 
> Linz STARTS from a templete, the ^ template (that he introduces later in 
> the proof), and then select a SINGLE (but arbitrary) decider H, and from 
> that he builds (with his template) a single input to give to that 
> decider H^.
> 

SINGLE and arbitrary are mutually exclusive.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
========== REMAINDER OF ARTICLE TRUNCATED ==========