Deutsch English Français Italiano |
<vb4fd0$2s0uc$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!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: Indirect Reference Changes the Behavior of DDD() relative to DDD emulated by HHH Date: Mon, 2 Sep 2024 08:42:56 -0500 Organization: A noiseless patient Spider Lines: 167 Message-ID: <vb4fd0$2s0uc$2@dont-email.me> References: <va104l$376ed$4@dont-email.me> <148bf4dd91f32379a6d81a621fb7ec3fc1e00db0@i2pn2.org> <va3lai$3nd5c$2@dont-email.me> <va46sd$3pr24$1@dont-email.me> <va4mle$3s0hu$1@dont-email.me> <5591ff08ed8f7b4bdf33813681e156b775efe0ec@i2pn2.org> <va63uu$2fo9$1@dont-email.me> <b0a86b6a1343ebb5f9112ae757768a7cbbc770b2@i2pn2.org> <va65r8$6ht7$1@dont-email.me> <da75188ffa7677bd2b6979c8fc6ba82119404306@i2pn2.org> <878qwn0wyz.fsf@bsb.me.uk> <efacnfsQdv-ErlT7nZ2dnZfqnPadnZ2d@brightview.co.uk> <87le0jzc8f.fsf_-_@bsb.me.uk> <vaj1kd$2kvg9$1@dont-email.me> <eca21d905b57bb0b98172c573890b5c8cda91da8@i2pn2.org> <vakisq$302rl$3@dont-email.me> <vamjse$3d6eb$1@dont-email.me> <van2ni$3f6c0$1@dont-email.me> <vap9r5$3t411$1@dont-email.me> <vapv4l$3vumk$4@dont-email.me> <vashj9$grso$1@dont-email.me> <vav3iq$10jsm$4@dont-email.me> <vavc3b$11uqn$2@dont-email.me> <vavcf8$129qh$1@dont-email.me> <vavdv4$11uqn$6@dont-email.me> <vavfjq$12m8t$3@dont-email.me> <vb1gqf$1f566$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 02 Sep 2024 15:42:57 +0200 (CEST) Injection-Info: dont-email.me; posting-host="a2fe8748f6382997edaeece42547d6b5"; logging-data="3015628"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iJoNJ+SNnduaIJsyRwwfc" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:LZmRzCqAGLWzB9UOgfaXdEcnK/k= Content-Language: en-US In-Reply-To: <vb1gqf$1f566$1@dont-email.me> Bytes: 9239 On 9/1/2024 5:48 AM, Fred. Zwarts wrote: > Op 31.aug.2024 om 18:15 schreef olcott: >> On 8/31/2024 10:47 AM, Fred. Zwarts wrote: >>> Op 31.aug.2024 om 17:22 schreef olcott: >>>> On 8/31/2024 10:15 AM, Fred. Zwarts wrote: >>>>> Op 31.aug.2024 om 14:50 schreef olcott: >>>>>> On 8/30/2024 8:31 AM, Mikko wrote: >>>>>>> On 2024-08-29 14:04:05 +0000, olcott said: >>>>>>> >>>>>>>> On 8/29/2024 3:00 AM, Mikko wrote: >>>>>>>>> On 2024-08-28 11:46:58 +0000, olcott said: >>>>>>>>> >>>>>>>>>> On 8/28/2024 2:33 AM, Mikko wrote: >>>>>>>>>>> On 2024-08-27 13:04:26 +0000, olcott said: >>>>>>>>>>> >>>>>>>>>>>> On 8/27/2024 12:45 AM, joes wrote: >>>>>>>>>>>>> Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott: >>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>> writes: >>>>>>>>>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We don't really know what context Sipser was given. I >>>>>>>>>>>>>>>>> got in touch >>>>>>>>>>>>>>>>> at the time so I do know he had enough context to know >>>>>>>>>>>>>>>>> that PO's >>>>>>>>>>>>>>>>> ideas were "wacky" and that had agreed to what he >>>>>>>>>>>>>>>>> considered a "minor >>>>>>>>>>>>>>>>> remark". Since PO considers his words finely crafted >>>>>>>>>>>>>>>>> and key to his >>>>>>>>>>>>>>>>> so-called work I think it's clear that Sipser did not >>>>>>>>>>>>>>>>> take the "minor >>>>>>>>>>>>>>>>> remark" he agreed to to mean what PO takes it to mean! >>>>>>>>>>>>>>>>> My own take >>>>>>>>>>>>>>>>> if that he (Sipser) read it as a general remark about >>>>>>>>>>>>>>>>> how to >>>>>>>>>>>>>>>>> determine some cases, i.e. that D names an input that H >>>>>>>>>>>>>>>>> can partially >>>>>>>>>>>>>>>>> simulate to determine it's halting or otherwise. We >>>>>>>>>>>>>>>>> all know or >>>>>>>>>>>>>>>>> could construct some such cases. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Exactly my reading. It makes Sipser's agreement >>>>>>>>>>>>>>>> natural, because it >>>>>>>>>>>>>>>> is both correct [with sensible interpretation of terms], >>>>>>>>>>>>>>>> and moreover >>>>>>>>>>>>>>>> describes an obvious strategy that a partial decider >>>>>>>>>>>>>>>> might use that >>>>>>>>>>>>>>>> can decide halting for some specific cases. No need for >>>>>>>>>>>>>>>> Sipser to be >>>>>>>>>>>>>>>> deceptive or misleading here, when the truth suffices. >>>>>>>>>>>>>>>> (In particular >>>>>>>>>>>>>>>> no need to employ "tricksy" vacuous truth get out >>>>>>>>>>>>>>>> clauses just to get >>>>>>>>>>>>>>>> PO off his back as some have suggested.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>> >>>>>>>>>>>>>>> That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>>> "I managed to >>>>>>>>>>>>>>> trick X into saying 'yes' to something vague". In any >>>>>>>>>>>>>>> reasonable >>>>>>>>>>>>>>> collegiate exchange you'd go back and check: "So even >>>>>>>>>>>>>>> when D is >>>>>>>>>>>>>>> constructed from H, H can return based on what /would/ >>>>>>>>>>>>>>> happen if H did >>>>>>>>>>>>>>> not stop simulating so that H(D,D) == false is correct >>>>>>>>>>>>>>> even though D(D) >>>>>>>>>>>>>>> halts?". Just imagine what Sipser would say to that! >>>>>>>>>>>>> Is this an accurate phrasing, pete? >>>>>>>>>>>> >>>>>>>>>>>> Deciders never compute the mapping of the computation >>>>>>>>>>>> that they themselves are contained within. >>>>>>>>>>> >>>>>>>>>>> Why not? A decider always either accepts or rejects its input. >>>>>>>>>> >>>>>>>>>> The computation that they themselves are contained within cannot >>>>>>>>>> possibly be an input. >>>>>>>>> >>>>>>>>> What would prevent that if the input language permits >>>>>>>>> computations? >>>>>>>>> >>>>>>>> >>>>>>>> When a TM takes its own machine description as input >>>>>>>> this is not always that same behavior as the direct >>>>>>>> execution of the machine. It is not the same because >>>>>>>> it is one level of indirect reference away. >>>>>>> >>>>>>> Now you contradict what you said above. You said that deciders never >>>>>>> conpute the mapping of the computation they themselves are contained >>>>>>> within. >>>>>> >>>>>> Although deciders cannot possibly see their own behavior >>>>>> other people can see this behavior. >>>>>> >>>>>>> Now you are saying that they do in a way that might not be >>>>>>> as expected. >>>>>>> >>>>>> >>>>>> If is a verified fact that DDD has different behavior >>>>>> before it is aborted in the same way that people are >>>>>> hungry before they eat. >>>>> >>>>> No, the behaviour specified by the finite string does not change >>>>> when a simulator decides to do the simulation only halfway. It is >>>>> just an incorrect simulation. >>>>> >>>>>> >>>>>> than the behavior of DDD after it has been aborted, >>>>>> people are not hungry after they eat. >>>>> >>>>> If two people are hungry and one of them eats, the other one is >>>>> still hungry and needs to eat. It is stupid to say that they are no >>>>> longer hungry because they have eaten. >>>>> Similarly the simulating HHH is not longer hungry, but the >>>>> simulated HHH still is hungry and has not yet eaten. >>>>> >>>>>> >>>>>> The direct execution of DDD includes the behavior >>>>>> of the emulated DDD after it has been aborted. >>>>> >>>>> And the simulator should also simulate until it sees the behaviour >>>>> of after the simulated HHH has aborted its simulator. >>>> >>>> THIS IS ONLY YOUR OWN FREAKING STUPIDITY. >>> No evidence for this ad hominem attack. So, my claim still stands. >> >> People that are not as stupid can see that HHH cannot >> wait for itself to abort its own simulation. >> > > And people (except the stupid ones) can see that, because HHH cannot > wait for itself, Because this would require it to wait forever, thus HHH knows that to meet its own requirement to halt it must abort its simulation. > this means that HHH failed to simulate itself correctly You are either very stupid or a damned liar about this. As long as HHH emulates its input according to the semantics of the x86 language HHH is correctly emulating this input even if this correct emulation causes the computer to catch on fire. AS I HAVE TOLD YOU FAR TOO MANY TIMES CORRECT EMULATION IS ENTIRELY DETERMINED BY THE SEMANTICS OF THE X86 LANGUAGE. When DDD calls HHH(DDD) then HHH must emulate itself emulating DDD. If this causes the emulated HHH to never return THEN THIS EMULATION IS STIPULATED TO BE CORRECT BY THE ONLY MEASURE OF CORRECT EMULATION, the semantics of the x86 language. > up to the end. HHH cannot possibly simulate itself correctly up to the end. HHH cannot possibly correctly simulate itself to the end because ========== REMAINDER OF ARTICLE TRUNCATED ==========