Deutsch   English   Français   Italiano  
<vun0cl$2ett4$2@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: Sun, 27 Apr 2025 23:32:21 -0500
Organization: A noiseless patient Spider
Lines: 143
Message-ID: <vun0cl$2ett4$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 28 Apr 2025 06:32:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cc4092dca5685a99a96dd309586b7dc0";
	logging-data="2586532"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+w+SC3A4DJudWCXm5OIptX"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cYts7p4iQEX0cnxtT7JfaZPn7aI=
In-Reply-To: <vulv07$1do22$5@dont-email.me>
X-Antivirus: Norton (VPS 250427-6, 4/27/2025), Outbound message
Content-Language: en-US
X-Antivirus-Status: Clean
Bytes: 7980

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.

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer