| Deutsch English Français Italiano |
|
<vrqb6f$3k9kh$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: 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: Sun, 23 Mar 2025 20:06:22 -0500
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <vrqb6f$3k9kh$2@dont-email.me>
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>
<e7268e8ef47579cacb49b0533d51549a77eb0b96@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Mar 2025 02:06:24 +0100 (CET)
Injection-Info: dont-email.me; posting-host="937db52631d074d5f8724ea8775a1ccd";
logging-data="3810961"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PQjyyNkdjDOofxoU4dy5e"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9UZThoBbiLf1hig4cEhQk3SLDm4=
X-Antivirus: Norton (VPS 250323-4, 3/23/2025), Outbound message
In-Reply-To: <e7268e8ef47579cacb49b0533d51549a77eb0b96@i2pn2.org>
X-Antivirus-Status: Clean
Content-Language: en-US
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.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer