Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mikko Newsgroups: comp.theory Subject: Re: Who here understands that the last paragraph is Necessarily true? Date: Fri, 19 Jul 2024 10:49:52 +0300 Organization: - Lines: 105 Message-ID: References: <58fc6559638120b31e128fe97b5e955248afe218@i2pn2.org> <1173a460ee95e0ca82c08abecdefc80ba86646ac@i2pn2.org> <5f6daf68f1b4ffac854d239282bc811b5b806659@i2pn2.org> <60e7a93cb8cec0afb68b3e40a0e82e9d63fa8e2a@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 19 Jul 2024 09:49:53 +0200 (CEST) Injection-Info: dont-email.me; posting-host="218330c1c4e97bfc3b405615ab2ac0d3"; logging-data="3053115"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+hLE5bwJ2iTP/zshNDL/B/" User-Agent: Unison/2.2 Cancel-Lock: sha1:M2R1gHAHbid0xB1wN71Qnrpkrqc= Bytes: 5948 On 2024-07-17 13:22:09 +0000, olcott said: > On 7/17/2024 2:32 AM, Mikko wrote: >> On 2024-07-16 14:04:18 +0000, olcott said: >> >>> On 7/16/2024 6:53 AM, Richard Damon wrote: >>>> On 7/15/24 10:51 PM, olcott wrote: >>>>> On 7/15/2024 2:40 PM, olcott wrote: >>>>>> On 7/15/2024 2:30 PM, Fred. Zwarts wrote: >>>>>>> Op 15.jul.2024 om 04:33 schreef olcott: >>>>>>>> On 7/14/2024 9:04 PM, Richard Damon wrote: >>>>>>>>> On 7/14/24 9:27 PM, olcott wrote: >>>>>>>>>> >>>>>>>>>> Any input that must be aborted to prevent the non termination >>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>> >>>>>>>>> Excpet, as I have shown, it doesn't. >>>>>>>>> >>>>>>>>> Your problem is you keep on ILEGALLY changing the input in your >>>>>>>>> argument because you have misdefined what the input is. >>>>>>>>> >>>>>>>> >>>>>>>> _DDD() >>>>>>>> [00002163] 55         push ebp      ; housekeeping >>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping >>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD >>>>>>>> [0000216b] e853f4ffff call 000015c3 ; call HHH(DDD) >>>>>>>> [00002170] 83c404     add esp,+04 >>>>>>>> [00002173] 5d         pop ebp >>>>>>>> [00002174] c3         ret >>>>>>>> Size in bytes:(0018) [00002174] >>>>>>>> >>>>>>>> The input *is* the machine address of this finite >>>>>>>> string of bytes: 558bec6863210000e853f4ffff83c4045dc3 >>>>>>>> >>>>>>> >>>>>>> It seems that you do not understand x86 language. The input is not a >>>>>>> string of bytes, but an address (00002163). This points to the starting >>>>>>> of the code of DDD. But a simulation needs a program, not a function >>>>>>> calling undefined other functions. Therefore, all functions called by >>>>>>> DDD (such as HHH) are included in the code to simulate. >>>>>> >>>>>> *The input is the machine address of this finite* >>>>>> *string of bytes: 558bec6863210000e853f4ffff83c4045dc3* >>>>>> >>>>>> You are talking about the behavior specified by that finite >>>>>> string. When you say that a finite string *is not* a finite >>>>>> string you are disagreeing with the law of identity. >>>>>> >>>>>> Every rebuttal to my work disagrees with one tautology of another. >>>>>> It is the fact that DDD calls HHH(DDD) in recursive emulation >>>>>> that makes it impossible for DDD correctly emulated by HHH to halt. >>>>> >>>>>> Everyone disagrees with this entirely on the basis of the strawman >>>>>> deception (damned lie) that some other DDD somewhere else has >>>>>> different behavior. >>>>> >>>>> *They disagree with the following* >>>>> >>>>> In other words the fact that the directly executed DDD halts >>>>> because the HHH(DDD) that it calls has already aborted its >>>>> simulation proves these these two different instances of DDD >>>>> are in different process states. >>>> >>>> BUT must have the same behavior. >>>> >>>>> >>>>> The state of needing to abort the input changes after it has >>>>> already been aborted is the same as the state of being hungry >>>>> changes after you have had something to eat. >>>>> >>>> >>>> Can't. Since programs are unchanging, their properties can not change. >>>> >>> >>> *WRONG* >>> https://en.wikipedia.org/wiki/Self-modifying_code >> >> Your complier cannot produce self-modifying code. >> > > My compiler can accept assembly language > that can derive self-modifying code. Using non-standard extensions of the language may indeed permit that unless the program is loaded to a read-only memory. The compiler is designed so that ordinary programs can be loaded to read-only memory. Some operating systems prevent programs from modifying themselves as if the program were in a read-only memory, and typical compilers compile so that the program can be run under such operating systems. > My first paper is based on a decider that changes itself > so that it can always get the correct answer. > > Self Modifying Turing Machine (SMTM) Solution to the Halting Problem > (concrete example) August 2016 > > https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example > -- Mikko