Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
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: <vv18t5$3ra6l$5@dont-email.me>
References: <TuuNP.2706011$nb1.2053729@fx01.ams4>
 <87cyd5182l.fsf@nosuchdomain.example.com> <vu6lnf$39fls$2@dont-email.me>
 <vugddv$b21g$2@dont-email.me> <vui4uf$20dpc$1@dont-email.me>
 <vuivtb$2lf64$3@dont-email.me> <vungtl$2v2kr$1@dont-email.me>
 <vuoaac$3jn5n$5@dont-email.me> <vuq81v$1hjka$1@dont-email.me>
 <vutefq$gmbi$3@dont-email.me>
 <991dde3a60e1485815b789520c7149e7842d18f2@i2pn2.org>
 <vuti3c$jq57$1@dont-email.me> <vutmr6$nvbg$2@dont-email.me>
 <vutv7r$v5pn$4@dont-email.me> <vuu73m$151a8$3@dont-email.me>
 <vuuej8$1cqp7$1@dont-email.me> <vuur2n$1qe3m$2@dont-email.me>
 <vv0352$2ur4q$1@dont-email.me> <vv0kpi$3djh5$1@dont-email.me>
 <vv13ro$3r3ei$1@dont-email.me> <vv160a$3smj7$1@dont-email.me>
 <vv169j$3ra6l$3@dont-email.me> <vv1700$3tln6$1@dont-email.me>
 <vv17to$3ra6l$4@dont-email.me> <vv18m5$3tln6$2@dont-email.me>
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: <vv18m5$3tln6$2@dont-email.me>

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 <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
>>>>
>>>>
>>>
>>> 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.