XPost: comp.theory, sci.logic   
   From: polcott333@gmail.com   
      
   On 8/4/2025 7:47 AM, Fred. Zwarts wrote:   
   > 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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)