Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: dbush 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: References: <0a2eeee6cb4b6a737f6391c963386745a09c8a01@i2pn2.org> <4818688e0354f32267e3a5f3c60846ae7956bed2@i2pn2.org> <65dddfad4c862e6593392eaf27876759b1ed0e69@i2pn2.org> 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: 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? >>> >>> >>>      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. >>> >>> >> >> 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.