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: Thu, 30 May 2024 22:51:00 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3bduk$2im01$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 31 May 2024 02:51:00 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2709505"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v3bcre$22a8n$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 7562
Lines: 154

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.

Note, the CODE, when run, reaches that state, if HH returns the answer 
(as it must to be a decider).

The PARTIAL simulation that HH has been programmed to do, doesn't reach 
that point, even though the COMPLETE AND CORRECT simulation of that same 
input by a UTM (where DD still calls the HH that does abort and return) 
will reach that point.

You are just stuck in your deception of trying to change the meaning of 
"Correct Simulation".

> 
> _DD()
> [00001c22] 55         push ebp
> [00001c23] 8bec       mov ebp,esp
> [00001c25] 51         push ecx
> [00001c26] 8b4508     mov eax,[ebp+08]
> [00001c29] 50         push eax         ; push DD 1c22
> [00001c2a] 8b4d08     mov ecx,[ebp+08]
> [00001c2d] 51         push ecx         ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342    ; call HH
> [00001c33] 83c408     add esp,+08
> [00001c36] 8945fc     mov [ebp-04],eax
> [00001c39] 837dfc00   cmp dword [ebp-04],+00
> [00001c3d] 7402       jz 00001c41
> [00001c3f] ebfe       jmp 00001c3f
> [00001c41] 8b45fc     mov eax,[ebp-04]
> [00001c44] 8be5       mov esp,ebp
> [00001c46] 5d         pop ebp
> [00001c47] c3         ret
> Size in bytes:(0038) [00001c47]
> 
> *I am going to stop here and not respond to anything else*
> *that you say until AFTER this one point is fully resolved*
> 
> 

So, are you going to stop LYING about what I am saying?

I never said that HH does an incorrect partial simulation, a simulation 
that mis-simulates any of the instructions that it actually simulates.

Your TRACES show the error of not following the call to HH, and thus 
your TRACES are LIES, and my memory is that your code of H actually has 
checks that do what you show, becuase it just doesn't simulate the 
instrucitons after the call.

So, if HH actually does what you claim, you need to present the output 
of what it does, and that would be simulating the actual instructions of 
HH. If that is too long to post in the newsgroup, post that ACTUAL trace 
on a web site.