Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!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: Fri, 31 May 2024 07:16:14 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3cbhu$2k3ld$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>
 <v3b9kj$2im02$1@i2pn2.org> <v3bale$222n5$1@dont-email.me>
 <v3bbs2$2im01$1@i2pn2.org> <v3bcre$22a8n$1@dont-email.me>
 <v3bduk$2im01$2@i2pn2.org> <v3bedb$22f8h$1@dont-email.me>
 <v3bfbm$2im01$3@i2pn2.org> <v3bg39$22o6m$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 11:16:14 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2756269"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v3bg39$22o6m$1@dont-email.me>
Bytes: 9250
Lines: 191

On 5/30/24 11:27 PM, olcott wrote:
> On 5/30/2024 10:15 PM, Richard Damon wrote:
>> On 5/30/24 10:58 PM, olcott wrote:
>>> On 5/30/2024 9:51 PM, Richard Damon wrote:
>>>> On 5/30/24 10:32 PM, olcott wrote:
>>>>> On 5/30/2024 9:15 PM, Richard Damon wrote:
>>>>>> On 5/30/24 9:54 PM, olcott wrote:
>>>>>>> On 5/30/2024 8:37 PM, Richard Damon wrote:
>>>>>>>> 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:
>>>>>>>
>>>>>>>>>>> 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 string directly SPECIFIES behavior to a UTM or to
>>>>>>> any TM based on a UTM.
>>>>>>
>>>>>> By telling that UTM information about the state-transition table 
>>>>>> of the machine.
>>>>>>
>>>>>> Note, the description of the machine doesn't depend on the input 
>>>>>> given to it, so it needs to fully specify how to recreate the 
>>>>>> behavior of the machine for ALL inputs (an infinite number of 
>>>>>> them) in a finite string.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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).
>>>>>>>
>>>>>>> When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and 
>>>>>>> embedded_H is
>>>>>>> not a decider.
>>>>>>
>>>>>> Right, that is YOUR delema. You can't make H / embedded_H a UTM 
>>>>>> without making it not a decider, thus "Correct Simulation by H" 
>>>>>> can't be the answer, since H can't do both.
>>>>>>
>>>>>>>
>>>>>>> When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly 
>>>>>>> simulated
>>>>>>> by embedded_H never reaches its own simulated final state of 
>>>>>>> ⟨Ĥ.qn⟩ in
>>>>>>> any finite number of steps and after these finite steps embedded_H
>>>>>>> halts.
>>>>>>
>>>>>> Then its simulation isn't "correct" per the definitions that 
>>>>>> relate simulation to behavior.
>>>>>>
>>>>>
>>>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>>>> 00       int HH(ptr p, ptr i);
>>>>> 01       int DD(ptr p)
>>>>> 02       {
>>>>> 03         int Halt_Status = HH(p, p);
>>>>> 04         if (Halt_Status)
>>>>> 05           HERE: goto HERE;
>>>>> 06         return Halt_Status;
>>>>> 07       }
>>>>> 08
>>>>> 09       int main()
>>>>> 10       {
>>>>> 11         HH(DD,DD);
>>>>> 12         return 0;
>>>>> 13       }
>>>>>
>>>>> In other words you are insisting that every correct simulation
>>>>> of DD by HH must simulate the following x86 machine code of DD
>>>>> *incorrectly or in the incorrect order* because the following
>>>>> machine code proves that DD correctly simulated by HH cannot
>>>>> possibly reach its own machine address of 00001c47.
>>>>
>>>> It is "Incorrect" in that it is incomplete.
>>>>
>>>
>>> You already acknowledged that DD correctly simulated by pure simulator
>>> HH never reaches its own simulated final state so you already know that
>>> a complete simulation does not help.
>>
>> Sure does, since those are different cases.
>>
>> Maybe you don't understand what it means to give the DD that calls the 
>> HH that aborts to an actual True Simulator, verse making HH a pure 
>> simulator/
>>
> 
> *So you did not even try to show that you are not lying*

Sure I did. You just didn't understand it, because you just don't know 
what you are talking about.

> 
> Try and show how HH using an x86 emulator can correctly emulate
> the following x86 machine code such that DD reaches its own
> machine address 00001c47.

Why should I, since that isn't what I was saying.

> 
> I am thinking that you know you are lying, yet am open
> to proof that you not.

You claim the DD is non-halting. Non-Halting is a property of Programs, 
not "simulation" of programs, except for the case of a never-aborted 
simulation.

You have admitted that DD (DD) will halt when run, but what to try to 
assert that even though that is the DEFINITION of what it halting means, 
that some other "equivalenet" characteristic shows it to be not halting.

Since equivalent characteristics, by definition, must yield an 
equivalent result.

Since your concept of "correct simulation" (better described as correct 
partial simulaition) says that DD is non-halting, either you think 
halting is the equivalent to non-halting, or you are just wrong that you 
definition creates an actually equivalent condition.

> 
>>>
>>> *Try and show how you are not lying*
>>>
>>> _DD()
>>> [00001c22] 55         push ebp
>>> [00001c23] 8bec       mov ebp,esp
>>> [00001c25] 51         push ecx
>>> [00001c26] 8b4508     mov eax,[ebp+08]
========== REMAINDER OF ARTICLE TRUNCATED ==========