[continued from previous message]   
      
   >>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.   
   >>>>>>>>>>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation   
   >>>>>>>>>>>>>>>>>>>>>>>>>>> never being   
   >>>>>>>>>>>>>>>>>>>>>>>>>>> able to complete its first statement before   
   >>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)   
   >>>>>>>>>>>>>>>>>>>>>>>>>>> again and again.   
   >>>>>>>>>>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>>>>>>>>>> If that happens then H does not return and   
   >>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.   
   >>>>>>>>>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>>>>>>>>> Maybe my work is over your head.   
   >>>>>>>>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your   
   >>>>>>>>>>>>>>>>>>>>>>>> head.   
   >>>>>>>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>>>>>>> typedef int (*ptr)();   
   >>>>>>>>>>>>>>>>>>>>>>> int HHH(ptr P);   
   >>>>>>>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>>>>>>> int DD()   
   >>>>>>>>>>>>>>>>>>>>>>> {   
   >>>>>>>>>>>>>>>>>>>>>>>    int Halt_Status = HHH(DD);   
   >>>>>>>>>>>>>>>>>>>>>>>    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.   
   >>>>   
   >>>> True. It would if HHH were a halting decider but HHH isn't.   
   >>>   
   >>> If you carefully studied all of what I said you   
   >>> would see that the halting problem is a category   
   >>> error because it directly contradicts one of the   
   >>> foundational axioms of computer science.   
   >>   
   >> Any statement that a problem contradicts anything is a categoryerror.   
   >   
   > Flibble was the first one to use this term that I am aware of.   
      
   Do you mean the term "category error"? It is a well known term   
   though many authors prefer "category mistake" for the same   
   meaning.   
      
   Anyway, any claim that a problem contradict something is   
   a category error because the meanings of "problem" and   
   "contradict" are not compatible.   
      
   --   
   Mikko   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)