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: Sun, 23 Mar 2025 19:56:04 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <e7268e8ef47579cacb49b0533d51549a77eb0b96@i2pn2.org>
References: <vrfuob$256og$1@dont-email.me> <vrgme1$2tr56$1@dont-email.me>
 <vri5mn$6nv4$1@dont-email.me>
 <8354fe5751e03a767452a3999818d5c6da714a6b@i2pn2.org>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 23 Mar 2025 23:56:04 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1477596"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vrq330$3dq3n$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 8887
Lines: 171

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.

That means you are just lying when you say the below is the finite 
string input given to EEE, as you just admitted that it uses more.

(It also shows your stupidity to say it stored the entire file in "a 
single location of global memory", as a signle location can hold only 
one value, even more evidence of you not knowing what you are talking about.

And the use of "global memory" as you have admitted, breaks the 
definition of your decider, which you have admitted needs to be a pure 
function, and thus can't use "global memory".

> 
> _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]
> 
> There are no freaking variations merely III repeating
> its first four instructions a finite number of times.
> 

Nope. The ONLY correct emulation shows goig from 0000217A with a call to 
EEE at 000015d2, and after that the Program Counter for this emulation 
will NEVER get back to any of the addresses between 00002172 to 0000217a.

IT is only the variable within EEE that represents the address it is 
emulation that goes back there, so your statement is just a lie.

And, since EEE did look at those locations in memory, every EEE got a 
DIFFERENT input, as the actual input is much larger than you deceptively 
claim, as it DOES contain all the memory locations looked at, which 
include the code for EEE, and thus every time you changed EEE, you 
canged the ACTUAL finite string that represents the input, and thus you 
========== REMAINDER OF ARTICLE TRUNCATED ==========