Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1 Date: Sat, 29 Mar 2025 14:50:51 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <4e934be3dc06717c9411d5e73d58796bce7647cf@i2pn2.org> References: <3ee338aad3b49626722d917050e06afa1f6c46b9@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 29 Mar 2025 18:54:33 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2291387"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: Bytes: 7568 Lines: 130 On 3/29/25 2:47 PM, olcott wrote: > On 3/29/2025 4:14 AM, joes wrote: >> Am Fri, 28 Mar 2025 22:45:58 -0500 schrieb olcott: >>> On 3/28/2025 9:36 PM, Richard Damon wrote: >>>> On 3/28/25 10:13 PM, olcott wrote: >>>>> On 3/28/2025 8:08 PM, Richard Damon wrote: >>>>>> On 3/28/25 6:38 PM, olcott wrote: >>>>>>> On 3/28/2025 5:30 PM, dbush wrote: >>>>>>>> On 3/28/2025 6:09 PM, olcott wrote: >>>>>>>>> On 3/28/2025 3:38 PM, dbush wrote: >>>>>>>>>> On 3/28/2025 4:30 PM, olcott wrote: >>>>>>>>>>> On 3/28/2025 2:24 PM, dbush wrote: >>>>>>>>>>>> On 3/28/2025 3:21 PM, olcott wrote: >>>>>>>>>>>>> On 3/28/2025 4:43 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>> Op 28.mrt.2025 om 03:13 schreef olcott: >>>>>>>>>>>>>>> On 3/27/2025 9:04 PM, Richard Damon wrote: >>>>>>>>>>>>>>>> On 3/27/25 9:07 PM, olcott wrote: >>>>>>>>>>>>>>>>> On 3/27/2025 7:38 PM, dbush wrote: >>>>>>>>>>>>>>>>>> On 3/27/2025 8:34 PM, olcott wrote: >>>>>>>>>>>>>>>>>>> On 3/27/2025 7:12 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>> On 3/27/2025 8:11 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>> On 3/27/2025 7:02 PM, dbush wrote: >> >>>>>>>>>>>>>>>>>>> I corrected your error dozens of times and you ignore >>>>>>>>>>>>>>>>>>> these corrections and mindlessly repeat your error like >>>>>>>>>>>>>>>>>>> a bot >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Which is what you've been doing for the last three years. >>>>>>>>>>>>>>>>>> Projection, as always.  I'll add the above to the list. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TM's cannot possibly ever report on the behavior of the >>>>>>>>>>>>>>>>> direct execution of another TM. I proved this many times >>>>>>>>>>>>>>>>> in may ways. Ignoring these proofs IT NOT ANY FORM OF >>>>>>>>>>>>>>>>> REBUTTAL. >> They can report *about* it, by deriving from the description. >> >>>>>>>>>>>>>>>> Sure they can. >>>>>>>>>>>>>>>> WHere is your proof? And what actual accepted principles is >>>>>>>>>>>>>>>> is based on? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No TM can take another directly executed TM as an input and >>>>>>>>>>>>>>> Turing computable functions only compute the mapping from >>>>>>>>>>>>>>> inputs to outputs. >> Nobody said otherwise. >> >>>>>>>>>>>>>> If A TM can only compute the mapping from *its* input to >>>>>>>>>>>>>> *its* output, it cannot be wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> Taking a wild guess does not count as computing the mapping. >> Not if the guess is always right. >> >>>>>>>>>>>> False.  The only requirement is to map a member of the input >>>>>>>>>>>> domain to a member of the output domain as per the >>>>>>>>>>>> requirements. >>>>>>>>>>>> If it does so in all cases, the mapping is computed.  It >>>>>>>>>>>> doesn't matter how it's done. >>>>>>>>>>>> >>>>>>>>>>> Unless an input is transformed into an output on the basis of a >>>>>>>>>>> syntactic or semantic property of this input it is not a Turing >>>>>>>>>>> computable function. >>>>>>>>>>> int StringLength(char *S) >>>>>>>>>>> { >>>>>>>>>>>     return 5; >>>>>>>>>>> } >>>>>>>>>>> Does not compute the string length of any string. >>>>>>>>>>> >>>>>>>>>> False.  It computes the length of all strings of length 5. >>>>>>>>> It does not compute (a sequence of steps of an algorithm that >>>>>>>>> derive an output on the basis of an input) jack shit it makes a >>>>>>>>> guess. >> There is no notion of relevance here, even if you don't like it. A >> computation is purely mechanical. This function is definitely computable, >> you even gave an implementation! >> >>>>>>>> Doesn't matter. If the requirement is to return 5 for strings that >>>>>>>> have a length of 5, it meets the requirement. >>>>>>> >>>>>>> The actual requirement is to compute the mapping from a finite >>>>>>> string to its length using a sequence of algorithmic steps. >>>>>>> Likewise for halting. Compute the mapping from a finite string of >>>>>>> machine code to the behavior that this finite string specifies. >> You seem to think the same string could specify many things. >> >>>>>> With that specifcation DEFINED as the behavior of the machine >>>>>> described when it is actually run. >>>>>> >>>>> In other words the halting problem is defined to not be allowed to use >>>>> computable functions and it is this screwball definition that prevents >>>>> the halting function from being Turing computable. >> wtf no. What functions are you talking about? The successive states >> (incl. >> tape) of a TM are entirely computable. >> >>>> The Halting Problem DEFINES THE FUNCTION. >>>> >>> It defines that it must compute the mapping from the direct execution of >>> a Turing Machine contradicting the fact that the direct execution of a >>> TM cannot possibly be an input to a TM. >> >> Jesus, can't y'all shorten your replies a little, this is not a forum. >> >> The function does not define anything about how the "mapping" is done; > > Except that it must figure out something that the > input finite string actually specifies. > > int sum(int x, int y) > { >   return 5; > } > > Is not computable function even for sum(2,3). Sure it is, is the function sum(x, y) -> 5 That is a function. Functions are allowed to ignore some (or all) of their inputs. > >> there need not be any recognisable derivation. The impossible halting >> decider should only give the correct result, how it does so is >> irrelevant. >> The mapping is *obviously* not from a TM in execution (whatever is that?) >> but from its description (which is one-to-one). That's a really silly >> strawman. The mapping must be *to* the direct execution, nothing easier >> than that. >> > >