[continued from previous message]   
      
   >>>>>>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>> 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.   
      
   But then ignore that you try to talk about HHH not being a specific C   
   program, which means that DD isn't either.   
      
   C function DD only has C defined behavior when HHH is fully and   
   precisely specified to C, which means it either simulates its input   
   forever, OR it decides to abort and return 0, it can't be both.   
      
   >   
   > https://github.com/plolcott/x86utm/blob/master/Halt7.c   
   > HHH on line 1081   
      
   Which thus *ALWAYS* will abort its simulation of DD, and thus the   
   concept of it not doing so is just a LIE, and unsound logic.   
      
   > DD on line 1355   
   >   
   > 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);   
   > }   
   >   
   > That DD simulated by HHH never stops running   
   > unless aborted by HHH proves that the input   
   > to HHH(DD) specifies non halting behavior.   
      
   No, becauses there is no such thing in this case of an HHH that doesn't   
   abort its simulation   
      
   >   
   > Saying that that some other DD somewhere else   
   > does stop as a rebuttal is only the strawman error.   
      
   No, you saying that some other DD that calls some other HHH that doesn't   
   abort is the same as this DD is your strawman error.   
      
      
   >   
   > A straw man fallacy (sometimes written as strawman)   
   > is the informal fallacy of refuting an argument   
   > different from the one actually under discussion,   
   > while not recognizing or acknowledging the distinction.   
   > https://en.wikipedia.org/wiki/Straw_man   
      
   Right, and talking about an HHH that doesn't abort, when HHH does abort   
   is a strawman.   
      
   >   
   > When the halting problem requires HHH to report   
   > on the behavior of the DD executed from main()   
   > this is erroneous:   
      
   Nope, talking about a non-program DD that calls whatever HHH is looking   
   at it is just a strawman.   
      
   >   
   > (1) The caller of a function is never an argument to   
   > this same function.   
      
   Sure it can be.   
      
   >   
   > (2) The halting problem is requiring a halt decider   
   > to report on behavior that is different that the behavior   
   > specified by its input.   
      
   No, since the "behavior specified by the input" is the behavior of the   
   direct execution of the program it represents.   
      
   The error is you buggy program can't figure out that behavior, as   
   assumes it doesn't do what it does.   
      
   >   
   > My work on the halting problem is only an aspect of   
   > my project to make “true on the basis of meaning   
   > expressed in language” reliably computable.   
   >   
      
   Which, since you show that you don't consider words to have their actual   
   meaning, just shows that you are just a liar, and stupid.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)