[continued from previous message]   
      
   >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies.   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same   
   >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)