Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: Functions computed by Turing Machines MUST apply finite string transformations to inputs Date: Thu, 1 May 2025 22:57:48 -0500 Organization: A noiseless patient Spider Lines: 166 Message-ID: References: <87cyd5182l.fsf@nosuchdomain.example.com> <991dde3a60e1485815b789520c7149e7842d18f2@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 02 May 2025 05:57:50 +0200 (CEST) Injection-Info: dont-email.me; posting-host="d126058d758b45651ab4999adf43b644"; logging-data="302649"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WHTY1aYCMiYXVWyqecozk" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:wZV3qpjfuJrSqKmLqcm16NHBHHY= X-Antivirus: Norton (VPS 250501-8, 5/1/2025), Outbound message X-Antivirus-Status: Clean In-Reply-To: Content-Language: en-US On 5/1/2025 9:40 PM, dbush wrote: > On 5/1/2025 10:34 PM, olcott wrote: >> On 5/1/2025 8:58 PM, André G. Isaak wrote: >>> On 2025-05-01 19:09, olcott wrote: >>>> On 5/1/2025 7:32 PM, André G. Isaak wrote: >>>>> On 2025-05-01 14:15, olcott wrote: >>>>>> On 5/1/2025 10:14 AM, André G. Isaak wrote: >>>>>>> On 2025-04-30 21:50, olcott wrote: >>>>>>>> On 4/30/2025 7:17 PM, André G. Isaak wrote: >>>>>>> >>>>>>>>> You are still hopelessly confused about your terminology. >>>>>>>>> >>>>>>>>> Computable functions are a subset of mathematical functions, >>>>>>>>> and mathematical functions are *not* the same thing as C >>>>>>>>> functions. Functions do not apply "transformations". They are >>>>>>>>> simply mappings, and a functions which maps every pair of >>>>>>>>> natural numbers to 5 is a perfectly legitimate, albeit not very >>>>>>>>> interesting, function. >>>>>>>>> >>>>>>>>> What makes this function a *computable function* is that fact >>>>>>>>> that it is possible to construct a C function (or a Turing >>>>>>>>> Machine, or some other type of algorithm) such as int foo(int >>>>>>>>> x, int y) {return 5;} which computes that particular function; >>>>>>>>> but the C function and the computable function it computes are >>>>>>>>> entirely separate entities. >>>>>>>> >>>>>>>> computes the sum of two integers >>>>>>>> by transforming the inputs into an output. >>>>>>>> int sum(int x, int y) { return x + y; } >>>>>>>> >>>>>>>> Computes no function because it ignores its inputs. >>>>>>>> int sum(int x, int y) { return 5; } >>>>>>> >>>>>>> All you're demonstrating here is that you have no clue what a >>>>>>> function is, nor, apparently, do you have any desire to learn. >>>>>>> >>>>>>> André >>>>>>> >>>>>> >>>>>> What I am explaining is that a halt decider >>>>>> must compute the mapping FROM THE INPUTS ONLY >>>>>> by applying a specific set of finite string >>>>>> transformations to the inputs. >>>>> >>>>> No. Halt deciders weren't even mentioned above. I was addressing >>>>> your absurd claim that int foo(int x, int y) { return 5; } does not >>>>> compute a function. This clearly indicates that you do not grasp >>>>> the concept of "function". >>>>> >>>> >>>> This is a brand new elaboration of computer >>>> science that I just came up with. >>> >>> IOW something you've pulled out of your ass. >>> >>>> It is common knowledge THAT inputs must correspond >>>> to OUTPUTS. What is totally unknown and brand new >>>> created by me is HOW inputs are made to correspond >>>> to OUTPUTS. >>> >>> We were discussing functions. Functions don't have inputs or outputs; >>> they have domains and codomains. ALGORITHMS have inputs and outputs, >>> and you keep conflating the two. >>> >>>> Specific finite string transformation rules are >>>> applied to inputs to derive outputs. >>> >>> Please point to a definition of 'function' which mentions "finite >>> string transformation rules". This may be a useful way of viewing >>> some (but certainly not all) algorithms, but it has nothing to do >>> with functions. Functions are simply a mapping from one set (the >>> domain) to another set (the codomain) such that every element of the >>> domain maps to one and only one element of the codomain. >>> >>>> What everyone else has been doing is simply GUESSING >>>> that they correspond or relying on some authority >>>> that say they must correspond. (Appeal to authority error). >>> >>> This is another baseless assertion that you've simply pulled out of >>> your ass. If you think otherwise, please provide a concrete example >>> >>>> DD correctly emulated by HHH maps to NON-HALTING BEHAVIOR. >>>> It really does, all that you have to do is PAY ATTENTION. >>> >>> Whether DD emulated by HH maps to halting or non-halting behaviour is >>> entirely dependent on which function is being computed. >>> >>> André >>> >> >> We are computing the halt function > > i.e. this function: > > > Given any algorithm (i.e. a fixed immutable sequence of instructions) X > described as with input Y: > > (,Y) maps to 1 if and only if X(Y) halts when executed directly > (,Y) maps to 0 if and only if X(Y) does not halt when executed directly > > > Which has been proven to be uncomputable, as shown by Linz and as you > have *explicitly* agreed is correct. > >> FOR THE INPUT NOT ANY DAMN THING ELSE >> FOR THE INPUT NOT ANY DAMN THING ELSE >> FOR THE INPUT NOT ANY DAMN THING ELSE >> FOR THE INPUT NOT ANY DAMN THING ELSE >> >> FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG >> FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG >> FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG >> >> int DD() >> { >>    int Halt_Status = HHH(DD); >>    if (Halt_Status) >>      HERE: goto HERE; >>    return Halt_Status; >> } >> >> Replacing the code of HHH with an unconditional simulator and >> subsequently running HHH(DD) specifies recursive >> simulation such that DD cannot possibly reach its >> "return instruction" (final halt state). Thus HHH >> is correct to reject DD as non halting. > > So you changed the input.  Changing the input is not allowed. > I never changed the input. >> >> >>      If simulating halt decider H correctly simulates its input D >>      until H correctly determines that its simulated D would never >>      stop running unless aborted then >> >>      H can abort its simulation of D and correctly report that D >>      specifies a non-halting sequence of configurations. >> >> >> > > And *yet again* you lie by implying that Sipser agrees with you when > it's been proven *on multiple occasions* that he does not: > Professor Sipser gave me permission to quote those words above Ben verified that too. Assuming the those words are true I AM PROVED CORRECT. Why would professor Sipser agree with words that are not true? > On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: > > I exchanged emails with him about this. He does not agree with anything > > substantive that PO has written. I won't quote him, as I don't have > > permission, but he was, let's say... forthright, in his reply to me. > > Your dishonesty knows no bounds. -- ========== REMAINDER OF ARTICLE TRUNCATED ==========