XPost: comp.theory, sci.logic   
   From: F.Zwarts@HetNet.nl   
      
   Op 02.aug.2025 om 16:16 schreef olcott:   
   > On 8/2/2025 4:18 AM, Fred. Zwarts wrote:   
   >> 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.   
   >>   
   >   
   > DDD correctly simulated by HHH cannot possibly reach   
   > its own simulated "return" instruction final halt state   
   > in 1 to infinity steps of correct simulation. When the   
   > simulation is aborted the entire process is killed so   
   > there is no stack unwinding.   
   >   
   >>>   
   >>> (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.   
   >>   
   >   
   > I discovered a case where the correct simulation   
   > and the direct execution have different halting   
   > behaviors.   
      
   No, you dreamed, but could not prove it. Only by twisting the meaning of   
   the words, you could make yourself believing it.   
      
   >   
   >>>   
   >>> (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.   
   >>   
   >   
   > The above HHH aborts after ten recursive simulations   
   > because people here did not understand that there were   
   > any recursive simulation when I only show one or two.   
      
   That does not make any difference. We also see that you are cheating, by   
   not only changing the simulator, but also the simulated input. World   
   class simulators show that the original input, when correctly simulated,   
   reaches its final halt state after tree recursion.   
   The HHH that simulates 10 recursions would also reach the final halt   
   state for this same input.   
   But, because your are cheating, you changed the input, which now needs   
   eleven recursion to halt.   
   We see in this way, the, no matter how many recursions you simulate,   
   this method is unable to reach the final halt state that is specified in   
   the input when we construct a new DDD with this new HHH.   
      
   >   
   >>>   
   >>>>> 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*.   
   >   
   > counter-factual   
   >   
   > _DDD()   
   > [00002192] 55         push ebp   
   > [00002193] 8bec       mov ebp,esp   
   > [00002195] 6892210000 push 00002192  // push DDD   
   > [0000219a] e833f4ffff call 000015d2  // call HHH   
   > [0000219f] 83c404     add esp,+04   
   > [000021a2] 5d         pop ebp   
   > [000021a3] c3         ret   
   > Size in bytes:(0018) [000021a3]   
      
   WE have told you many times that it is incorrect to suggest that these   
   18 bytes describe the whole input for the simulator.   
   All functions called by DDD, directly or indirectly, also belong to the   
   input under test.   
      
   >   
   > Every 5 instructions of DDD that are correctly emulated   
   > end up in HHH at line one. One more instruction of   
   > DDD emulates line two, one more emulates line three,   
   > one more ends up at line four, one more ends up back   
   > at line one.   
      
   Incorrect, the call ends up inside HHH. When you would correctly follow   
   the code of HHH in your simulator, keeping track of the internal state   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)