Path: ...!news.nobody.at!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: Thu, 30 May 2024 22:27:37 -0500
Organization: A noiseless patient Spider
Lines: 164
Message-ID: <v3bg39$22o6m$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>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 31 May 2024 05:27:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="08a73d0f9257967986a8324b25ade22a";
	logging-data="2187478"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/IPQ1gLAg+jkce60bJIC+6"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:I00C70w9+/EEP+/Awtd1CcXA+oE=
In-Reply-To: <v3bfbm$2im01$3@i2pn2.org>
Content-Language: en-US
Bytes: 7999

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*

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.

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

>>
>> *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]
>> [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*

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