Path: ...!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
Subject: Re: III correctly emulated by EEE ---
Date: Tue, 25 Mar 2025 07:19:56 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <d24ee89b318d5738772eb50421dd1f9e626fd987@i2pn2.org>
References: <vrfuob$256og$1@dont-email.me> <vrigh6$f35v$1@dont-email.me>
 <vrj6d3$14iuu$1@dont-email.me> <vrjog0$1ilbe$6@dont-email.me>
 <db8aa67218b2a0990cd1df38aca29dbd3930e145@i2pn2.org>
 <vrkumg$2l2ci$2@dont-email.me>
 <ba957e964c1090cbb801b1688b951ac095281737@i2pn2.org>
 <vrmepa$2r2l$1@dont-email.me>
 <d8ee6d675850304b99af1b587437ba0ac64dbb85@i2pn2.org>
 <vrms64$cvat$2@dont-email.me>
 <76e394abe71be9cdc7f1948e73352c4f76ae409e@i2pn2.org>
 <vrmua7$cvat$8@dont-email.me>
 <dc633a07cd15e2c80ed98083cc5f9d218edcc9da@i2pn2.org>
 <vro0hk$1c9ia$1@dont-email.me>
 <9adf9b9c30250aaa2d3142509036c892db2b7096@i2pn2.org>
 <vrpfua$2qbhf$2@dont-email.me>
 <211f9a2a284cb2deaa666f424c1ef826fe855e80@i2pn2.org>
 <vrq330$3dq3n$1@dont-email.me>
 <e7268e8ef47579cacb49b0533d51549a77eb0b96@i2pn2.org>
 <vrqb6f$3k9kh$2@dont-email.me>
 <3f250e699762cfe6fccc844f10eb04f32d470b6a@i2pn2.org>
 <vrrpcl$11a56$4@dont-email.me>
 <8423998561d8feee807509b0ed6335123d35a7c9@i2pn2.org>
 <vrt3gv$264jb$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 25 Mar 2025 11:20:10 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1677552"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vrt3gv$264jb$4@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 9471
Lines: 174

On 3/24/25 10:13 PM, olcott wrote:
> On 3/24/2025 8:28 PM, Richard Damon wrote:
>> On 3/24/25 10:14 AM, olcott wrote:
>>> On 3/24/2025 6:23 AM, Richard Damon wrote:
>>>> On 3/23/25 9:06 PM, olcott wrote:
>>>>> On 3/23/2025 6:56 PM, Richard Damon wrote:
>>>>>> On 3/23/25 6:47 PM, olcott wrote:
>>>>>>> On 3/23/2025 4:46 PM, Richard Damon wrote:
>>>>>>>> On 3/23/25 1:21 PM, olcott wrote:
>>>>>>>>> On 3/23/2025 6:07 AM, Richard Damon wrote:
>>>>>>>>>> On 3/22/25 11:52 PM, olcott wrote:
>>>>>>>>>>> On 3/22/2025 9:53 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/22/25 2:08 PM, olcott wrote:
>>>>>>>>>>>>> On 3/22/2025 12:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 3/22/25 1:31 PM, olcott wrote:
>>>>>>>>>>>>>>> On 3/22/2025 11:37 AM, joes wrote:
>>>>>>>>>>>>>>>> Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>     HHH(Infinite_Recursion);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>> There is no program DDD in the above code.
>>>>>>>>>>>>>>>> There is also no Infinite_Recursion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since no Turing machine M can ever compute the mapping 
>>>>>>>>>>>>>>>>> from the behavior
>>>>>>>>>>>>>>>>> of any directly executed TM2 referring to the behavior 
>>>>>>>>>>>>>>>>> of the directly
>>>>>>>>>>>>>>>>> executed DDD has always been incorrect. Halt Deciders 
>>>>>>>>>>>>>>>>> always report on
>>>>>>>>>>>>>>>>> the behavior that their input finite string specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please explain what behaviour the description of a TM 
>>>>>>>>>>>>>>>> "specifies",
>>>>>>>>>>>>>>>> and which TM the input describes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Bill sang a song" describes what Bill did.
>>>>>>>>>>>>>>> A tape recording of Bill singing that same
>>>>>>>>>>>>>>> song completely specifies what Bill did.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And what a UTM does with this input completely specifies 
>>>>>>>>>>>>>> its behavior,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In every case that does not involve pathological self- 
>>>>>>>>>>>>>>>>> reference the
>>>>>>>>>>>>>>>>> behavior that the finite string specifies is 
>>>>>>>>>>>>>>>>> coincidentally the same
>>>>>>>>>>>>>>>>> behavior as the direct execution of the corresponding 
>>>>>>>>>>>>>>>>> machine. The
>>>>>>>>>>>>>>>>> actual measure, however, has always been the behavior 
>>>>>>>>>>>>>>>>> that the finite
>>>>>>>>>>>>>>>>> string input specifies.
>>>>>>>>>>>>>>>> ...which is the direct execution. Not much of a 
>>>>>>>>>>>>>>>> coincidence.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _III()
>>>>>>>>>>>>>>> [00002172] 55         push ebp      ; housekeeping
>>>>>>>>>>>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
>>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push III
>>>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call EEE(III)
>>>>>>>>>>>>>>> [0000217f] 83c404     add  esp,+04
>>>>>>>>>>>>>>> [00002182] 5d         pop  ebp
>>>>>>>>>>>>>>> [00002183] c3         ret
>>>>>>>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When-so-ever any correct emulator EEE correctly emulates
>>>>>>>>>>>>>>> a finite number of steps of an input III that calls this
>>>>>>>>>>>>>>> same emulator to emulate itself the behavior of the direct
>>>>>>>>>>>>>>> execution of III will not be the same as the behavior of
>>>>>>>>>>>>>>> the emulated III.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Becuase a finite emulation that stop before the end is not 
>>>>>>>>>>>>>> a correct emulation 
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words you keep dishonestly trying to get away with
>>>>>>>>>>>>> disagreeing with the law of identity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When N steps are III are correctly emulated by EEE
>>>>>>>>>>>>> then N steps are III are correctly emulated by EEE.
>>>>>>>>>>>>
>>>>>>>>>>>> Which isn't the same as the CORRECT emulation that shows if 
>>>>>>>>>>>> the program being emulated will halt/.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> There exists no Natural Number N number of steps of III
>>>>>>>>>>>>> correctly emulated by EEE where III reaches its
>>>>>>>>>>>>> own "ret" instruction and terminates normally.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Because
>>>>>>>>>>>
>>>>>>>>>>> In other words you agree that the recursive emulation
>>>>>>>>>>> of a single finite string of x86 machine code single
>>>>>>>>>>> machine address [00002172] cannot possibly reach its
>>>>>>>>>>> own machine address [00002183]when emulated by emulator
>>>>>>>>>>> EEE according to the semantics of the x86 language.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But it isn't a single finite string of x86 machince code, 
>>>>>>>>>
>>>>>>>>> As a matter of verified fact it is a single finite
>>>>>>>>> string of machine code at a fixed offset in the
>>>>>>>>> Halt7.obj file.
>>>>>>>>
>>>>>>>> Nope, because DEFINTIONALLY, to correctly emulate it, you need 
>>>>>>>> ALL of it (at least all seen by the emulator) and thus you can't 
>>>>>>>> change the parts seen and still be talking about the same input.
>>>>>>>>
>>>>>>>> Your claim just shows you are a patholgical liar.
>>>>>>>>
>>>>>>>> You can not "correctly emulate" the code of just the function, 
>>>>>>>> you need the rest of the code, which mean you can't do the 
>>>>>>>> variations you talk about.
>>>>>>>>
>>>>>>>
>>>>>>> x86utm operates on a compiled object file that
>>>>>>> is stored in a single location of global memory.
>>>>>>
>>>>>> Right, and thus you must consider *ALL* of that memory as the 
>>>>>> input, so if you change it, it is a different input.
>>>>>>
>>>>>
>>>>> You haven't yet noticed that all posts with this title
>>>>> [III correctly emulated by EEE] are talking about a pure
>>>>> emulator that emulates a finite number of instructions of III.
>>>>>
>>>>>
>>>>
>>>> Which is just a strawman, and a contradiction, as the definition of 
>>>> "correct emulation" (to be able to use it in the halting problem as 
>>>> a surrogate for the programs behavior) must be complete.
>>>>
>>>
>>> _III()
>>> [00002172] 55         push ebp      ; housekeeping
>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
>>> [00002175] 6872210000 push 00002172 ; push III
>>> [0000217a] e853f4ffff call 000015d2 ; call EEE(III)
>>> [0000217f] 83c404     add  esp,+04
>>> [00002182] 5d         pop  ebp
>>> [00002183] c3         ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> You continue to look increasingly foolish when you
>>> try to keep getting away with denying that III
>>> calls EEE(III) in recursive emulation.
>>>
>>
>> But I don't deny it, just point out that it is irrelevent, 
========== REMAINDER OF ARTICLE TRUNCATED ==========