Deutsch English Français Italiano |
<vunprc$37b0f$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: 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 07:46:52 -0400 Organization: A noiseless patient Spider Lines: 147 Message-ID: <vunprc$37b0f$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> <b6fd774a57600defb787252e824051fea412e91d@i2pn2.org> <vulusj$1bf1j$11@dont-email.me> <vulv07$1do22$5@dont-email.me> <vun0cl$2ett4$2@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 13:46:52 +0200 (CEST) Injection-Info: dont-email.me; posting-host="67af223ffcc413f8c29b457017b45374"; logging-data="3386383"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19iFAY8ysxui3tTQf701d5q" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:nT2SrjZi54Lx77xa+V0yDU1+NDU= Content-Language: en-US In-Reply-To: <vun0cl$2ett4$2@dont-email.me> Bytes: 8071 On 4/28/2025 12:32 AM, olcott wrote: > On 4/27/2025 2:02 PM, dbush wrote: >> On 4/27/2025 3:00 PM, olcott wrote: >>> On 4/26/2025 9:07 PM, Richard Damon wrote: >>>> On 4/26/25 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 >>>> >>>> No, because the HHH that DD calls DOES abort, so "unless" isn't a >>>> valid word here. >>> >>> Then why did Professor Sipser and Ben agree to it? >>> >>> <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 *yet again* you lie by implying that Sipser agrees with you when >> it has been repeatedly proven that he does not: >> >> 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. >> > >> >> >> Your dishonesty knows no bounds. >> > > His agreement was only needed for the quoted words. > Which you use to imply that he agrees with you when it's proven he doesn't. That's lying.