XPost: sci.logic
Am Fri, 21 Jun 2024 23:18:50 -0500 schrieb olcott:
On 6/21/2024 11:09 PM, joes wrote:
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:
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.
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.
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.
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.
The behavior of D correctly simulated by H1 is the same as the behavior
of the directly executed D(D) because D does not call H1(D,D) in
recursive simulation.
D1 however, which calls H1(D1, D1), can't be decided by H1.
The behavior of D correctly simulated by H is NOT the same as the
behavior of D correctly simulated by H1 because D DOES call H(D,D) in recursive simulation.
The simulation by H is then of course not correct.
What about the other points above?
--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)