Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise
Date: Wed, 29 May 2024 19:59:19 -0500
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <v38j17$1c8ir$2@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 30 May 2024 02:59:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0a722b73a14c6c7bef786c05822a9348";
	logging-data="1450587"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18pVw6Ko7v8DI8I5LWADLL9"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LOknoJ8JACojcL+ntMrdtQ0civ4=
Content-Language: en-US
In-Reply-To: <v38ici$2fohv$2@i2pn2.org>
Bytes: 5617

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.


-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer