embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to Ĥ.qn

On 7/29/2024 4:27 PM, Mike Terry wrote:

On 28/07/2024 12:31, Alan Mackenzie wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

>

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).

>

I think you're wrong, here.  All your C programs are a stand in for
turing machines.  A turing machine is either running or halted.  There is
no third state "aborted".  An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing
machine.

>

So aborted programs are halted programs.  If you disagree, perhaps you
could point out where in my arguments above I'm wrong.

>
>

Aborting is an action performed by a simulator, not the TM being simulated.

>
OK, so if a simulator aborts the program it's simulating, that program is
still in state running, even though it's a suspended animation which will
never get any further.  The simulator, having aborted the program, then
has no more work to do, so the simulator will be in state halted.  Is
that right?
>

 The way simulators are discussed in these threads, the simulator is a /component/ within some other program such as some partial halt decider program.  The role of the (partial) simulator is to calculate the computation steps of the computation represented by its input.  Also it will need to give the main program the ability to interogate the status of its simulation as it progresses - e.g. to determine which state its simulated program has reached, and where it is positioned on its simulated tape and the simulated tape contents.  The rest of the program /uses/ the component. Typically it might analyse the results from calling the simulator looking for patterns which indicate halting/non-halting behaviour of its simulated computation.  We could call that the program's halt-analysis logic, which is logically separate from the simulation code.
 So we could say the status of the simulator after aborting is like the status of a component in a C++ program after the last call to the component - it is still there, I suppose, but just not being called.  Like the status of the printf function after its final call in a program.  I wouldn't say the simulator was halted, just like I wouldn't say the printf routine was halted.  Such component code doesn't have its own halt status because it is part of some larger program.
 As to the program it was simulating - well that program was never "running" as such - it was just being simulated in a virtual machine.  That is just a particular form of data manipulation performed by the main program.  Is the virtual machine still there, if its owning code has abandoned it?  I think the question doesn't make sense.  Perhaps the simulator has "freed" all the resources that were used during the simulation, but there's no requirement for a TM to do that, and it really doesn't matter!
 Hope that makes sense,
Mike.
 

*Maybe this is easier to understand*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(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
Two complete simulations show a pair of identical TMD's
are simulating a pair of identical inputs. We can see
this thus proving recursive simulation that can stop
running when aborted yet never halts.
Hotel California where you can checkout but never leave
*The complete proof for context*
https://www.liarparadox.org/Linz_Proof.pdf
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer