Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: III correctly emulated by EEE ---
Date: Tue, 25 Mar 2025 07:00:57 -0500
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <vru5tp$38ob9$1@dont-email.me>
References: <vrfuob$256og$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>
 <448c82acff6b5fc1d2aa266be92df6f778ec2c6a@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 25 Mar 2025 13:01:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9741c665c88d9215381b06ce738934cb";
	logging-data="3432809"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX187+8o1OTwAKCfZ5eKFKpr0"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tiYUZhXlP+WESlpibpghLHcHv2Y=
X-Antivirus: Norton (VPS 250324-4, 3/24/2025), Outbound message
In-Reply-To: <448c82acff6b5fc1d2aa266be92df6f778ec2c6a@i2pn2.org>
Content-Language: en-US
X-Antivirus-Status: Clean
Bytes: 8276

On 3/25/2025 3:37 AM, joes wrote:
> Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:
>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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.
> But there is an N after which III returns.
> 
>>>>>>>>>>>> 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.
> Then it is not pure.
> 
>>>>> 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.
>>>>>
>>>> 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,
>>
>> It proves that the input DDD to HHH DOES NOT HALT.
>> How the f-ck is that irrelevant?
> DDD, the input, halts.
> 

The DDD that halts IS NOT AN ACTUAL INPUT TO HHH.

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