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: Olcott was simply wrong --- Try to prove otherwise
Date: Thu, 30 May 2024 21:37:25 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3b9kl$2im02$2@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>
 <v38g31$2foi0$11@i2pn2.org> <v38gi5$1bndb$3@dont-email.me>
 <v38ici$2fohv$2@i2pn2.org> <v38j17$1c8ir$2@dont-email.me>
 <v38jgo$2foi0$14@i2pn2.org> <v38jv9$1c8ir$4@dont-email.me>
 <v38kh7$2foi0$15@i2pn2.org> <v38lsl$1ggjs$1@dont-email.me>
 <v38o71$2foi0$17@i2pn2.org> <v38ogh$1grj4$1@dont-email.me>
 <v38pr0$2fohv$6@i2pn2.org> <v38thu$1hf5c$2@dont-email.me>
 <v39o04$2h667$1@i2pn2.org> <v3a11j$1ni4n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 31 May 2024 01:37:25 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2709506"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v3a11j$1ni4n$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 13815
Lines: 289

On 5/30/24 10:04 AM, olcott wrote:
> On 5/30/2024 6:30 AM, Richard Damon wrote:
>> On 5/29/24 11:58 PM, olcott wrote:
>>> On 5/29/2024 9:55 PM, Richard Damon wrote:
>>>> On 5/29/24 10:32 PM, olcott wrote:
>>>>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>>>>> On 5/29/24 9:48 PM, olcott wrote:
>>>>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will give you the benefit of the doubt and call that an 
>>>>>>>>>>>>> honest
>>>>>>>>>>>>> misunderstanding. I have much more empathy for you now that 
>>>>>>>>>>>>> I found
>>>>>>>>>>>>> that Linz really did say words that you could construe as 
>>>>>>>>>>>>> you did.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>>>>>>>> where D is correctly simulated by pure simulator H or pure 
>>>>>>>>>>>>> function
>>>>>>>>>>>>> H never has any D reach its own simulated final state and 
>>>>>>>>>>>>> halt.
>>>>>>>>>>>>
>>>>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the 
>>>>>>>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>>>>>>>
>>>>>>>>>>>> This seems to be your blind spot.
>>>>>>>>>>>
>>>>>>>>>>> ∃H  ∈ Turing_Machines
>>>>>>>>>>> ∀x  ∈ Turing_Machines_Descriptions
>>>>>>>>>>> ∀y  ∈ Finite_Strings
>>>>>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>>>>>
>>>>>>>>>>> Not really the above formalization does not can cannot
>>>>>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then what is x representing?
>>>>>>>>>
>>>>>>>>> x <is> a finite string Turing machine description that 
>>>>>>>>> SPECIFIES behavior. The term: "representing" is inaccurate.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>>>>>
>>>>>>>
>>>>>>> If we assume that a decider takes an actual Turing machine as its
>>>>>>> input that is correct otherwise that is one level of indirection
>>>>>>> away from what we are really looking at.
>>>>>>>
>>>>>>> The people have perpetuated this mistake for many decades never
>>>>>>> actually made it not a mistake.
>>>>>>>
>>>>>>
>>>>>> You need to define what you mean by "Indirection", because you 
>>>>>> aren't using it in the normal manner.
>>>>>>
>>>>>
>>>>> I have conclusively proven that the behavior of the correct
>>>>> simulation of the x86 code of D by pure function H has
>>>>> different behavior than the direct execution of D(D).
>>>>
>>>> But the question isn't about the "Correcgt Simulation" and 
>>>> especially based on YOUR definition. So you haven't proven ANYTHING 
>>>> about the question except that you don't understand it and are just 
>>>> an ignorant pathological liar with a reckless disregard for the trutn.
>>>>
>>>> You are just showing that you have successfully brainwashed yourself 
>>>> into beleiving your own lies.
>>>>
>>>
>>> typedef int (*ptr)();  // ptr is pointer to int function in C
========== REMAINDER OF ARTICLE TRUNCATED ==========