Re: Turing Computations <are> finite string transformations of inputs

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

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.

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