Deutsch English Français Italiano |
<v7htlv$3u1jc$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!feeder1.cambriumusenet.nl!feed.tweak.nl!217.73.144.44.MISMATCH!feeder.ecngs.de!ecngs!feeder2.ecngs.de!168.119.53.7.MISMATCH!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: Hypothetical possibilities Date: Sat, 20 Jul 2024 22:01:19 -0500 Organization: A noiseless patient Spider Lines: 165 Message-ID: <v7htlv$3u1jc$1@dont-email.me> References: <v7gl30$3j9fi$1@dont-email.me> <v7h1fl$3lcvq$3@dont-email.me> <v7h224$3li66$3@dont-email.me> <e975eef57ba6d3d4cc790818c05b7165443f7ce4@i2pn2.org> <v7h5b2$3m6kq$2@dont-email.me> <73e4850d3b48903cf85b2967ba713aced98caf96@i2pn2.org> <v7h9on$3muu0$1@dont-email.me> <09536cf44fc4c3d14b37641cf8fdc9e8a8c24580@i2pn2.org> <v7hept$3o0be$1@dont-email.me> <97884acd35091ddd67bda892c7a3dd28e188f760@i2pn2.org> <v7hftt$3o7r5$1@dont-email.me> <f74209ef7d87b6f7891e4a2b89cc18bfe7233810@i2pn2.org> <v7hkb2$3otgn$1@dont-email.me> <1c5729ae6d0a7bca84d24eec9f85bf30de70e3d9@i2pn2.org> <v7hnu6$3pd9s$1@dont-email.me> <f0dda3e0d0e85081d8ce0cdd494f5f1f8f8c89e3@i2pn2.org> <v7hpkv$3pmkh$1@dont-email.me> <bae0c74b7bd66b38b097faae53d1dc2fa3cfb0ad@i2pn2.org> <v7hrfb$3tn3h$1@dont-email.me> <547a563f882d081187fb1c6a27ef08a93ff1edd8@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 21 Jul 2024 05:01:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9ab67b95e26d71c9bf3d4bab69c0e6c7"; logging-data="4130412"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19BEVHAUwgc5G1Y8Pa3hC6M" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:tUOBQAF6xR/neHs95xYggq8sOl0= Content-Language: en-US In-Reply-To: <547a563f882d081187fb1c6a27ef08a93ff1edd8@i2pn2.org> Bytes: 8755 On 7/20/2024 9:55 PM, Richard Damon wrote: > On 7/20/24 10:23 PM, olcott wrote: >> On 7/20/2024 9:05 PM, Richard Damon wrote: >>> On 7/20/24 9:52 PM, olcott wrote: >>>> On 7/20/2024 8:46 PM, Richard Damon wrote: >>>>> On 7/20/24 9:23 PM, olcott wrote: >>>>>> On 7/20/2024 8:01 PM, Richard Damon wrote: >>>>>>> On 7/20/24 8:21 PM, olcott wrote: >>>>>>>> On 7/20/2024 7:05 PM, Richard Damon wrote: >>>>>>>>> On 7/20/24 7:06 PM, olcott wrote: >>>>>>>>>> On 7/20/2024 6:00 PM, Richard Damon wrote: >>>>>>>>>>> On 7/20/24 6:47 PM, olcott wrote: >>>>>>>>>>>> On 7/20/2024 5:11 PM, Richard Damon wrote: >>>>>>>>>>>>> On 7/20/24 5:21 PM, olcott wrote: >>>>>>>>>>>>>> On 7/20/2024 4:06 PM, joes wrote: >>>>>>>>>>>>>>> Am Sat, 20 Jul 2024 15:05:53 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 7/20/2024 2:50 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>> On 7/20/24 3:09 PM, olcott wrote: >>>>>>>>>>>>>>>>>> On 7/20/2024 2:00 PM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>> Op 20.jul.2024 om 17:28 schreef olcott: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> (a) Termination Analyzers / Partial Halt Deciders >>>>>>>>>>>>>>>>>>>> must halt this is >>>>>>>>>>>>>>>>>>>> a design requirement. >>>>>>>>>>>>>>>>>>>> (b) Every simulating termination analyzer HHH either >>>>>>>>>>>>>>>>>>>> aborts the >>>>>>>>>>>>>>>>>>>> simulation of its input or not. >>>>>>>>>>>>>>>>>>>> (c) Within the hypothetical case where HHH does not >>>>>>>>>>>>>>>>>>>> abort the >>>>>>>>>>>>>>>>>>>> simulation of its input {HHH, emulated DDD and >>>>>>>>>>>>>>>>>>>> executed DDD} >>>>>>>>>>>>>>>>>>>> never stop running. >>>>>>>>>>>>>>>>>>>> This violates the design requirement of (a) >>>>>>>>>>>>>>>>>>>> therefore HHH must abort >>>>>>>>>>>>>>>>>>>> the simulation of its input. >>>>>>>>>>>>>>> You missed a couple details: >>>>>>>>>>>>>>> A terminating input shouldn't be aborted, or at least not >>>>>>>>>>>>>>> classified >>>>>>>>>>>>>>> as not terminating. Terminating inputs needn't be >>>>>>>>>>>>>>> aborted; they and the >>>>>>>>>>>>>>> simulator halt on their own. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> And when it aborts, the simulation is incorrect. When >>>>>>>>>>>>>>>>>>> HHH aborts and >>>>>>>>>>>>>>>>>>> halts, it is not needed to abort its simulation, >>>>>>>>>>>>>>>>>>> because it will halt >>>>>>>>>>>>>>>>>>> of its own. >>>>>>>>>>>>>>>>>> So you are trying to get away with saying that no HHH >>>>>>>>>>>>>>>>>> ever needs to >>>>>>>>>>>>>>>>>> abort the simulation of its input and HHH will stop >>>>>>>>>>>>>>>>>> running? >>>>>>>>>>>>>>> Pretty much. >>>>>>>>>>>>>>>>> It is the fact that HHH DOES abort its simulation that >>>>>>>>>>>>>>>>> makes it not >>>>>>>>>>>>>>>>> need to. >>>>>>>>>>>>>>>> No stupid it is not a fact that every HHH that can >>>>>>>>>>>>>>>> possibly exist aborts >>>>>>>>>>>>>>>> its simulation. >>>>>>>>>>>>>>> I thought they all halt after a finite number of steps? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> void DDD() >>>>>>>>>>>>>> { >>>>>>>>>>>>>> HHH(DDD); >>>>>>>>>>>>>> return; >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> DDD correctly simulated by pure function HHH cannot >>>>>>>>>>>>>> possibly reach its own return instruction. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Wrong. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You know that you are lying about this as you admit below: >>>>>>>>>>> >>>>>>>>>>> Nope, YOU just don't what the words mean, and reckless >>>>>>>>>>> disregard the teaching you have been getting, which makes >>>>>>>>>>> your errors not just honest mistakes but reckless >>>>>>>>>>> pathological lies. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> It may be that the simulation by HHH never reaches that point, >>>>>>>>>>>> >>>>>>>>>>>>> but if HHH aborts its simuliaton and returns (as required >>>>>>>>>>>>> for it to be a decider) then the behavior of DDD >>>>>>>>>>>> >>>>>>>>>>>> Simulated by HHH is to Die, stop running, no longer function. >>>>>>>>>>> >>>>>>>>>>> Nope, HHH is NOT the "Machine" that determines what the code >>>>>>>>>>> does, so can not "Kill" it. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So you are trying to get away with the lie >>>>>>>>>> that an aborted simulation keeps on running. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No, but the BEHAVIOR of the program does, and that is what >>>>>>>>> matters. >>>>>>>> >>>>>>>> So you agree that DDD correctly simulated by any pure function >>>>>>>> HHH cannot possibly reach its own return instruction? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> No, I will let you claim (without proof, so we can argue tha >>>>>>> later) that the simulation by HHH of DDD does not reach the >>>>>>> return, but the behavior of the DDD simuliated by HHH continues, >>>>>> >>>>>> We are talking about real hardware here not figments >>>>>> of your imagination. >>>>>> >>>>> >>>>> No, you are not. The "Hardware" would be the actual CPU chip which >>>>> never stops the program when it is running. A Simulator is just a >>>>> piece of software running on it, and what it does can't affect the >>>>> behavior of the actual CPU running the program. >>>>> >>>>> >>>>>> When an actual x86 emulator stops emulating its input >>>>>> this emulated input immediately stops running. >>>>>> >>>>> >>>>> Nope, that is you stupidity where you confuse the observation for >>>>> the facts. >>>>> >>>>> It has been told to you MANY times, but it seems that you just can >>>>> not understand it. >>>>> >>>>> The SIMULATION is an observation of the program, >>>> >>>> Not at all. It is the same as a finite string of static data >>>> interpreted by an interpreter. It is merely data within the >>>> process of the x86 emulator. When the emulator stops emulating >>>> it immediately stops. >>>> >>> >>> In other words, you have just been lying for years about doing the >>> Halting problem, whose input is the reperesentation of the program to >>> be decided. >>> >>> No program to be decided on, no program to be emulated. >>> >> >> I was shocked to find out that you really believed that a static >> finite string could keep running after its x86 emulator stopped >> emulating it. >> >> I thought that you understood that when an interpreter stops >> interpreting its input source-code the the interpreted program >> would stop. >> > > I guess I need to be shocked that you so poorly understand the problem Trying to get away with changing the subject won't work. Your knowledge of software engineering is apparently insufficient to understand very basic ideas that are a mandatory prerequisite. ========== REMAINDER OF ARTICLE TRUNCATED ==========