XPost: comp.theory   
   From: 643-408-1753@kylheku.com   
      
   On 2025-11-19, olcott  wrote:   
   > On 11/19/2025 12:20 PM, Tristan Wibberley wrote:   
   >> On 19/11/2025 01:41, olcott wrote:   
   >>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote:   
   >>>> On 2025-11-19, olcott  wrote:   
   >>>>> Liars try to claim that DD simulated by HHH   
   >>>>> (according to the semantics of the C programming   
   >>>>> language) reaches its own simulated "return"   
   >>>>> statement final halt state.   
   >>>>   
   >>>> Without the implementation of HHH beng specified, we cannot tell; it   
   >>>> could be the case that HHH(DD) does not return.   
   >>>>   
   >>>   
   >>> Yes because no software engineer could possibly   
   >>> have any idea what simulated means.   
   >>   
   >>   
   >> software engineers don't normally work with "simulated", they work with   
   >> "emulated" and "virtual". The latter refers to a generalisation of   
   >> "emulated" which includes machines that haven't actually existed.   
   >>   
   >> "simulated" can include a wide variety of analyses that characterise a   
   >> system by relations between its starting states and ending states to   
   >> include statistical ones.   
   >>   
   >> The use of simulate to mean emulate in discussion of the Halting Problem   
   >> seems to me to be obsolete now, if it /ever/ meant to strictly emulate.   
   >   
   > https://github.com/plolcott/x86utm/blob/master/Halt7.c   
   > In the above case simulate does perfectly mean emulate   
   > because HHH is anchored in a world class x86 emulator.   
   >   
   > The problem with x86 emulation is essentially no one   
   > has even a slight clue about the simple semantics of   
   > the x86 language.   
      
   No, just yourself.   
      
   Mike Terry and I have done a decent job of working with your simulation   
   stack and and understanding it.   
      
   You claimed this very shortly after I published a fork of   
   of the x86utm, capable of showing that simulations abandoned   
   by a decider can be continued and shown to terminate when   
   the decider decided 0.   
      
   You insinuated that you are disavowing that whole simulation stack,   
   by saying that academics don't understand x86, and that you are   
   planning to move to something else.   
      
   It is you who don't understand; you don't know how to respond   
   to code with code. You've forgotten how it all works and have   
   no idea how to defend it against objections expressed with code.   
      
   Can you point to a time when you made the above remark /prior/   
   to the work which shows, wth code, that abandoned simulations decided as   
   nonterminating are terminating?   
      
   Prior to that time, you insisted that you proved all your results   
   with concrete x86 code. And that everyone not tracing and otherwise   
   engaging with your x86 code is not doing a proper job of arguing   
   against you --- perhaps because they are too stupid to understand it.   
      
   Now it turns out the one too stupid to undertand x86 and respond   
   to code with code is actually YOU!   
      
   > Because of this I switched to simulate   
   > as in a C interpreter emulates code written in C.   
      
   Continued simulations can easily be shown in such a substrate also,   
   and will be even more obvious and understandable.   
      
   I manually showed such a trace.   
      
   --   
   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)