[continued from previous message]   
      
   >>>>>>>>> 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.   
   >   
      
   No, you are, as you think a call instruction doesn't go into the   
   function called, and that a correct simulation of it might differ from   
   the behavior that the actual x86 does.   
      
   Sorry, You "proof" need to lie, under the excuse that the details are   
   too complicated, as you can't show what you want without lying.   
      
   THe fact that D, when run, halts says your simulation is just incorrect.   
      
   Your logic is based on being able to have two programs being the "same"   
   code, even though they do different things.   
      
   H can't both abort and not abort at the same time.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)