Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise
Date: Thu, 30 May 2024 10:40:02 +0300
Organization: -
Lines: 119
Message-ID: <v39agi$1jiql$1@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> <v38j17$1c8ir$2@dont-email.me> <v38jgo$2foi0$14@i2pn2.org> <v38jv9$1c8ir$4@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 09:40:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="171987d8304ab438b73528bfdb9cffdc";
	logging-data="1690453"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18BZ41d6ergtxPhh2wX4zWW"
User-Agent: Unison/2.2
Cancel-Lock: sha1:anDmticAfFvfifngFBTrdKWjxIE=
Bytes: 6467

On 2024-05-30 01:15:21 +0000, olcott said:

> 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, x is a description of the Turing machine that specifies the behaviour
that H is required to report. The maning of x is that there is a universal
Turing machine that, when given x and y, simulates what the described
Turing machine does when given y. Therefore, you may reformulate the
requirement:

∀x  ∈ Turing_Machines_Descriptions
∀y  ∈ Finite_Strings
H(x,y) returns "yes" if UTM(x,y) halts and "no" otherwise.

-- 
Mikko