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: Two dozen people were simply wrong --- Try to prove otherwise
Date: Wed, 29 May 2024 20:09:05 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v38g31$2foi0$11@i2pn2.org>
References: <v3501h$lpnh$1@dont-email.me> <v362eu$2d367$3@i2pn2.org>
 <v363js$vg63$2@dont-email.me> <v36803$2d368$3@i2pn2.org>
 <v368je$100kd$3@dont-email.me> <v373mr$2d367$5@i2pn2.org>
 <v37bpa$15n0b$1@dont-email.me> <v37i9p$lls$1@news.muc.de>
 <87y17smqnq.fsf@bsb.me.uk> <v37sap$18mfo$1@dont-email.me>
 <v38eq4$2foi0$1@i2pn2.org> <v38fe0$1bndb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 30 May 2024 00:09:05 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2613824"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v38fe0$1bndb$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4359
Lines: 84

On 5/29/24 7:57 PM, olcott wrote:
> On 5/29/2024 6:47 PM, Richard Damon wrote:
>> On 5/29/24 2:31 PM, olcott wrote:
>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>
>>>>> How about a bit of respect?  Mike specifically asked you not to 
>>>>> cite his
>>>>> name as a back up for your points.  Why do you keep doing it?
>>>>
>>>> He does it to try to rope more people in.  It's the same ploy as
>>>> insulting people by name.  It's hard to ignore being maligned in public
>>>> by a fool.
>>>>
>>>
>>> *Thanks for validating my simplified encoding of the Linz*
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> I really did believe that Ben Bacarisse was lying when I said it.
>>>
>>> At the time I was talking about the easily verified fact of the actual
>>> execution trace of fully operational code and everyone was denying the
>>> easily verified facts.
>>>
>>> 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       }
>>>
>>> It turns out that two dozen people are easily proven wrong when
>>> they claimed that the correct simulation of the input to H(D,D)
>>> is the behavior of int main() { D(D); }
>>>
>>
>> How is that?
>>
>>
>>> When D is correctly simulated by H using an x86 emulator the only
>>> way that the emulated D can reach its own emulated final state
>>> at line 06 and halt is
>>> (a) The x86 machine code of D is emulated incorrectly
>>> (b) The x86 machine code of D is emulated in the wrong order
>>>
>>
>> Which isn't a "Correct Simulation" by the definition that allow the 
>> relating of a "Simulation" to the behavior of an input.
>>
> 
> Right the execution trace of D simulated by pure function H using
> an x86 emulator must show that D cannot possibly reach its own
> simulated final state and halt or the simulation of the machine
> language of D is incorrect or in the wrong order.

So, you aren't going to resolve the question but just keep up with your 
contradiction that H is simulating a template (that doesn't HAVE any 
instrucitons of H in it) but also DOES simulate those non-existance 
instructions by LYING about what it does and simulating a SPECIFIC 
instance that it LIES behaves just like DIFFERENT specific instatces.

> 
> *FULLY OPERATIONAL CODE DOES SHOW THIS*

Nope

> 
> I may not look at any of you other replies until after this
> one is fully resolved.
> 

Good for you, just prove your reckless disregard for the truth that is 
going to land you in Gehenna.