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: Fri, 24 May 2024 18:18:03 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2r3mr$1vblq$8@i2pn2.org>
References: <v2nsvh$1rd65$2@dont-email.me> <v2oreb$1tsmo$4@i2pn2.org>
 <v2pr71$29rhj$2@dont-email.me> <v2psq3$1v3p0$2@i2pn2.org>
 <v2qr6n$2fesr$1@dont-email.me> <v2qvb5$1vblp$4@i2pn2.org>
 <v2r17j$2ge4f$2@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 22:18:03 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2076346"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v2r17j$2ge4f$2@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8371
Lines: 164

On 5/24/24 5:35 PM, olcott wrote:
> On 5/24/2024 4:03 PM, Richard Damon wrote:
>> On 5/24/24 3:52 PM, olcott wrote:
>>> On 5/24/2024 6:14 AM, Richard Damon wrote:
>>>> On 5/24/24 6:46 AM, Fred. Zwarts wrote:
>>>>> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>>>>>> 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?
>>>>>>
>>>>>> 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 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"?
>>>>>>
>>>>>> 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 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> If olcott wants to be closer to the Linz or Sipser rules, he could 
>>>>> do so with a small modification: use different names for H. Use H1 
>>>>> when called by main and use H2 when called by D. H1 and H2 are not 
>>>>> required to be exact copies of each other, but only to be 
>>>>> functionally equivalent. By doing so, a lot of useless discussions 
>>>>> could be avoided.
>>>>
>>>> Yes, he could, but when it was proposed that we make D call its own 
>>>> identical copy of H, he rejected it saying it wasn't allowed.
>>>>
>>>> Of course, the reason it isn't allowed is that it makes his method 
>>>> of detecting that D calls (a copy of) H not work and his whole 
>>>> method falls apart, as his H just never answers.
>>>
>>> A copy of D crashes the libx86emu emulator unless the copy
>>> is very small having less code than the full D.
>>>
>>
>> That is very strange, unless you have configured the emulator for very 
>> small memory space, and that just shows a limitation to your 
>> computation implementation, so, you are just admitting that you tools 
>> can't handle the logic system.
>>
> 
> No need for that once we are have mutual agreement on H/D
> getting mutual agreement on embedded_H / ⟨Ĥ⟩ is isomorphic.

But sincd they aren't, we can't.

First note, nothing you have actually implemented has an "embedded_H" as 
your D just calls H and not a copy of it.

> 
> I can explicitly show that your idea of D correctly simulated
> by pure function H IS WRONG.

The do so.

> 
> Once you agree to these easily verified facts we can move on to
> the Linz proof having the acceptance of the H/D proof as the basis
> for moving on.

But until you actually post agreement to the terms, we can't move to there.

> 
> If you want to keep insisting that D correctly simulated by pure
> function H requires the x86 instructions of D or H to be incorrectly
> emulated or emulated in the wrong order then we must get though this
> first.

I never said that, so you are proving yourself to be a LIAR, which is 
why I am insisting on your agreement to a precise definition, with an 
acceptance of the consequence of the terms.

Try to show where I said H needs to "incorrectly" simulate the input. I 
am saying that to make the conclusion you want to make, the simulaiton 
needs to meet all of your requirements, PLUS the fact that it must 
continue to seeing the final state, or never halt.

If THAT simulation never halts, then you can conclude that the input 
doesn't halt.

> 
> Paraphrase:
> Your latest ruse is that a non-halting computation must simulated
> to its non existent end.
> 

Which is, like typical for you, paraphrased poorly due to you lack of 
understanding. What I am actually saying is that to show that a 
computation being simulated is non-halting, you must show that the 
correct simulation, of that exact input,  which doesn't stop until it 
reaches a final state, would be non-haltign.