Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Turing Machine computable functions MUST apply finite string
 transformations to inputs
Date: Thu, 1 May 2025 22:08:22 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <d1b7f196263e13fab5184de5e1019960e4357ab4@i2pn2.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 2 May 2025 02:08:39 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2752403"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <vv1700$3tln6$1@dont-email.me>

On 5/1/25 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 because no one
> actually took into account the exact details of
> HOW inputs are mapped to OUTPUTS.


No, YOU are incoherent as you don't understand the nature of what you 
are talking about.

> 
> When you stupidly ask for an INCORRECT mapping
> that does not entail any actual limit to computation.

No, you don't know the definiton of a correct mapping, because you chose 
to make yourself ignorant and thus stupid about the field.

> 
> *DD correctly emulated by HHH DOES NOT HALT*
> *DD correctly emulated by HHH DOES NOT HALT*
> *DD correctly emulated by HHH DOES NOT HALT*
> 

Your specified HHH doesn't correctly emulate DD, so you are shown to 
just be a pathetic pathological liar who is totally ignorant of what he 
is talking about.