Deutsch English Français Italiano |
<vuplut$11gfd$1@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: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: Turing Machine computable functions apply finite string transformations to inputs Date: Mon, 28 Apr 2025 23:52:44 -0500 Organization: A noiseless patient Spider Lines: 395 Message-ID: <vuplut$11gfd$1@dont-email.me> References: <vu6lnf$39fls$2@dont-email.me> <vua9oi$2lub6$1@dont-email.me> <vudkah$1ona3$1@dont-email.me> <vufi61$3k099$1@dont-email.me> <vugddv$b21g$2@dont-email.me> <0a2eeee6cb4b6a737f6391c963386745a09c8a01@i2pn2.org> <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> <XpecnXs9MtzKApD1nZ2dnZfqnPudnZ2d@brightview.co.uk> <QJ-dnfPs3ckgO5D1nZ2dnZfqn_adnZ2d@brightview.co.uk> <KvSdnTEjuOT7x5P1nZ2dnZfqlJydnZ2d@giganews.com> <sUydndwmjqgpho31nZ2dnZfqnPWdnZ2d@brightview.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 29 Apr 2025 06:52:50 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0b89789aab052ff5f64890600c4ef3d2"; logging-data="1098221"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19iui3TWxDsRx6c41t4LOIg" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:oLkx4lJacAWd3PXmHq392eWbtCs= X-Antivirus: Norton (VPS 250428-8, 4/28/2025), Outbound message X-Antivirus-Status: Clean Content-Language: en-US In-Reply-To: <sUydndwmjqgpho31nZ2dnZfqnPWdnZ2d@brightview.co.uk> Bytes: 19757 On 4/28/2025 7:22 PM, Mike Terry wrote: > On 27/04/2025 17:25, olcott wrote: >> On 4/26/2025 10:38 PM, Mike Terry wrote: >>> On 27/04/2025 04:07, Mike Terry wrote: >>>> On 27/04/2025 01:22, olcott wrote: >>>>> On 4/26/2025 5:31 PM, dbush wrote: >>>>>> On 4/26/2025 6:28 PM, olcott wrote: >>>>>>> On 4/26/2025 5:11 PM, dbush wrote: >>>>>>>> On 4/26/2025 6:09 PM, olcott wrote: >>>>>>>>> On 4/26/2025 4:04 PM, Richard Damon wrote: >>>>>>>>>> On 4/26/25 4:33 PM, olcott wrote: >>>>>>>>>>> On 4/26/2025 1:26 PM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 26.apr.2025 om 19:29 schreef olcott: >>>>>>>>>>>>> On 4/26/2025 12:16 PM, joes wrote: >>>>>>>>>>>>>> Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/25/2025 5:09 PM, joes wrote: >>>>>>>>>>>>>>>> Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 4/25/2025 11:54 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 4/25/25 12:31 PM, olcott wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Once we understand that Turing computable functions >>>>>>>>>>>>>>>>>>> are only allowed >>>>>>>>>>>>>>>>>>> to derived their outputs by applying finite string >>>>>>>>>>>>>>>>>>> operations to >>>>>>>>>>>>>>>>>>> their inputs then my claim about the behavior of DD >>>>>>>>>>>>>>>>>>> that HHH must >>>>>>>>>>>>>>>>>>> report on is completely proven. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Youy have your words wrong. They are only ABLE to use >>>>>>>>>>>>>>>>>> finite >>>>>>>>>>>>>>>>>> algorithms of finite string operations. The problem >>>>>>>>>>>>>>>>>> they need to >>>>>>>>>>>>>>>>>> solve do not need to be based on that, but on just >>>>>>>>>>>>>>>>>> general mappings >>>>>>>>>>>>>>>>>> of finite strings to finite strings that might not be >>>>>>>>>>>>>>>>>> described by a >>>>>>>>>>>>>>>>>> finite algorithm. >>>>>>>>>>>>>>>>>> The mapping is computable, *IF* we can find a finite >>>>>>>>>>>>>>>>>> algorith of >>>>>>>>>>>>>>>>>> transformation steps to make that mapping. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are no finite string operations that can be >>>>>>>>>>>>>>>>> applied to the input >>>>>>>>>>>>>>>>> to HHH(DD) that derive the behavior of of the directly >>>>>>>>>>>>>>>>> executed DD >>>>>>>>>>>>>>>>> thus DD is forbidden from reporting on this behavior. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, there are, the operations that the processor >>>>>>>>>>>>>>>> executes. How did you >>>>>>>>>>>>>>>> think it works? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When you try to actually show the actual steps instead of >>>>>>>>>>>>>>> being stuck in >>>>>>>>>>>>>>> utterly baseless rebuttal mode YOU FAIL! >>>>>>>>>>>>>> Which x86 semantics does a processor violate when deriving >>>>>>>>>>>>>> a halting >>>>>>>>>>>>>> state from the string description of DD? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> When any HHH emulates DD according to the finite string >>>>>>>>>>>>>>> transformation >>>>>>>>>>>>>>> rules specified by the x86 language (the line of >>>>>>>>>>>>>>> demarcation between >>>>>>>>>>>>>>> correct and incorrect emulation) no emulated DD can >>>>>>>>>>>>>>> possibly reach its >>>>>>>>>>>>>>> final halt state and halt. >>>>>>>>>>>>>> Yes, where is that line? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Everyone claims that HHH violates the rules >>>>>>>>>>>>> of the x86 language yet no one can point out >>>>>>>>>>>>> which rules are violated because they already >>>>>>>>>>>>> know that HHH does not violate any rules and >>>>>>>>>>>>> they are only playing trollish head games. >>>>>>>>>>>>> >>>>>>>>>>>>> _DD() >>>>>>>>>>>>> [00002133] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002136] 51 push ecx ; make space for local >>>>>>>>>>>>> [00002137] 6833210000 push 00002133 ; push DD >>>>>>>>>>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD) >>>>>>>>>>>>> [00002141] 83c404 add esp,+04 >>>>>>>>>>>>> [00002144] 8945fc mov [ebp-04],eax >>>>>>>>>>>>> [00002147] 837dfc00 cmp dword [ebp-04],+00 >>>>>>>>>>>>> [0000214b] 7402 jz 0000214f >>>>>>>>>>>>> [0000214d] ebfe jmp 0000214d >>>>>>>>>>>>> [0000214f] 8b45fc mov eax,[ebp-04] >>>>>>>>>>>>> [00002152] 8be5 mov esp,ebp >>>>>>>>>>>>> [00002154] 5d pop ebp >>>>>>>>>>>>> [00002155] c3 ret >>>>>>>>>>>>> Size in bytes:(0035) [00002155] >>>>>>>>>>>>> >>>>>>>>>>>>> DD emulated by HHH according to the finite >>>>>>>>>>>>> string transformation rules of the x86 language >>>>>>>>>>>>> does emulate [00002133] through [0000213c] which >>>>>>>>>>>>> causes HHH to emulate itself emulating DD again >>>>>>>>>>>>> in recursive emulation repeating the cycle of >>>>>>>>>>>>> [00002133] through [0000213c]. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Finite recursion, >>>>>>>>>>> >>>>>>>>>>> Mathematical induction proves that DD emulated by >>>>>>>>>>> any HHH that applies finite string transformation >>>>>>>>>>> rules specified by the x86 language to its input >>>>>>>>>>> no DD can possibly reach its final halt state. >>>>>>>>>> >>>>>>>>>> No, it doesn't, as you can't have an infinte series of a >>>>>>>>>> function that has been defined to be a specific instance. >>>>>>>>>> >>>>>>>>> >>>>>>>>> One recursive emulation of HHH emulating itself emulating >>>>>>>>> DD after DD has already been emulated by DD once conclusively >>>>>>>>> proves that >>>>>>>>> >>>>>>>>> simulated DD would never stop running unless aborted >>>>>>>>> >>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>> 10/13/2022> >>>>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its *simulated D would never* >>>>>>>>> *stop running unless aborted* then >>>>>>>>> >>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>> 10/13/2022> >>>>>>>>> >>>>>>>> >>>>>>>> And again you lie by implying that Sipser agrees with you when >>>>>>>> it has been proven that he doesn't: >>>>>>>> >>>>>>>> >>>>>>>> On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: >>>>>>>> > I exchanged emails with him about this. He does not agree >>>>>>>> with anything >>>>>>>> > substantive that PO has written. I won't quote him, as I >>>>>>>> don't have >>>>>>>> > permission, but he was, let's say... forthright, in his reply >>>>>>>> to me. >>>>>>>> >>>>>>> >>>>>>> That professor Sipser did not have the time to >>>>>>> understand the significance of what he agreed to >>>>>>> does not entail that he did not agree with my >>>>>>> meanings of what he agreed to. >>>>>>> >>>>>>> Professor Sipser did not even have the time to >>>>>>> understand the notion of recursive emulation. >>>>>>> Without this it is impossible to see the significance >>>>>>> of my work. >>>>>> >>>>>> In other words, he did not you agree what you think he agreed to, >>>>>> and your posting the above to imply that he did is a form of lying. >>>>>> >>>>> >>>>> *He agreed to MY meaning of these words* >>>> >>>> He most certainly did not! He presumably agreed to what he / >>>> thought/ you meant by the words. ========== REMAINDER OF ARTICLE TRUNCATED ==========