Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply

Am Fri, 21 Jun 2024 15:52:21 -0500 schrieb olcott:

On 6/21/2024 3:00 PM, Richard Damon wrote:

On 6/21/24 3:45 PM, olcott wrote:

On 6/21/2024 2:33 PM, Richard Damon wrote:

On 6/21/24 3:19 PM, olcott wrote:

When H is asked H(D,D) this maps to D correctly simulated by H.

Like every other input, it should map to the behaviour of D(D).
You are talking about H(H, D(D)), which is H simulating itself.

When H is asked H(D,D) this DOES NOT map to behavior that halts.

Only if H returns.

Nope. H(M,d) is DEFINED (if it is correct) to determine if M(d) will
Halt.

If one "defines" that the input to H(D,D) maps to the behavior of D(D)
yet cannot show this because it does not actually map to that behavior
*THEN THE DEFINITION IS SIMPLY WRONG*

Ridiculous. H is wrong. Your modification is not useful.

But we CAN show that it maps to the behavior of D(D) (at least when the
representation of D includes the H that is giving the 0 answer) by just
runnig it and seeing what it does.

No you cannot show that the mapping for the input to H(D,D) maps to the
behavior of D(D).

If it doesn't, H is not a simulator.
The input D(D) absolutely describes the behaviour of that machine.
H just can't map it.

You assume that the call to H(D,D) from D correctly simulated by H *must
return* against the verified facts that it does not return.

Either H is not a decider or it returns.

The directly executed D(D) is essentially the first call in a recursive
chain where the second call is always aborted.
*these two calls are not identical*

They most definitely are. The input is the same.

H(D,D) is not free to simply assume that the call from D(D) to H(D,D)
will return.

Yes it is, because it is a decider. It (incorrectly) aborts nonterminating
inputs.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim