Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Turing Computations <are> finite string transformations of inputs
Date: Mon, 28 Apr 2025 07:48:39 -0400
Organization: A noiseless patient Spider
Lines: 127
Message-ID: <vunpul$37b0f$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> <vuh2a3$tkor$1@dont-email.me>
 <vuhjsk$1h0ma$1@dont-email.me> <vujhmf$36iqv$1@dont-email.me>
 <vujj6s$35hcg$6@dont-email.me> <vujm3c$397q3$1@dont-email.me>
 <vujn04$3a526$3@dont-email.me> <vukio6$646h$5@dont-email.me>
 <vulu92$1bf1j$9@dont-email.me> <vulutv$1do22$4@dont-email.me>
 <vun0vr$2ett4$3@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:48:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="67af223ffcc413f8c29b457017b45374";
	logging-data="3386383"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/6kNbA5CsslonW4uohrh85"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:SwOc5YxJNME75lAJ5socukAHXD4=
In-Reply-To: <vun0vr$2ett4$3@dont-email.me>
Content-Language: en-US

On 4/28/2025 12:42 AM, olcott wrote:
> On 4/27/2025 2:01 PM, dbush wrote:
>> On 4/27/2025 2:50 PM, olcott wrote:
>>> On 4/27/2025 1:27 AM, Fred. Zwarts wrote:
>>>> Op 27.apr.2025 om 00:33 schreef olcott:
>>>>> On 4/26/2025 5:18 PM, André G. Isaak wrote:
>>>>>> On 2025-04-26 15:28, olcott wrote:
>>>>>>> On 4/26/2025 4:03 PM, André G. Isaak wrote:
>>>>>>>> On 2025-04-25 21:28, olcott wrote:
>>>>>>>>> On 4/25/2025 5:28 PM, André G. Isaak wrote:
>>>>>>>>>> On 2025-04-25 10:31, 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.
>>>>>>>>>>
>>>>>>>>>> You're very confused here.
>>>>>>>>>>
>>>>>>>>>> Computable functions are *functions*. That is, they are 
>>>>>>>>>> mappings from a domain to a codomain, neither of which are 
>>>>>>>>>> required to be strings. Functions don't involve finite string 
>>>>>>>>>> operations at all.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> All Turing Machine based computation applies the/
>>>>>>>>> finite string transformations specified by the TM
>>>>>>>>> language to the input finite string.
>>>>>>>>
>>>>>>>> Turing machines and computable functions are not the same thing. 
>>>>>>>> You keep conflating the two. The point of my post was to try to 
>>>>>>>> get you to be more careful with your terminology.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Yes so I must correct my words to say
>>>>>>>
>>>>>>> All Turing Machine based *Computable Functions* apply the
>>>>>>>  >> finite string transformations specified by the TM
>>>>>>>  >> language to the input finite string.
>>>>>>
>>>>>> Which is just as mangled as your earlier usage. Maybe learn what 
>>>>>> these things mean...
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> When HHH emulates DD once and then emulates itself
>>>>> emulating DD according to the finite string transformation
>>>>> rules specified by the x86 language then HHH 
>>>>
>>>> should also analyse Halt7.c and conclude that there is a conditional 
>>>> abort, which makes the recursion finite and thus there is no need to 
>>>> abort the simulation. But HHH fails to do this correct analysis and 
>>>> prematurely aborts the simulation.
>>>
>>> Now it is clear that correct simulation requires that HHH(DD)
>>> apply the finite string transformations specified by the x96
>>> language to its input the nonsense about directed execution
>>
>> Shows that no H exists that satisfies these requirements, as proven by 
>> Linz and others:
>>
>>
>> Given any algorithm (i.e. a fixed immutable sequence of instructions) 
>> X described as <X> with input Y:
>>
>> A solution to the halting problem is an algorithm H that computes the 
>> following mapping:
>>
>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed 
>> directly
>>
>>
>>
>>> <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:
>>
> 
> He must agree with me about correct simulation
> as I have recently repeatedly proven.

Clearly 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.
 >


> 
> When DD is emulated by HHH once and then HHH emulates
> itself emulating DD, then HHH has complete proof that
> and infinite numbers of steps of DD emulated by HHH
> could not cause DD to reaches its own final halt state.

In other words, HHH changes the input.

Changing the input is not allowed.

> 
>> 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.
>