| Deutsch English Français Italiano |
|
<76b61b4a12875ac8e1f2254be22f1f791df848ea@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
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:04:05 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <76b61b4a12875ac8e1f2254be22f1f791df848ea@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>
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:38 -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: <vv160a$3smj7$1@dont-email.me>
On 5/1/25 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.
You mean you are admitting that you didn't understand that this
relationships HAS been precisely definied?
>
> Specific finite string transformation rules are
> applied to inputs to derive outputs.
That is what an algorithm can do. It isn't how a Function works.
Something you have demonstrated you failure to understand.
Perhaps the problem is that "Functions" in Computation Theory are sort
of abstract stating results without needing to specify hwo they are
gotten. We can specify how, but it is not limited by the rules of
algorithms, since not all Functions are computable.
>
> 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).\
No, people have been looking at the DEFINITIONS. Something you don't
seem to understand.
>
> DD correctly emulated by HHH maps to NON-HALTING BEHAVIOR.
> It really does, all that you have to do is PAY ATTENTION.
But since HHH doesn't correctly emulate DD, you are just showing that
you "logic" is based on lying about false premises.
Sorry, this seems to be your novel concept, that we can just make up
what we want and lie about things.
>
>> To understand what a halt decider does you need to first understand
>> what the halting function is. And to understand that, you must first
>> understand what a function is. You clearly do not.
>>
>> André
>>
>
>