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

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
for the same reason that the mapping from DD correctly
simulated by HHH to DD(DD) does not exist.
THE MAPPING MUST BE WHAT THE INPUT ACTUALLY SPECIES
NOT MERELY WHAT SOMEONE EXPECTS.

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.

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