Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!border-1.nntp.ord.giganews.com!nntp.giganews.com!local-2.nntp.ord.giganews.com!Xl.tags.giganews.com!local-1.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 29 Apr 2025 00:22:12 +0000
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Subject: Re: Turing Machine computable functions apply finite string
 transformations to inputs
Newsgroups: comp.theory
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>
X-Mozilla-News-Host: news://man.com
Date: Tue, 29 Apr 2025 01:22:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
MIME-Version: 1.0
In-Reply-To: <KvSdnTEjuOT7x5P1nZ2dnZfqlJydnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <sUydndwmjqgpho31nZ2dnZfqnPWdnZ2d@brightview.co.uk>
Lines: 257
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-KHqZ5mVKNRTt3wc8WC/RF21OYSWyAr7Xv3o3Gr/l5/0P4advA4D8/2hiF/lPnwmrn00OWVzkJpONR65!kRHmfbsV12nV9cYvxBbQZhGRKSQUS1OQUmxgmibkut6pxtz/yNTZGmRCg0t0n7eurHp8yJT77omP!8Zyt/IhYICsV9t75uYJmDEJkSLw=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40

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.
>>>
>>> Since there is a natural interpretation of those words which would be correct, and relevant to a 
>>> discussion concerning a simulating HD, my GUESS would be that he thought that was what you were 
>>> saying: basically, the D in the quote below is clearly intended to represent *one* *specific* 
>>> input whose halt status is being determined, namely the input D.
>>>
>>> There is talk of "would never stop running if not aborted", which is saying that if H were 
>>> replaced by a UTM (which never aborts its input) THEN UTM(D) WOULD RUN FOREVER.  That amounts to 
>>> the same thing as saying that H has determined [through examination of its simulation steps] that 
>>> D does not halt [when run directly/natively].  Of course if H has determined that D does not 
>>> halt, there's no point in simulating further, and H can just decide "non-halting" straight away.
>>>
>>> NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some modified version of D that 
>>> reflects changes to the embedded copy of modified H internal to D.  The role of D in all this is 
>>> /data/ viz the string representing the particular D being discussed.  The role of H is /code/, H 
>>> being the halt decider deciding the input D.  D does not change when applying the "simulated D 
>>> would never stop unless aborted", or imagining whatever hypothetical changes to H you are 
>>> thinking of - only code of H is being (hypothetically) changed.
>>
>> I suppose I should have made this clear, as you get confused by this point - The TM description D 
>> which is not changing, includes the [TM description of the] embedded copy of [original] H.  I.e. H 
>> without any of your hypothetical imagined changes.
>>
>> Much better still, stop imagining hypothetical changes to things and phrase things by introducing 
>> new objects with new names when required, so that a given name always means the same thing....
========== REMAINDER OF ARTICLE TRUNCATED ==========