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

On 3/29/25 5:33 PM, olcott wrote:

On 3/29/2025 2:51 PM, joes wrote:

Am Sat, 29 Mar 2025 13:54:22 -0500 schrieb olcott:

On 3/29/2025 4:19 AM, joes wrote:

Am Fri, 28 Mar 2025 17:38:22 -0500 schrieb olcott:

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

On 3/28/2025 6:09 PM, olcott wrote:

On 3/28/2025 3:38 PM, dbush wrote:

On 3/28/2025 4:30 PM, olcott wrote:

>

It does not compute (a sequence of steps of an algorithm that derive
an output on the basis of an input) jack shit it makes a guess.

Even a constant function is a "computation", even if it doesn't
actually do any work.

That is not transforming an input finite string into its corresponding
output finite string.

 

Yes it is: transforming every input into the same output.
>

 Deciders must transform inputs into accept or reject
states on the basis of a syntactic or semantic property
specified by the input.
 The DDD input to HHH specifies non-halting.
 

Doesn't matter. If the requirement is to return 5 for strings that
have a length of 5, it meets the requirement.

 

The actual requirement is to compute the mapping from a finite string
to its length using a sequence of algorithmic steps.
Likewise for halting. Compute the mapping from a finite string of
machine code to the behavior that this finite string specifies.

 

Do you reckon the direct execution of a TM contradicts the
specification?

Does it?
>

 Direct execution itself cannot possibly contradict anything.
Read what I said above as many times as needed to get it.
 

Sure it does.
HHH(DD) needs to answer about the behavior of the direct execution of DD.
What ever HHH answers about that DD, even if it just guesses, will cause DD to do the opposite, and thus DD will contradict the answer of HHH(DD).
This is what causes every HHH to be wrong about the DD defined to call it, and thus shows that it is impossible to build a correct Halt Decider.