Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: dbush Newsgroups: comp.theory Subject: Re: Turing Machine computable functions MUST apply finite string transformations to inputs Date: Thu, 1 May 2025 21:59:02 -0400 Organization: A noiseless patient Spider Lines: 109 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 03:59:02 +0200 (CEST) Injection-Info: dont-email.me; posting-host="bfb965ae000e29628a09f9a13a748901"; logging-data="4040917"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19bUZxParWEmw5wfCzs2ung" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:mEBZMGgXQArS+7gfo3m8hVAvLrs= Content-Language: en-US In-Reply-To: On 5/1/2025 9:55 PM, olcott wrote: > On 5/1/2025 8:42 PM, dbush wrote: >> On 5/1/2025 9:26 PM, olcott wrote: >>> On 5/1/2025 8:14 PM, dbush wrote: >>>> On 5/1/2025 9:09 PM, 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. >>>>> >>>>> 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. >>>>> >>>>> Specific finite string transformation rules are >>>>> applied to inputs to derive outputs. >>>> >>>> In other words, you're simply looking at an algorithm to see what >>>> mapping it computes >>>> >>>>> >>>>> 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). >>>>> >>>> >>>> False.  The halting problem proofs start with the assumption that >>>> the following requirements can be met and that HHH meets them: >>>> >>>> >>>> Given any algorithm (i.e. a fixed immutable sequence of >>>> instructions) X described as with input Y: >>>> >>>> A solution to the halting problem is an algorithm H that computes >>>> the following mapping: >>>> >>>> (,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 >>>> >>>> >>> >>> For all of these years no one ever noticed that >>> those requirements are incoherent >> >> False.  The mapping exists and is well-defined, it's just that no >> algorithm can compute it, as Linz proved and you *explicitly* agreed. >> > > Specify every single step of the mapping In other words, you're assuming that there's an algorithm that computes the mapping. > and you will > see that it has never been well defined. It has ONLY > ever been a leap to a conclusion. And a contradiction is reached. Therefore the assumption that an algorithm exists to compute the mapping is false, as Linz and others have proved and you have *explicitly* agreed is correct.