Re: DDD specifies recursive emulation to HHH and halting to HHH1

On 3/31/25 10:57 PM, olcott wrote:

On 3/31/2025 9:48 PM, dbush wrote:

On 3/31/2025 10:38 PM, olcott wrote:

>
HHH must report on the behavior that its input
actually specifies.

>
And the input specifies an algorithm that halts when executed directly.
>

 Which is NOT how it is executed.
It IS executed with recursive emulation.

But of COURSE that is how it is executed.
That is what the actual problem statement says to do.
Your problem is you got on your strawman chain so long ago you forget the meaning of the actual problem.
Or maybe your problem is that you don't understand the concept of directly executiong things, as that is like "Reality", but you only think in the realm of imagination, which is more like simulation, particularly when you don't require the simulation to be strictly "correct"

 

This seems way too difficult
for people that can only spout off words that
they learned by rote, with no actual understanding
of the underlying principles involved.
>
Every actual computation can only transform input
finite strings into outputs. HHH does do this.

>
But not as per the requirements:
>

 

>
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 "requirements" that you mindlessly spout off

>
Which would make all true statements provable if they could be met.
>

violate this foundational principle of functions
computed by Turing machines.

>
Which just says that no Turing machine satisfies those requirements, as Linz and others proved.
>

>
int sum(int x, int y)
{
   return 5;
}
>
sum(2,3) does not compute the sum of 2 + 3.
>

>
>
It absolutely does.  There are *NO* requirements on the implementation, only the result.

 Unless and algorithm transforms its inputs
into its outputs it is not a Turing computable
function.
 

But the problem is to try to FIND an algorithm. No algorithm has been given, just a problem. There is no presumption that the problem has a solution as a Turing Computable function.
Problems are not stated as algorithms, but by mappings to try to find an algorithm that computes it.
We are not playing Jeopardy where they give the answer and we need to determine the question.
The Halting problem STARTS with a problem definition, to try to compute the mapping of a full description of a algorithm and its input, to whether that algorith will halt on that input when it is run.
The input needs to be a full algorithm, and thus your DDD needs to include as part of it, the HHH that it calls, and everything that HHH calls.
When you do that, the mapping of that particular algorithm to the answer is possible.
The problem is that your decider, which had to have been defined before we built that input, because the algorithm used to build it had that as a dependency, just returns the wrong answer.