XPost: comp.theory, sci.logic   
   From: F.Zwarts@HetNet.nl   
      
   Op 04.aug.2025 om 15:42 schreef olcott:   
   > 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.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)