XPost: comp.theory, sci.logic, sci.math   
   From: dbush.mobile@gmail.com   
      
   On 10/23/2025 6:48 PM, olcott wrote:   
   > On 10/23/2025 5:40 PM, dbush wrote:   
   >> On 10/23/2025 6:08 PM, olcott wrote:   
   >>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:   
   >>>> On 2025-10-22, olcott  wrote:   
   >>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:   
   >>>>>> On 2025-10-22, olcott  wrote:   
   >>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:   
   >>>>>>>> On 2025-10-22, André G  Isaak  wrote:   
   >>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:   
   >>>>>>>>>> But that entire bundle is one fixed case DD, with a single   
   >>>>>>>>>> behavior,   
   >>>>>>>>>> which is a property of DD, which is a finite string.   
   >>>>>>>>>   
   >>>>>>>>> I think part of the problem here is that Olcott doesn't grasp   
   >>>>>>>>> that the   
   >>>>>>>>> "finite string input" DD *must* include as a substring the entire   
   >>>>>>>>> description of HHH.   
   >>>>>>>>   
   >>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be   
   >>>>>>>> HHH,   
   >>>>>>>> but the same algorithm: a workalike.   
   >>>>>>>>   
   >>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH   
   >>>>>>>> called by DD could be in Python.   
   >>>>>>>   
   >>>>>>> DD does call HHH(DD) in recursive simulation   
   >>>>>>> and you try to get away with lying about it.   
   >>>>>>   
   >>>>>> I'm saying that's not a requirement in the halting problem.   
   >>>>>>   
   >>>>>> DD does not have to use that implementation of HHH; it can have   
   >>>>>> its own clean-room implementation and it can be in any language.   
   >>>>>>   
   >>>>>> But nonetheless, yes, there will still be a nested simulation tower.   
   >>>>>>   
   >>>>>   
   >>>>> I made sure to read what you said all the way through   
   >>>>> this time. DD correctly simulated by HHH cannot possibly   
   >>>>> reach its own final halt state no matter what HHH does.   
   >>>>   
   >>>> The /simulation/ of DD by HHH will not /reproduce/ the halt   
   >>>> state of DD, which DD undeniably /has/.   
   >>>>   
   >>>   
   >>> The finite string as an actual input to HHH(DD)   
   >>   
   >> i.e. finite string DD which is the description of machine DD and   
   >> therefore is stipulated to specify all semantic properties of the   
   >> described machine, including halting when executed directly.   
   >>   
   >>> *does not have the halting property*   
   >>   
   >> False, see above.>   
   >>> Turing machine deciders only compute the mapping   
   >>> from their finite string inputs   
   >>   
   >> And the finite string input DD has the halting property as show above.   
   >>   
   >>>   
   >>> Turing machine deciders only compute the mapping   
   >>> from their finite string inputs   
   >>>   
   >>> Turing machine deciders only compute the mapping   
   >>> from their finite string inputs   
   >>>   
   >>> The DD that has the halting property   
   >>   
   >> i.e. finite string DD which is an input to HH   
   >>   
   >>> is not an input   
   >> False, see above.   
   >   
   > Correct simulation is defined as simulation   
   > according to the semantics of the specification   
   > language: C, x86 or TM description.   
      
   And because aborting is against the semantics of those languages, HHH   
   doesn't do a correct simulation.   
      
   >   
   > The execution trace of DD correctly simulated   
   > by HHH   
   Does not exist because HHH aborts.   
      
      
   And since none of what you've written directly addresses my prior post,   
   you've implicitly agreed that the above points are correct, specifically   
   that the input to HHH(DD) specifies halting behavior.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)