[continued from previous message]   
      
   >>>>>>>>>>> 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?   
      
   Olcott cherry picks a hyper simple program and says see, I can tell if   
   it halts or not! I am an genius. Ect... He can detect a non-terminating   
   condition! God be praised indeed.   
      
   If HHH(DD) returns non-zero it goes into an infinite GOTO loop. We can   
   say this is non-halting. If HHH(DD) returns zero, DD halts.   
      
   int DD()   
   {   
   10:    int Halt_Status = HHH(DD);   
   20:    if (Halt_Status)   
   30:       HERE: goto HERE;   
   40:    return Halt_Status;   
   }   
      
   ?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)