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 22:24:51 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v38o1j$2fohv$3@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> <v38l89$1gdia$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 02:24:51 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2613823"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v38l89$1gdia$1@dont-email.me>
Bytes: 6871
Lines: 129

On 5/29/24 9:37 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.
>>
> 
> That never has been the way that it has ever actually worked.
> 

You have a source for that?

Read the DEFINITION of Halting, it talks about THE MACHINE.

Read the DEFINITION of the Halting Problem, it asks about THE MACHINE 
described by the input.

So, yes, it has ALWAYS been the machine,