home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.ai.philosophy      Perhaps we should ask SkyNet about this      59,235 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 58,101 of 59,235   
   =?UTF-8?B?QW5kcsOpIEcuIElzYWFr?= to Kaz Kylheku   
   Re: Never any actual rebuttal to HHH(DD)   
   22 Oct 25 13:24:00   
   
   XPost: comp.theory, sci.logic, sci.math   
   From: agisaak@gm.invalid   
      
   On 2025-10-22 12:40, Kaz Kylheku wrote:   
   > 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.   
      
   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.   
      
   AndrĂ©   
      
   > 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.   
   >   
      
   --   
   To email remove 'invalid' & replace 'gm' with well known Google mail   
   service.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca