Path: ...!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 29 Jul 2024 21:27:19 +0000
Subject: Re: This function proves that only the outermost HHH examines the
 execution trace
Newsgroups: comp.theory
References: <v80h07$2su8m$3@dont-email.me> <v82bi4$39v6n$4@dont-email.me>
 <v82tr5$3dftr$2@dont-email.me> <v82vtl$3dq41$2@dont-email.me>
 <v830hg$3dftr$9@dont-email.me> <v83des$2nhr$1@news.muc.de>
 <KUidnalBUcYWDjj7nZ2dnZfqn_ednZ2d@brightview.co.uk>
 <v85a6c$gb3$1@news.muc.de>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Mon, 29 Jul 2024 22:27:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.17
MIME-Version: 1.0
In-Reply-To: <v85a6c$gb3$1@news.muc.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <-vacnc1vPMGllDX7nZ2dnZfqnPadnZ2d@brightview.co.uk>
Lines: 55
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-lsCJBr4Kp2jR9VzfgFSeQh9Ip/RwHwZTwv4P3xPFIn3qkNW7NvRA5M3F3XudlfQ32cH43HyY/ut/OKX!FQCrCEshEPEZmg6eqQSjHQHpTx1Vv6ZF7zevm2dJc0NggHI6ncVtb0jr5EV4q+3jb11t6s8rT2Dz!52c4J8AAyaiEYs7GRvV1BEJ1n2o=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 4649

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.