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,sci.logic
Subject: Re: Can you see that D correctly simulated by H remains stuck in
 recursive simulation?
Date: Thu, 23 May 2024 22:41:51 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2oupf$1tsmn$1@i2pn2.org>
References: <v2nsvh$1rd65$2@dont-email.me> <v2oreb$1tsmo$4@i2pn2.org>
 <v2otlq$24vfk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 May 2024 02:41:51 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2028247"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v2otlq$24vfk$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8064
Lines: 178

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.

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

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

> 
>> 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.

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

>> 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^.

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

> 
>> 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.

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.

> 
>> 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^.

That is NOT what you are doing, and the fact you can't see the 
difference shows your blindness to the truth,

> 
>> Of course, it also means that even if/when you get your agreement, you 
>> are no closer to your halting proof, as you have shown that you 
>> undestand that you conditions actually tell you NOTHING about the 
>> actual behavior of halting.
>>
> 
> 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.
> 


It isn't, it is a specific H applied to a specific input showwing that 
this specific machine could not have been a correct decider.

AFTER proving that for the specific machine that it was wrong, he can 
point out that because he made no assumption about the details of that 
H, we can select anew, ANY other machine as the H, and do the same 
thing, and thus NO machine that met the original specification, which 
includes ANY machine that would claim to be a Halt Decider, can actually 
be correct.

You just don't understand the logic of universal categorical logic, even 
though you try to claim you evented it under a different naem.

He proves for one SPECIFIC, but arbitary case, using the fact that it IS 
  a specific case (but not which one) and that he can show he can make 
an input that disproves that one, he can show that he can make an input 
for any decider that claims to meet the specification.

THAT is valid logic, but yours isn't, as all you show is that in your 
full set of deciders, each looking at a different input machine (since 
only machines have behavior, not templates) that particular decider gave 
up before getting the answer.
========== REMAINDER OF ARTICLE TRUNCATED ==========