Re: Defining a correct simulating halt decider

Liste des GroupesRevenir à c theory 
Sujet : Re: Defining a correct simulating halt decider
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theory
Date : 03. Sep 2024, 00:42:02
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <751115c693764ecebf730fa6a8f28ee9e816c36b@i2pn2.org>
References : 1 2 3
User-Agent : Mozilla Thunderbird
On 9/2/24 6:22 PM, olcott wrote:
On 9/2/2024 12:52 PM, Fred. Zwarts wrote:
Op 02.sep.2024 om 18:38 schreef olcott:
A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.
>
If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.
>
A halt decider never ever computes the mapping
for the computation that itself is contained within.
>
Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.
>
*Simulating Termination Analyzer H Not Fooled by Pathological Input D*
https://www.researchgate.net/ publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>
A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.
>
Indeed, it should simulate *itself* and not a hypothetical other HHH with different behaviour.
If HHH includes code to see a 'special condition' and aborts and halts, then it should also simulate the HHH that includes this same code and
  DDD has itself and the emulated HHH stuck in recursive emulation.
Only id HHH never aborts, which is NOT what your HHH does, or it fails to be a decider.
You don't seem to understand that programs can't "change their mind" or that the "get to decide" what to do, but are just deterministinc algorithms that do what they are programmed to do.

 void DDD()
{
   HHH(DDD);
   return;
}
 When HHH emulates itself emulating DDD the emulated
HHH cannot possibly return because each DDD keeps
calling HHH to emulate itself again until the outer
executed HHH kills the whole emulated process at
the very first emulated DDD before it ever reaches
its own second line.
 
Of course it can. and it must if the emulating HHH aborts its emulation to return an answer.
You just have a funny-mental problem confusing the behavior of the machine being emulated (which continues even after the emulation finishes, being a mathematical concept) with the emulation that was done by the emulator.
DDD and the HHH(DDD) that it calls both return, even though HHH(DDD) can't emulate to that point, because since they all have the same code, since you have said that the outer HHH does abort its emulation, the ALL will, and thus all return.
Sorry, you are just stuck in your ignorance abort how programs work, or what theu even are.

Date Sujet#  Auteur
13 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal