Deutsch English Français Italiano |
<vue5ph$27hl2$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Fred. Zwarts" <F.Zwarts@HetNet.nl> Newsgroups: comp.theory Subject: Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Using Finite String Transformations Date: Thu, 24 Apr 2025 22:09:21 +0200 Organization: A noiseless patient Spider Lines: 84 Message-ID: <vue5ph$27hl2$1@dont-email.me> References: <vsnchj$23nrb$2@dont-email.me> <vto4vh$23i07$1@dont-email.me> <vto7qu$267in$1@dont-email.me> <k%RLP.1232047$Xb1.539402@fx05.ams4> <vtorpb$2uac$1@news.muc.de> <vtp32o$2vb5o$1@dont-email.me> <vtqpt5$17ns$1@news.muc.de> <vtrhbc$16pbv$2@dont-email.me> <vtrk7l$t44$1@news.muc.de> <vtrmfa$1be3n$1@dont-email.me> <vtvkgo$vjvi$1@dont-email.me> <vu2042$34l74$1@dont-email.me> <vu519u$1s5f9$1@dont-email.me> <vu6aha$2vn05$3@dont-email.me> <vu6dk4$2fq2$1@news.muc.de> <vu6knm$394oo$1@dont-email.me> <vu8cgm$2p5e$1@news.muc.de> <vu8gml$v0qa$2@dont-email.me> <vu8m2h$vn9b$2@dont-email.me> <vu8pr1$13jl5$8@dont-email.me> <vu8qo3$vn9b$4@dont-email.me> <vu8ruc$13jl5$12@dont-email.me> <vuaaae$2lbp9$2@dont-email.me> <zIWdnaZKufSzmpT1nZ2dnZfqnPadnZ2d@brightview.co.uk> <vub1go$3clpn$3@dont-email.me> <HcWcnf7heZkdG5T1nZ2dnZfqn_qdnZ2d@brightview.co.uk> <vue4jl$28iho$5@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 24 Apr 2025 22:09:21 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2e638f62f9520c381ea45971c85c834e"; logging-data="2344610"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LNsRGuqT0vU1zGCT8E9s2" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:gljfmIjpc0cc0PDJ3SzzREoA5NI= Content-Language: nl, en-GB In-Reply-To: <vue4jl$28iho$5@dont-email.me> Bytes: 5833 Op 24.apr.2025 om 21:49 schreef olcott: > On 4/23/2025 7:31 PM, Mike Terry wrote: >> On 23/04/2025 16:38, olcott wrote: >>> On 4/23/2025 10:28 AM, Mike Terry wrote: >>>> On 23/04/2025 10:02, Fred. Zwarts wrote: >>>>> Op 22.apr.2025 om 21:50 schreef olcott: >>>>>> On 4/22/2025 2:30 PM, Fred. Zwarts wrote: >>>>>>> Op 22.apr.2025 om 21:14 schreef olcott: >>>>>>>> On 4/22/2025 1:10 PM, Fred. Zwarts wrote: >>>>>>>>> Op 22.apr.2025 om 18:38 schreef olcott: >>>>>>>>>> >>>>>>>>>> a function is computable if there exists an algorithm >>>>>>>>>> that can do the job of the function, i.e. given an input >>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>> >>>>>>>>>> On Turing Machines inputs <are> finite strings, and >>>>>>>>>> finite string transformation rules <are> applied to >>>>>>>>>> these finite strings to derive corresponding outputs. >>>>>>>>>> >>>>>>>>> And it has been proven that no finite string transformations >>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>> that specify a correct program. >>>>>>>> >>>>>>>> int sum(int x, int y) { return x + y; } >>>>>>>> Only when people stupid assume the same thing as >>>>>>>> sum(3,2) should return the sum of 5 + 3. >>>>>>>> >>>>>>> Therefore HHH should report on the actual input, the finite >>>>>>> string that describes a halting program. Not on the hypothetical >>>>>>> input that does not halt, because it is based on a hypothetical >>>>>>> HHH that does not abort. >>>>>>> >>>>>>> Why do you maintain that HHH should process the hypothetical >>>>>>> input instead of the actual input. >>>>>>> Do you really believe that 3+2 equals 5+3? >>>>>> >>>>>> I have proven that the directly executed DD and DD >>>>>> emulated by HHH according to the semantics of the >>>>>> x86 language have a different set of state changes >>>>>> many hundreds of times for several years. >>>>> You never showed a proof. You only repeated a dream. You are >>>>> dreaming many years without any logic. You failed to show the first >>>>> state change where the direct execution is different from the >>>>> simulation. You only showed an erroneous HHH that fails to reach >>>>> the end of the simulation of a halting program. >>>> >>>> Worse than this, on more than one occasion I've actually posted >>>> traces of computation DDD(DDD) executed directly and simulated by >>>> HHH side by side. Both traces were of course /identical/, up to the >>>> point where HHH stops simulating. >>> >>> *Factually incorrect* (You are usually very careful about these things) >>> The call to HHH(DD) from the directly executed DD returns. >>> The call to HHH(DD) from DD emulated by HHH cannot possibly return. >>> >> >> ...because HHH stops simulating before reaching that step in the >> computation. Note that I said >> >> MT: Both traces were of course /identical/, >> *up to the point where HHH stops simulating* >> >> So I was factually correct. >> >> >> Mike. >> > > THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION > AND THE DIRECTLY EXECUTED DD NEVER DOES. > > When the finite string transformation rules of the > x86 language are applied to the input to HHH(DD) > THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE > not even after an infinite number of emulated steps. > It is only a finite recursion. Only if you change the input as well, then it does not reach the end after an infinite number of steps. But for the input given to *this* HHH, which is DD that calls this HHH that aborts, only a finite number of steps is needed, but HHH does not simulate enough steps to see it. The programmer introduced a bug, which made HHH blind for finite recursions.