Re: Turing Machine computable functions apply finite string transformations to inputs VERIFIED FACT

On 4/28/2025 10:50 PM, olcott wrote:

On 4/28/2025 3:13 PM, Richard Heathfield wrote:

On 28/04/2025 19:30, olcott wrote:

On 4/28/2025 11:38 AM, Richard Heathfield wrote:

On 28/04/2025 16:01, olcott wrote:

On 4/28/2025 2:33 AM, Richard Heathfield wrote:

On 28/04/2025 07:46, Fred. Zwarts wrote:
>
<snip>
>

So we agree that no algorithm exists that can determine for all possible inputs whether the input specifies a program that (according to the semantics of the machine language) halts when directly executed.
Correct?

>
Correct. We can, however, construct such an algorithm just as long as we can ignore any input we don't like the look of.
>

>
The behavior of the direct execution of DD cannot be derived
by applying the finite string transformation rules specified
by the x86 language to the input to HHH(DD). This proves that
this is the wrong behavior to measure.
>
It is the behavior THAT IS derived by applying the finite
string transformation rules specified by the x86 language
to the input to HHH(DD) proves that THE EMULATED DD NEVER HALTS.

>
The x86 language is neither here nor there.

>
Computable functions are the formalized analogue
of the intuitive notion of algorithms, in the sense
that a function is computable if there exists an
algorithm that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
>
*Outputs must correspond to inputs*
>
*This stipulates how outputs must be derived*
Every Turing Machine computable function is
only allowed to derive outputs by applying
finite string transformation rules to its inputs.

>
In your reply to my article, you forgot to address what I actually wrote. I'm not sure you understand what 'reply' means.
>
Still, I'm prepared to give you another crack at it. Here's what I wrote before:
>
What matters is whether a TM can be constructed that can accept an arbitrary TM tape P and an arbitrary input tape D and correctly calculate whether, given D as input, P would halt. Turing proved that such a TM cannot be constructed.
>
This is what we call the Halting Problem.
>

 Yet it is H(P,D) and NOT P(D) that must be measured.

Not if it's the behavior of P(D) we want to know about, which it is.

 *This is a verified fact*
When DD is emulated by HHH according to the finite
string transformation rules of the x86 language

False, because the x86 language says that any instruction other than a HLT must be followed by the next instruction.  That means the last instruction emulated before aborting wasn't emulated correctly.

DD cannot possibly reach its own final state no
matter what HHH does.

Category error.  Algorithms do one thing and one thing only, so there is no "no mater what HHH does".

 

Whatever you think you've proved, you haven't solved the Halting Problem. There are *no* solutions. We know this because there is a simple well-known proof. So the only way to devise a solution is to re- define the problem.
>

 It ultimately is only a confused view because key
details about how outputs are made to conform to
inputs:
 Turing machines apply finite string transformations
to finite string inputs.

And no Turing machine exists that satisfies the below requirements, as Linz proved and you *explicitly* agreed with:
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

 

And that's fine. If that's what floats your boat, you can re-define it as much as you like. But any proofs you may devise apply not to the Halting Problem but to the Olcott problem.
>
>

 You aren't paying enough attention because you
are too sure that I am wrong. I proved my point
above.