Deutsch English Français Italiano |
<vrrpcl$11a56$4@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
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: Mon, 24 Mar 2025 09:14:44 -0500 Organization: A noiseless patient Spider Lines: 154 Message-ID: <vrrpcl$11a56$4@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> <vrqb6f$3k9kh$2@dont-email.me> <3f250e699762cfe6fccc844f10eb04f32d470b6a@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 15:14:45 +0100 (CET) Injection-Info: dont-email.me; posting-host="2287d57c8a85f7b4edf97e8b0d992052"; logging-data="1091750"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sB8tHi8jVYPS2Lu9vIhGC" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:r7TUi8uO1j9DmcRyk5xkPg7qCe8= Content-Language: en-US X-Antivirus: Norton (VPS 250324-2, 3/24/2025), Outbound message X-Antivirus-Status: Clean In-Reply-To: <3f250e699762cfe6fccc844f10eb04f32d470b6a@i2pn2.org> Bytes: 8454 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. -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer