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