Deutsch English Français Italiano |
<vutuhv$v5pn$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: dbush <dbush.mobile@gmail.com> Newsgroups: comp.theory Subject: Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Ignoramus !!! Date: Wed, 30 Apr 2025 15:44:00 -0400 Organization: A noiseless patient Spider Lines: 117 Message-ID: <vutuhv$v5pn$2@dont-email.me> References: <vsnchj$23nrb$2@dont-email.me> <vtajkf$10asg$2@dont-email.me> <vtbe3g$1vs00$1@dont-email.me> <852f89c9196e0261b8156050fea4572fe886933f@i2pn2.org> <vth52t$3in23$9@dont-email.me> <vth557$3a127$7@dont-email.me> <vth8lr$3n2du$2@dont-email.me> <a8ab995b650b894cbfb635478f7406c4eee4d187@i2pn2.org> <vthqtc$5g2e$2@dont-email.me> <63af93cb608258cc3e12b9bab3a2efa0b7ee7eee@i2pn2.org> <vtit6a$15e5s$3@dont-email.me> <vtivmo$19aqd$1@dont-email.me> <vtkc4l$2h48g$3@dont-email.me> <vtkdnm$2iqu5$1@dont-email.me> <vtkkge$2si58$2@dont-email.me> <vtl56j$3aajg$1@dont-email.me> <vtlu0a$3vgp0$1@dont-email.me> <vtm04f$2a90$1@dont-email.me> <vtm9q8$aut7$1@dont-email.me> <vtmah8$2a90$2@dont-email.me> <vtmgen$gs48$1@dont-email.me> <vtmh1n$2a90$3@dont-email.me> <vto4vh$23i07$1@dont-email.me> <vto7qu$267in$1@dont-email.me> <vtopqv$2meit$1@dont-email.me> <vung5v$2uf19$1@dont-email.me> <vuo87d$3jn5n$3@dont-email.me> <vuq7bm$1gtva$1@dont-email.me> <vutfj1$gmbi$5@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 30 Apr 2025 21:43:59 +0200 (CEST) Injection-Info: dont-email.me; posting-host="36c3ab966607e6b458aa2826fcd1def6"; logging-data="1021751"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19QGINXNDLSXVFN3VM+68y+" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:iyAGiSVwDqDOsfFXD1QcGQModm8= Content-Language: en-US In-Reply-To: <vutfj1$gmbi$5@dont-email.me> On 4/30/2025 11:28 AM, olcott wrote: > On 4/29/2025 4:49 AM, Mikko wrote: >> On 2025-04-28 15:52:13 +0000, olcott said: >> >>> On 4/28/2025 4:01 AM, Mikko wrote: >>>> On 2025-04-16 17:36:31 +0000, olcott said: >>>> >>>>> On 4/16/2025 7:29 AM, Richard Heathfield wrote: >>>>>> On 16/04/2025 12:40, olcott wrote: >>>>>>> sum(3,2) IS NOT THE SAME AS sum(5,2). >>>>>>> IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO >>>>>>> GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION >>>>>>> INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS. >>>>>> >>>>>> Whether sum(3,2) is or is not the same as sum(5,2) is not the >>>>>> question. The question is whether a universal termination analyser >>>>>> can be constructed, and the answer is that it can't. >>>>>> >>>>>> This has been rigorously proved. If you want to overturn the proof >>>>>> you've got your work cut out to persuade anyone to listen, not >>>>>> least because anyone who tries to enter into a dialogue with you >>>>>> is met with contempt and scorn. >>>>>> >>>>>> The proof stands. >>>>>> >>>>> >>>>> *corresponding output to the input* >>>>> *corresponding output to the input* >>>>> *corresponding output to the input* >>>>> *corresponding output to the input* >>>>> *corresponding output to the input* >>>>> >>>>> Not freaking allowed to look at any damn thing >>>>> else besides the freaking input. Must compute whatever >>>>> mapping ACTUALLY EXISTS FROM THIS INPUT. >>>> >>>> A halt decider is is not allowed to compute "whatever" mapping. It is >>>> required to compute one specific mapping: to "no" if the computation >>>> described by the input can be continesd forever without halting, to >>>> "no" otherwise. >>> >>> It must do this by applying the finite string transformation >>> rules specified by the x86 language to the input to HHH(DD). >> >> No, it needn't. A halt decider cannot do other than certain finite string >> operations. No relation to x86 language is required. >> >>> This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD. >> >> Whether the execution is "direct" or otherwise is irrelevant. A >> computation >> either halts or not. A halt decider must just tell whether the >> somputation >> halts. It is true that no Turing machine can determine this about every >> computation, i.e., no Turing machine is a halt decider. >> >>> It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE >>> EMULATION OF HHH EMULATING ITSELF EMULATING DD. >> >> Which are not mentioned in the halting problem. >> > > When understand rather than simply ignore the HHH/DD > example it can be seen that every conventional halting > problem proof Which starts with the assumption that these requirements can be met: Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y: A solution to the halting problem is an algorithm H that computes the following mapping: (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly > suffers the same fate. The contradictory > part of the "impossible" input IS NEVER REACHABLE. And because there is a contradiction, the assumption that the above requriements can be met is is proven false, as show by Linz and you have *explictly* agreed is correct. > > int DD() > { > int Halt_Status = HHH(DD); > if (Halt_Status) > HERE: goto HERE; > return Halt_Status; > } > > It took several C programmers only a few minutes to see this. > The same thing applies to the Peter Linz proof. > > Unlike the HHH/DD example the Linz proof lacks a fully > specified termination analyzer written in a language that > has a complete definition. Irrelavant, because *no* assumptions are made about how HHH is implemented. > > Replacing the code of HHH with an unconditional simulator and > subsequently running HHH(DD) according to the finite string > transformation rules of the x86 language DOES NOT HALT! > Obviously, but that changes the input. Changing the input is not allowed.