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
Subject: Re: Two dozen people were simply wrong --- Try to prove otherwise
Date: Thu, 30 May 2024 21:37:23 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3b9kj$2im02$1@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>
 <v39agi$1jiql$1@dont-email.me> <v39v3h$1mtd9$5@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:23 -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: <v39v3h$1mtd9$5@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8530
Lines: 177

On 5/30/24 9:31 AM, olcott wrote:
> On 5/30/2024 2:40 AM, Mikko wrote:
>> 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. 
> 
> That is what I said.

Note, the string doesn't DIRECTLY specify behavior, but only indirectly 
as a description/representation of the Turing Mach

> 
>> 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. 
> 
> Yes that is also correct.



> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> When embedded_H is a UTM then it never halts.

But it isn't unless H is also a UTM, and then H never returns.

You like to keep returning to that deception.

> 
> When embedded_H is a simulating halt decider then its correctly
> simulated input never reaches its own simulated final state of
> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
> input as non-halting.

Except that isn't what the question is, the question is what the actual 
behavior of the machine described, or equivalently, the simulation by a 
REAL UTM (one that never stops till done).

As has been shown, H / embedded_H can't be that and answer, so either 
your embedded_H needs to answer about a simulation done by a different 
machine (which seems beyond your understanding) or you just don't have a 
valid criteria to use.

> 
> 
>> 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.
>>
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========