XPost: comp.theory, sci.logic, sci.math   
   From: 643-408-1753@kylheku.com   
      
   On 2025-10-22, olcott  wrote:   
   > On 10/22/2025 12:07 PM, Kaz Kylheku wrote:   
   >> On 2025-10-22, olcott  wrote:   
   >>> On 10/22/2025 10:40 AM, Kaz Kylheku wrote:   
   >>>> On 2025-10-22, olcott  wrote:   
   >>>>> On 10/20/2025 10:20 PM, Kaz Kylheku wrote:   
   >>>>>>> And when I identify a flaw yo simply ignore   
   >>>>>>> whatever I say.   
   >>>>>>   
   >>>>>> Nope; all the ways you say claim you've identified a flaw have been   
   >>>>>> dissected by multiple poeple to a much greater detail than they deserve.   
   >>>>>>   
   >>>>>> It is disingenuous to say that you've simply had your details ignored.   
   >>>>>>   
   >>>>>   
   >>>>> Turing machines in general can only compute mappings   
   >>>>> from their inputs. The halting problem requires computing   
   >>>>> mappings that in some cases are not provided in the   
   >>>>> inputs therefore the halting problem is wrong.   
   >>>>   
   >>>> The halting problem positively does not propose anything   
   >>>> like that, which would be gapingly wrong.   
   >>>   
   >>> It only seems that way because you are unable to   
   >>   
   >> No, it doesn't only seem that way. Thanks for playing.   
   >>   
   >>> provide the actual mapping that the actual input   
   >>> to HHH(DD) specifies when DD is simulated by HHH   
   >>> according to the semantics of the C language,   
   >>   
   >> DD is a "finite string input" which specifies a behavior that is   
   >> independent of what simulates it,   
   >   
   > That is stupidly incorrect.   
   > That DD calls HHH(DD) (its own simulator) IS PART OF   
   > THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.   
      
   In no way am I saying that DD is not built on HHH, and   
   does not have a behavior dependent on that of HHH.   
   Why would I ever say that?   
      
   But that entire bundle is one fixed case DD, with a single behavior,   
   which is a property of DD, which is a finite string.   
      
   DD can be passed as an argument to any decider, not only HHH.   
      
   For instance, don't you have a HHH1 such that HHH1(DD)   
   correctly steps DD to the end and returns the correct value 1?   
      
   DD's behavior is dependent on a decider which it calls;   
   but not dependent on anything which is analyzing DD.   
      
   Even when those two are the same, they are different   
   instances/activations.   
      
   DD creates an activation of HHH on whose result it depends.   
      
   The definition of DD's behavior does not depend on the ongoing   
   activation of something which happens to be analyzing it;   
   it has no knowledge of that.   
      
   --   
   TXR Programming Language: http://nongnu.org/txr   
   Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal   
   Mastodon: @Kazinator@mstdn.ca   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)