[continued from previous message]   
      
   >>>>>>>>>>>>>>>>>>    if (Halt_Status)   
   >>>>>>>>>>>>>>>>>>      HERE: goto HERE;   
   >>>>>>>>>>>>>>>>>>    return Halt_Status;   
   >>>>>>>>>>>>>>>>>> }   
   >>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>> int main()   
   >>>>>>>>>>>>>>>>>> {   
   >>>>>>>>>>>>>>>>>>    HHH(DD);   
   >>>>>>>>>>>>>>>>>> }   
   >>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>> People here have consistently lied about   
   >>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"   
   >>>>>>>>>>>>>>>>>> statement final halt state for three years.   
   >>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>> You yourself have not told the truth about   
   >>>>>>>>>>>>>>>>>> this even once.   
   >>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>> That seems to confirm that the definition of "decider"   
   >>>>>>>>>>>>>>>>> is over your head.   
   >>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>> I am just talking at the level of the execution   
   >>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting   
   >>>>>>>>>>>>>>>> behavior to its termination analyzer.   
   >>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>> The termination problem is not about specifying "to its   
   >>>>>>>>>>>>>>> termination   
   >>>>>>>>>>>>>>> analyzer". Instead the termination problem is to   
   >>>>>>>>>>>>>>> determine whether   
   >>>>>>>>>>>>>>> a program terminates every time when used as it was   
   >>>>>>>>>>>>>>> designed to be   
   >>>>>>>>>>>>>>> used.   
   >>>>>>>>>>>>>>   
   >>>>>>>>>>>>>> The halting problem requires that a halt decider   
   >>>>>>>>>>>>>> correctly report on the behavior of its caller   
   >>>>>>>>>>>>>> and no halt decider can even see its actual caller.   
   >>>>>>>>>>>>>   
   >>>>>>>>>>>>> Every halt decider is required to report on the behaviour   
   >>>>>>>>>>>>> asked about.   
   >>>>>>>>>>>>   
   >>>>>>>>>>>> And this is incorrect when it has not access to   
   >>>>>>>>>>>> the behavior that it is asked about.   
   >>>>>>>>>>>   
   >>>>>>>>>>> No, it is not. The solution to the halting problem must   
   >>>>>>>>>>> include the   
   >>>>>>>>>>> necessary access. Conversely, a proof that the necessary   
   >>>>>>>>>>> access is   
   >>>>>>>>>>> impossible is sufficient to prove that halting problem is   
   >>>>>>>>>>> unsolvable.   
   >>>>>>>>>>   
   >>>>>>>>>> Reporing on the behavior of DD() executed from   
   >>>>>>>>>> main requires HHH to report on information   
   >>>>>>>>>> that is not contained in its input thus it is   
   >>>>>>>>>> incorrect to require HHH to report on that.   
   >>>>>>>>>   
   >>>>>>>>> That HHH fails to meet the requirements does not mean that the   
   >>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt   
   >>>>>>>>> decider.   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> That HHH fails to meet the requirements by itself does   
   >>>>>>>> not mean that the requirements are wrong.   
   >>>>>>>>   
   >>>>>>>> Turing machine deciders only compute a mapping from   
   >>>>>>>> their [finite string] inputs to an accept or reject   
   >>>>>>>> state on the basis that this [finite string] input   
   >>>>>>>> specifies or fails to specify a semantic or syntactic   
   >>>>>>>> property.   
   >>>>>>>>   
   >>>>>>>> That the information that HHH is required to report   
   >>>>>>>> on simply is not contained in its input is what makes   
   >>>>>>>> the requirements wrong.   
   >>>>>>>   
   >>>>>>> No, it merely means that the designer ot HHH has failed to   
   >>>>>>> specify the   
   >>>>>>> encoding rules so that the input contains the full specification   
   >>>>>>> of the   
   >>>>>>> behaviour.   
   >>>>>   
   >>>>>> In other words you are trying to get away with   
   >>>>>> disagreeing with the semantics of the x86 language   
   >>>>>> or the semantics of the C programing language.   
   >>>>>   
   >>>>> You are the one who disagrees with the x86 processors about the x86   
   >>>>> language semantics. When an x86 processor executes a program it   
   >>>>> executes   
   >>>>> according to the x86 semantics. When DD is executed according to   
   >>>>> the x86   
   >>>>> semantics it halts. Anybody who says that DD specifies a non-halting   
   >>>>> behaviour disagrees with the x86 semantics.   
   >>>   
   >>>> But, DD can halt or not halt, right?   
   >>>   
   >>> When Olcott uses the name DD he means the particular program in his   
   >>> GitHub repository except when he wants to deceive with equivocation.   
   >>> The DD is Olcotts repository halts.   
   >   
   >> I am doing this in the C programming language so that   
   >> every detail can be concretely specified and thus no   
   >> important details are simply abstracted away.   
   >>   
   >> https://github.com/plolcott/x86utm/blob/master/Halt7.c   
   >> HHH on line 1081   
   >> DD on line 1355   
   >   
   > The DD on line 1355 is the DD I mentioned above and whicn is listed   
   > below. HHH always means the HHH on line 1081 except when otherwise   
   > stated. HHH(DD) means the HHH on line 1081 is called with the pointer   
   > to the DD on line 1355 as the argument. THat call returns 0, which   
   > means that DD does not halt.   
   >   
      
   HHH(DD)==0 has nothing to do with DD executed from main.   
      
   The DD executed from main is the caller of HHH(DD) thus   
   cannot as be one-and-the-same-thing as an argument to HHH.   
   If you think so then you knowledge of C is abysmal.   
      
   The input to HHH(DD) specifies a non-halting sequence.   
      
   --   
   Copyright 2025 Olcott   
      
   My 28 year goal has been to make   
   "true on the basis of meaning" computable.   
      
   This required establishing a new foundation   
   for correct reasoning.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)