XPost: comp.theory, sci.logic, sci.math   
   From: 643-408-1753@kylheku.com   
      
   On 2025-10-22, olcott  wrote:   
   > On 10/22/2025 6:15 PM, Kaz Kylheku wrote:   
   >> On 2025-10-22, olcott  wrote:   
   >>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:   
   >>>> On 2025-10-22, olcott  wrote:   
   >>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:   
   >>>>>> On 2025-10-22, André G  Isaak  wrote:   
   >>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:   
   >>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,   
   >>>>>>>> which is a property of DD, which is a finite string.   
   >>>>>>>   
   >>>>>>> I think part of the problem here is that Olcott doesn't grasp that the   
   >>>>>>> "finite string input" DD *must* include as a substring the entire   
   >>>>>>> description of HHH.   
   >>>>>>   
   >>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,   
   >>>>>> but the same algorithm: a workalike.   
   >>>>>>   
   >>>>>> The HHH analyzing DD's halting could be in C, while the HHH   
   >>>>>> called by DD could be in Python.   
   >>>>>   
   >>>>> DD does call HHH(DD) in recursive simulation   
   >>>>> and you try to get away with lying about it.   
   >>>>   
   >>>> I'm saying that's not a requirement in the halting problem.   
   >>>>   
   >>>> DD does not have to use that implementation of HHH; it can have   
   >>>> its own clean-room implementation and it can be in any language.   
   >>>>   
   >>>> But nonetheless, yes, there will still be a nested simulation tower.   
   >>>>   
   >>>   
   >>> Thus proving that DD correctly simulated by HHH   
   >>> cannot possibly reach its own simulated final halt   
   >>> state no matter what HHH does.   
   >>   
   >> I explained that a nested simulation tower is two dimensional.   
   >>   
   >> One dimension is the simulation level, the nesting itself;   
   >> that goes out to infinity.   
   >   
   > Great. Thus the input to HHH(DD) specifies behavior   
   > such that the correctly simulated DD cannot possibly   
   > reach its own simulated final halt state.   
      
   People replying to you respond to multiple points. Yet you typically   
   only read one point of a response.   
      
   You snipped all this:   
      
   >> Due to the aborting behavior of HHH,   
   >> it is not actually realized in simulation; we have to step   
   >> through the aborted simulations to keep it going.   
   >>   
   >> The other dimension is the execution /within/ the simulations.   
   >> That can be halting or non-halting.   
   >>   
   >> In the HHH(DD) simulation tower, though that is infinite,   
   >> the simulations are halting.   
   >>   
   >> I said that before. Your memory of that has vaporized, and you have now   
   >> focused only on my statement that the simluation tower is infinite.   
   >>   
   >> The depth of the simulation tower, and the halting of the simulations   
   >> within that tower, are independent phenomena.   
   >>   
   >> A decider must not mistake one for the other.   
      
   There being endless nested simulations doesn't imply that the   
   simulations are nonterminating.   
      
   If we simply do this:   
      
     void fun(void)   
     {   
        sim_t s = simulation_create(fun);   
        return;   
     }   
      
   we get an infinite tower of simulations, all of which terminate.   
      
   When fun() is called, it creates a simulation beginning at fun.   
   No step of this simulation is performed, yet it exists.   
      
   Then fun terminates.   
      
   No simulation has actually started, but we have a simuation   
   state which implies an infnite tower.   
      
   If the simulation s abandoned by fun is stepped, then soon,   
   inside that simulation, fun wil be called, and will create another   
   simulation and exit.   
      
   Then if we simulate that the same thing will happen.   
      
   Suppose the simulation_create module provides a simulate_run   
   function which identifies all/any unfinished simulations and   
   runs them.   
      
   Then if we do this:   
      
     int main()   
     {   
        fun();   
        simulate_run();   
     }   
      
   simulate_run() will get into an infinite loop inside of   
   which it is always completing simulations of fun, which   
   are creating new simulations.   
      
   That won't even run out of memory because it's not recursion.   
      
   simulation_create() dynamically allocates a simulation.  If   
   simulation_run() calls simulation_destroy() whenever it detects that it   
   has completed a simulation, then I think thesituation can hit a steady   
   state; it runs forever, continuously launching and terminating   
   simulations.   
      
   But we cannot call fun itself non-halting. It has facilitated   
   the infinite generation of simulations, but is itself halting.   
      
      
   --   
   TXR Programming Language: http://nongnu.org/txr   
   Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal   
   Mastodon: @Kazinator@mstdn.ca   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)