XPost: comp.theory, sci.logic   
   From: F.Zwarts@HetNet.nl   
      
   Op 01.aug.2025 om 16:46 schreef olcott:   
   > On 8/1/2025 1:53 AM, joes wrote:   
   >> Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:   
   >>> On 7/31/2025 7:07 PM, Richard Damon wrote:   
   >>>> On 7/31/25 11:50 AM, olcott wrote:   
   >>   
   >>>>> On 7/29/2025 11:22 PM, Alan Mackenzie wrote:   
   >>>>>   > It is a lack of technical ability on your part which is unable to   
   >>>>>   > judge whether such a correct simulation is possible.  Everybody   
   >>>>>   > else sees that it is not, so further questions about it are   
   >>>>>   > non-sensical.   
   >>>>> HHH emulates DDD in a separate process context. When this DDD calls   
   >>>>> HHH(DDD) the original HHH emulates this HHH in the DDD process   
   >>>>> context.   
   >>>> And that separate proccess, if left unaborted, would halt. But HHH   
   >>>> gives up and aborts it, so the process is Halting, not non-halting.   
   >   
   >> And HHH cannot simulate itself to its undeniable halting state.   
   >>   
   >>>>> This emulated HHH creates yet another process context to emulate its   
   >>>>> own DDD. When this DDD calls yet another HHH(DDD) this provides enough   
   >>>>> execution trace that the repeating pattern can be seen.   
   >>>> But the pattern isn't non-halting by the fact that DDD is shown to be   
   >>>> halting.   
   >>> *No not at all. Not in the least little bit* Recursive simulation is   
   >>> only a little more difficult than self recursion.   
   >   
   >> DDD halts if it weren't aborted.   
   >>   
   >   
   > (1) That is counter-factual. Neither HHH() nor DDD() nor DDD   
   > simulated by HHH ever stops running unless HHH(DDD) aborts   
   > its input.   
      
      
   It is irrelevant what a hypothetical non-input would do. HHH aborts, so   
   DDD and HHH, both the directly executing and the simulated versions halt.   
      
   >   
   > (2) I have never been taking about DDD() the behavior of a non-input.   
   > Turing machines are only accountable for the behavior that their   
   > inputs specify, they are never accountable for any non-inputs.   
      
      
   And this input specifies a program with code to abort, so it specifies a   
   halting program. When HHH does not see that, it fails.   
      
   >   
   > (3) When I make a claim about DDD simulated by HHH and this is   
   > changed to the behavior of the directly executed DDD this is   
   > a dishonest tactic known as the strawman error.   
      
   When the input specifies a halting behaviour, it is an error to close   
   your eyes and pretend that it does not exist.   
      
   >   
   > void DDD()   
   > {   
   >    HHH(DDD);   
   >    return;   
   > }   
   >   
   > Executed HHH simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > that simulates DDD that calls HHH(DDD)   
   > Then HHH kills the whole simulation process and returns 0   
      
   Counterfactual. HHH abors after a few cycles, when only one more cycle   
   is needed to complete the simulation, as proven by simulators that do   
   not abort the exact same input.   
      
   >   
   >>> When N instructions of DDD are correctly emulated by every HHH that can   
   >>> possibly exist (technically this is an infinite set of HHH/DDD pairs)   
   >>> no emulated DDD can possibly halt and every directly executed DDD()   
   >>> halts.   
   >   
   >> See, and I thought DDD was a concrete program filled in with HHH,   
   >> which aborts after two levels of simulation, not something that   
   >> calls "HHH" symbolically, producing many different programs.   
   >>   
   >   
   > I had to turn it into an infinite set of HHH/DDD   
   > pairs so that it could be more easily understood   
   > that DDD simulated by HHH cannot possibly halt.   
   >   
   > When HHH detects the above non-halting behavior   
   > pattern it kills the whole simulation process so   
   > there is no stack unwinding.   
   >   
   There is no non-halting behaviour pattern, only a finite number more   
   than N instructions are needed to reach the final input *for this input*.   
   Proving that for all N the program specifies a halting behaviour, but we   
   can construct *another* input for which HHH fails again.   
   But you cheat by changing the input, which then needs more steps.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)