Deutsch   English   Français   Italiano  
<vuon92$3dd6e$15@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!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 apply finite string
 transformations to inputs +++
Date: Mon, 28 Apr 2025 16:09:08 -0400
Organization: A noiseless patient Spider
Lines: 139
Message-ID: <vuon92$3dd6e$15@dont-email.me>
References: <vu6lnf$39fls$2@dont-email.me> <vugvr3$pke9$8@dont-email.me>
 <4818688e0354f32267e3a5f3c60846ae7956bed2@i2pn2.org>
 <vuj18i$2lf64$6@dont-email.me>
 <f0d3f2e87d9a4e0b0f445f60a33d529f41a4fcf7@i2pn2.org>
 <vuj55m$2lf64$10@dont-email.me> <vuj8h3$2uahf$3@dont-email.me>
 <vujfuu$35hcg$1@dont-email.me>
 <65dddfad4c862e6593392eaf27876759b1ed0e69@i2pn2.org>
 <vujlj0$3a526$1@dont-email.me> <vujln7$32om9$8@dont-email.me>
 <vujmmm$3a526$2@dont-email.me> <vujmrj$32om9$9@dont-email.me>
 <vujtcb$3gsgr$1@dont-email.me> <vuju44$3hnda$1@dont-email.me>
 <vuk47o$3qkbb$1@dont-email.me> <vuk6b6$3l184$1@dont-email.me>
 <vuls34$1bf1j$4@dont-email.me> <vun87k$2m24h$2@dont-email.me>
 <vunb06$2fjjl$5@dont-email.me> <vuo57j$3h5l9$2@dont-email.me>
 <vuoath$3ljma$1@dont-email.me> <vuohgi$3td7u$1@dont-email.me>
 <vuoied$3dd6e$7@dont-email.me> <vuoj3v$3td7u$4@dont-email.me>
 <vuojkq$3dd6e$9@dont-email.me> <vuolso$1pcj$1@dont-email.me>
 <vuomlg$3dd6e$12@dont-email.me> <vuomum$2gnd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 28 Apr 2025 22:09:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="67af223ffcc413f8c29b457017b45374";
	logging-data="3585230"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19spwY+/9mLDiem1+SW/GXM"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:K9FWE5OGzh0jLaqz7Nm06gyhdcM=
Content-Language: en-US
In-Reply-To: <vuomum$2gnd$1@dont-email.me>
Bytes: 7194

On 4/28/2025 4:03 PM, olcott wrote:
> On 4/28/2025 2:58 PM, dbush wrote:
>> On 4/28/2025 3:45 PM, olcott wrote:
>>> On 4/28/2025 2:07 PM, dbush wrote:
>>>> On 4/28/2025 2:58 PM, olcott wrote:
>>>>> On 4/28/2025 1:46 PM, dbush wrote:
>>>>>> On 4/28/2025 2:30 PM, olcott wrote:
>>>>>>> On 4/28/2025 11:38 AM, Richard Heathfield wrote:
>>>>>>>> On 28/04/2025 16:01, olcott wrote:
>>>>>>>>> On 4/28/2025 2:33 AM, Richard Heathfield wrote:
>>>>>>>>>> On 28/04/2025 07:46, Fred. Zwarts wrote:
>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>> So we agree that no algorithm exists that can determine for 
>>>>>>>>>>> all possible inputs whether the input specifies a program 
>>>>>>>>>>> that (according to the semantics of the machine language) 
>>>>>>>>>>> halts when directly executed.
>>>>>>>>>>> Correct?
>>>>>>>>>>
>>>>>>>>>> Correct. We can, however, construct such an algorithm just as 
>>>>>>>>>> long as we can ignore any input we don't like the look of.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The behavior of the direct execution of DD cannot be derived
>>>>>>>>> by applying the finite string transformation rules specified
>>>>>>>>> by the x86 language to the input to HHH(DD). This proves that
>>>>>>>>> this is the wrong behavior to measure.
>>>>>>>>>
>>>>>>>>> It is the behavior THAT IS derived by applying the finite
>>>>>>>>> string transformation rules specified by the x86 language
>>>>>>>>> to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.
>>>>>>>>
>>>>>>>> The x86 language is neither here nor there. 
>>>>>>>
>>>>>>> Computable functions are the formalized analogue
>>>>>>> of the intuitive notion of algorithms, in the sense
>>>>>>> that a function is computable if there exists an
>>>>>>> algorithm that can do the job of the function, i.e.
>>>>>>> *given an input of the function domain it*
>>>>>>> *can return the corresponding output*
>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>
>>>>>>> *Outputs must correspond to inputs*
>>>>>>>
>>>>>>> *This stipulates how outputs must be derived*
>>>>>>> Every Turing Machine computable function is
>>>>>>> only allowed to derive outputs by applying
>>>>>>> finite string transformation rules to its inputs.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> And no turing machine exists that can derive the following mapping 
>>>>>> (i.e. the mapping is not a computable function), as proven by Linz 
>>>>>> and others:
>>>>>>
>>>>>
>>>>> Because the theory of computation was never previously
>>>>> elaborated to make it clear that Turing computable
>>>>> functions are required to derive their output by applying
>>>>> finite string transformations to their input finite strings.
>>>>>
>>>>
>>>> And no such algorithm can derive this 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
>>>>
>>>>
>>>>> *When we do this then a mapping suddenly appears*
>>>>
>>>> And that mapping is not the halting mapping, therefore the algorithm 
>>>> is not a halt decider.
>>>>
>>>>> DD emulated by HHH according to the finite string
>>>>> transformation rules of the x86 language DOES NOT HALT.
>>>>
>>>> In other words, HHH doesn't map the halting function.
>>>>
>>>>>
>>>>> *a function is computable if there exists an algorithm that can do 
>>>>> the* *job of the function, i.e. given an input of the function 
>>>>> domain it can* *return the corresponding output*.
>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>> And the halting function is not a computable function:
>>>>
>>>
>>> Maybe you have ADD like Richard and can only
>>> pay attention to a point when it is repeated many times
>>>
>>> I just proved that your halting function is incorrect.
>>>
>>
>> Category error.  The halting function below is fully defined, and this 
>> mapping is not computable *as you have explicitly admitted*.
>>
> 
> Neither is the square root of an actual onion computable.

Category error.  There is no correct answer to "the square root of an 
onion", but there is a correct answer to whether any arbitrary algorithm 
X with input Y will halt when executed directly.  It's just that there's 
no algorithm that can tell us that, as Linz show and you have 
*explicitly* agreed is correct.

> 
> Turing Computable Functions 

i.e. mathematical mappings for which an algorithm exists which can 
compute them.

> are required to apply finite
> string transformations to their inputs. 

Category error.  Mathematical mappings don't have behavior.  They are 
simply pairings from an input domain to an output domain.


> The function defined
> below ignores that requirement PROVING THAT IT IS INCORRECT.

Category error, as mathematical mappings don't have behavior.

> 
>>
>> Given any algorithm (i.e. a fixed immutable sequence of instructions) 
>> X described as <X> with input Y:
>>
>> (<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
>>
>>
>>
> 
>