Deutsch   English   Français   Italiano  
<fb4ec8d5da98ed6ce19507d1aefc95d21517bde2@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Turing Machine computable functions apply finite string
 transformations to inputs
Date: Tue, 29 Apr 2025 07:55:25 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <fb4ec8d5da98ed6ce19507d1aefc95d21517bde2@i2pn2.org>
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>
 <vuplut$11gfd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Apr 2025 11:55:50 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2388319"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vuplut$11gfd$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 4/29/25 12:52 AM, olcott wrote:
> 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 ==========