XPost: comp.theory   
   From: polcott333@gmail.com   
      
   On 11/18/2024 10:16 AM, Richard Damon wrote:   
   > On 11/17/24 11:04 PM, olcott wrote:   
   >> On 11/17/2024 9:19 PM, Richard Damon wrote:   
   >>> On 11/17/24 9:47 PM, olcott wrote:   
   >>>> On 11/17/2024 8:26 PM, Richard Damon wrote:   
   >>>>> On 11/17/24 8:46 PM, olcott wrote:   
   >>>>>> On 11/17/2024 4:04 PM, Richard Damon wrote:   
   >>>>>>> On 11/17/24 4:30 PM, olcott wrote:   
   >>>>>>>> On 11/17/2024 2:51 PM, Richard Damon wrote:   
   >>>>>>>>> On 11/17/24 1:36 PM, olcott wrote:   
   >>>>>>>>>> void DDD()   
   >>>>>>>>>> {   
   >>>>>>>>>>    HHH(DDD);   
   >>>>>>>>>>    return;   
   >>>>>>>>>> }   
   >>>>>>>>>>   
   >>>>>>>>>> _DDD()   
   >>>>>>>>>> [00002172] 55         push ebp      ; housekeeping   
   >>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping   
   >>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD   
   >>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)   
   >>>>>>>>>> [0000217f] 83c404     add esp,+04   
   >>>>>>>>>> [00002182] 5d         pop ebp   
   >>>>>>>>>> [00002183] c3         ret   
   >>>>>>>>>> Size in bytes:(0018) [00002183]   
   >>>>>>>>>>   
   >>>>>>>>>> DDD emulated by any encoding of HHH that emulates N   
   >>>>>>>>>> to infinity number of steps of DDD cannot possibly   
   >>>>>>>>>> reach its "return" instruction final halt state.   
   >>>>>>>>>>   
   >>>>>>>>>> This applies to every DDD emulated by any HHH no   
   >>>>>>>>>> matter the recursive depth of emulation. Thus it is   
   >>>>>>>>>> a verified fact that the input to HHH never halts.   
   >>>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>   
   >>>>>>>>> I will also add, that since you have dropped your requirements   
   >>>>>>>>> on HHH (or are seeming to try to divorse yourself from previous   
   >>>>>>>>> assumptions) there are MANY HHH that can complete the   
   >>>>>>>>> emulation, they just fail to be "pure functions".   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> The damned liar despicably dishonest attempt to get away   
   >>>>>>>> with changing the subject away from DDD reaching its final   
   >>>>>>>> halt state.   
   >>>>>>>>   
   >>>>>>>   
   >>>>>>> Which is just what YOU are doing, as "Halting" and what a   
   >>>>>>> "Program" is are DEFINED, and you can't change it.   
   >>>>>>>   
   >>>>>>   
   >>>>>> YET ANOTHER STUPID LIE.   
   >>>>>> A SMART LIAR WOULD NEVER SAY THAT I MEANT   
   >>>>>> PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.   
   >>>>>>   
   >>>>>   
   >>>>> But then you can talk about "emulation" or x86 semantics, as both   
   >>>>> of those are operations done on PROGRAMS.   
   >>>>>   
   >>>>   
   >>>> No stupid I provided a published paper that includes the   
   >>>> termination analysis of C functions.   
   >>>   
   >>> Look again at what they process. C functions that include all the   
   >>> functions they call.   
   >>>   
   >>   
   >> You stupidly claimed termination analysis is only done   
   >> on programs. I proved that you were stupidly wrong on   
   >> pages 24-27 of the PDF of this paper.   
   >>   
   >> Automated Termination Analysis of C Programs   
   >> https://publications.rwth-aachen.de/record/972440/files/972440.pdf   
   >>   
   >>   
   >   
   > The problem here is you are mixing language between domains.   
      
   I said the termination analysis applies to C functions   
   you said that it does not. No weasel words around it   
   YOU WERE WRONG!   
      
      
   --   
   Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius   
   hits a target no one else can see." Arthur Schopenhauer   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)