Re: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩

On 7/29/2024 3:08 PM, joes wrote:

Am Mon, 29 Jul 2024 11:16:13 -0500 schrieb olcott:

On 7/28/2024 3:02 AM, Mikko wrote:

On 2024-07-27 14:08:10 +0000, olcott said:

On 7/27/2024 2:21 AM, Mikko wrote:

On 2024-07-26 14:08:11 +0000, olcott said:

On 7/26/2024 3:45 AM, Mikko wrote:

On 2024-07-24 13:33:55 +0000, olcott said:

On 7/24/2024 3:57 AM, Mikko wrote:

On 2024-07-23 13:31:35 +0000, olcott said:

On 7/23/2024 1:32 AM, 0 wrote:

On 2024-07-22 13:46:21 +0000, olcott said:

On 7/22/2024 2:57 AM, Mikko wrote:

On 2024-07-21 13:34:40 +0000, olcott said:

On 7/21/2024 4:34 AM, Mikko wrote:

On 2024-07-20 13:11:03 +0000, olcott said:

On 7/20/2024 3:21 AM, Mikko wrote:

On 2024-07-19 14:08:24 +0000, olcott said:

 

(b) We know that a decider is not allowed to report on the
behavior computation that itself is contained within.

>
No, we don't. There is no such prohibition.

 

Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.

If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
>

In this case we have two x86utm machines that are identical
except that DDD calls HHH and DDD does not call HHH1.

>
That DDD calls HHH and DDD does not call HHH1 is not a difference
between two unnamed turing machines.
>

The same thing happens at the Peter Linz Turing Machine level I
will provide that more difficult example if and only if you prove
that you understand this one.

Way to disgruntle your "reviewers".
 

However, Peter Linz does not call taht same thing a difference.

 

Some of the properties you assert exsit actually do exist, some
don't.

 

(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
You are supposed to evaluate the above as a contiguous sequence of
moves such that non-halting behavior is identified.

>
The above is an obvious tight loop of (d), (e), (f), and (g).
Its relevance (it any) to the topic of the discussion is not obvious.
>

When we compute the mapping from the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
to the behavior specified by this input we know that embedded_H is
correct to transition to Ĥ.qn.
Everyone say no, no that it not the behavior of the computation that
embedded_H is contained within: Ĥ applied to ⟨Ĥ⟩.
It is not supposed to be (or allowed to be) the behavior of the
executing Turing machine that embedded_H is contained within.
It is only supposed to be the behavior that the input to embedded_H
specifies and this includes recursive simulation.

 From the fact that the simulation is recursive we know that the
embedded H is the same as the outer one.
 

It is a fact that embedded_H aborts the simulation of its input
or itself never stops running.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer