Deutsch English Français Italiano |
<vueisg$2luer$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: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Using Finite String Transformations Date: Thu, 24 Apr 2025 18:52:48 -0500 Organization: A noiseless patient Spider Lines: 115 Message-ID: <vueisg$2luer$1@dont-email.me> References: <vsnchj$23nrb$2@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> <vucbg5$mukj$1@dont-email.me> <vucbrv$mukj$2@dont-email.me> <b76c7dc89655dcc3f3fb52dee18a2d30f82f6166@i2pn2.org> <vue9t9$2d7t8$6@dont-email.me> <7e071b34937fe58e9523ac4be56ece689b1248ae@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 25 Apr 2025 01:52:49 +0200 (CEST) Injection-Info: dont-email.me; posting-host="300926f27b5919fc39f09bdee60cc0b3"; logging-data="2816475"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/1Kd2VgvnAFqM5/3VGQZ+I" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:Pcf43iKRrk1tPcjpjI2FTQFGUcE= In-Reply-To: <7e071b34937fe58e9523ac4be56ece689b1248ae@i2pn2.org> Content-Language: en-US X-Antivirus: Norton (VPS 250424-14, 4/24/2025), Outbound message X-Antivirus-Status: Clean Bytes: 7296 On 4/24/2025 6:26 PM, Richard Damon wrote: > On 4/24/25 5:19 PM, olcott wrote: >> On 4/24/2025 5:53 AM, Richard Damon wrote: >>> On 4/23/25 11:40 PM, olcott wrote: >>>> On 4/23/2025 10:34 PM, olcott wrote: >>>>> 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. >>>>>> >>>>> >>>>> It *is not* up to the point where HHH stops simulating. >>>>> >>>>> It is up to the point where the simulated versus directly >>>>> executed calls HHH(DD). >>>>> >>>>> This call immediately from the directly executed DD and >>>>> cannot possibility return from DD emulated by HHH according >>>>> to the finite string transformation rules of the x86 language. >>>>> >>>> >>>> According to the finite string transformation rules of the x86 >>>> language. >>>> The call from the directly executed DD to HHH(DD) immediately returns. >>>> The call from DD emulated by HHH to HHH(DD) cannot possibility return. >>> >>> >>> According to the rules of the x86 language, your provided input is >>> invalid as it references code outside the input. PERIOD. >>> >> >> *Repetition seems to help you overcome your ADD* >> >> I have told you that the whole Halt.obj is in scope >> for every function in Halt.c several times now. >> > > And thus there is only every that ONE HHH, so HHH *NEVER* correctly > emulates it input, *At least you will quit STUPIDLY saying that HHH is undefined* *At least you will quit STUPIDLY saying that HHH is undefined* *At least you will quit STUPIDLY saying that HHH is undefined* *At least you will quit STUPIDLY saying that HHH is undefined* *At least you will quit STUPIDLY saying that HHH is undefined* -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer