Re: Functions computed by Turing Machines MUST apply finite string transformations to inputs +++

On 5/4/2025 1:38 PM, olcott wrote:

On 5/4/2025 11:57 AM, dbush wrote:

On 5/4/2025 12:06 PM, olcott wrote:

On 5/3/2025 4:28 PM, dbush wrote:

On 5/3/2025 3:45 PM, Richard Heathfield wrote:

>
I am conscious that you have already explained to me (twice!) that Mr O's approach is aimed not at overturning the overarching indecidability proof but a mere detail of Linz's proof. Unfortunately, your explanations have not managed to establish a firm root in what passes for my brain. This may be because I'm too dense to grok them, or possibly it's because your explanations are TOAST (see above).
>
You have said, I think, that Olcott doesn't need a universal decider in order to prove his point. But a less ambitious decider doesn't contradict Linz's proof, surely? So once more for luck, what exactly would PO be establishing with his non-universal and impatient simulator if he could only get it to work?

>
The core issue is that PO, despise being nearly 70 and having worked as a programmer, fundamentally doesn't understand proof by contradiction.
>

>
The actual issue is the NO ONE here (or perhaps anywhere)
sufficiently understands the key details about
COMPUTING THE MAPPING FROM AN INPUT TO AN OUTPUT.
>
Many here know that a mapping from the input must be
computed.

>
False.  There is no requirement that a mapping is computable.  The halting function is one such mapping, as Linz and others have proved and you have *explictly* agreed is correct.
>
>

What they don't know are ALL of the tiny
detailed steps required to compute this mapping.
>

>
And if the mapping isn't computable, like the halting function, there are no such steps.
>

 int sum(int x, int y) { return x + y; }
The mapping from sum(3,2) to sum 5 + 6 does not
exist

Category error.  A mapping is an association between an input domain and an output domain, not a C function call to a value.
But there is a mapping from the values X=3 Y=2 to the sum of 5 and 6:
(X,Y) maps to (x+2)+(y+4)
And the above algorithm doesn't compute that mapping

 for the same reason that the mapping from DD correctly
simulated by HHH to DD(DD) does not exist.

Strawman.  No one has asked about such a mapping.  The halting problem is about this mapping:
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

 THE MAPPING MUST BE WHAT THE INPUT ACTUALLY SPECIES
NOT MERELY WHAT SOMEONE EXPECTS.

In other words, you're once again demonstrating that you don't understand proof by contradiction, a concept taught to and understood by high school students over 50 years your junior.

  

They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.

>
A correct simulation is stipulated to be one that exactly matches the behavior of the machine to be simulated.
>
DD is not correctly simulated by HHH, as the last instruction simulated is not simulated correctly, because the x86 language requires any executed instruction other than a HLT to be followed by the execution of the next instruction.
>
We also know that "DD correctly simulated by HHH" is PO-speak for "Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD)", as you have agreed and given permission to replace the former with the later.
>
This means that you're changing the input.
>
Changing the input is not allowed.
>

>
They cannot provide these detailed steps of the
execution trace of each machine instruction showing
exactly how DD correctly emulated by HHH halts
BECAUSE THEY KNOW THAT THEY ARE WRONG AND ONLY PLAYING HEAD GAMES.

>
That you don't understand requirements doesn't make it a head game.