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,675 of 59,235   
   olcott to Richard Damon   
   Re: Defining a halt decider with perfect   
   15 Dec 25 22:53:45   
   
   XPost: comp.theory, sci.logic, sci.math   
   From: polcott333@gmail.com   
      
   On 12/15/2025 9:22 PM, Richard Damon wrote:   
   > On 12/15/25 8:31 PM, olcott wrote:   
   >> On 12/15/2025 6:17 PM, Richard Damon wrote:   
   >>> On 12/15/25 9:05 AM, olcott wrote:   
   >>>> On 12/15/2025 3:10 AM, Mikko wrote:   
   >>>>> On 15/12/2025 02:39, olcott wrote:   
   >>>>>> On 12/14/2025 6:13 PM, Richard Damon wrote:   
   >>>>>>> On 12/14/25 3:57 PM, olcott wrote:   
   >>>>>>>> On 12/14/2025 1:55 PM, Richard Damon wrote:   
   >>>>>>>>> On 12/14/25 11:32 AM, olcott wrote:   
   >>>>>>>>>> On 12/14/2025 3:56 AM, Mikko wrote:   
   >>>>>>>>>>> On 13/12/2025 23:32, olcott wrote:   
   >>>>>>>>>>>   
   >>>>>>>>>>>> All of the textbooks require halt deciders to   
   >>>>>>>>>>>> report on the behavior of machine M on input w.   
   >>>>>>>>>>>> This may be easy to understand yet not precisely   
   >>>>>>>>>>>> accurate.   
   >>>>>>>>>>   
   >>>>>>>>>>> That is precisely accurate. The problem is exactly what the   
   >>>>>>>>>>> problem   
   >>>>>>>>>>> statement says. You may define your problem differently but then   
   >>>>>>>>>>> you just have another problem. The halting problem still is what   
   >>>>>>>>>>> it was.   
   >>>>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>> All the textbooks simply ignore that no Turing   
   >>>>>>>>>> machine can possibly compute the mapping from   
   >>>>>>>>>> the behavior from another actual Turing machine.   
   >>>>>>>>>   
   >>>>>>>>> Sure it can, from the representation of it.   
   >>>>>>>>>   
   >>>>>>>>> Just like it can add two numbers by using representatins.   
   >>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>> They can only compute the mapping from a finite   
   >>>>>>>>>> string input that is a mere proxy for this behavior.   
   >>>>>>>>>   
   >>>>>>>>> And the proxy represents that same behavior, so it must get the   
   >>>>>>>>> same result.   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> As I have conclusively proved many thousands of   
   >>>>>>>> times that the behavior of DD AS AN ACTUAL INPUT   
   >>>>>>>> to HHH does SPECIFY non-halting behavior.   
   >>>>>>>   
   >>>>>>> No you haven't,   
   >>>>>> I say that I have proven this   
   >>>>>> DD AS AN INPUT TO HHH(DD)   
   >>>>>   
   >>>>> You keep repeating that the meaning of DD as imput ot HHH is different   
   >>>>> from the meaning of DD per se. But you never say what that different   
   >>>>> meaning is.   
   >>>>>   
   >>>>   
   >>>> Or I do say it 500 times and you never notice.   
   >>>> DD simulated by HHH according to the semantics of C   
   >>>> cannot possibly reach its own "return" statement   
   >>>> final halt state.   
   >>>   
   >>> Which is a lie, as HHH doesn't simulate the input by the semantic of   
   >>> C, as it doesn't correctly simulate the "HHH(DD)" instruction, as it   
   >>> thinks HHH is something differnt that what it must actually be.   
   >>>   
   >>   
   >> So you you think that HHH thinks that the call   
   >> from DD to HHH(DD) is a bowl of spaghetti?   
   >   
   > No, because HHH doesn't "Think", but it clearly simulates it wrong, as   
   > it doesn't make it act like the real HHH.   
      
   I am just going to have to rewrite this as a   
   C interpreter.   
      
   HHH.exe *is* a (not yet implemented) C interpreter.   
   It can correctly interpret a source file test.c   
   that only contains DD.   
      
   It knows that HHH is itself and it understands that   
   the argument to HHH(DD) refers to the text of DD.   
      
   > It is clear that YOU think   
   > that HHH doesn't actually mean that HHH, as you keep on changing what   
   > your think HHH is, just showing your don't know the meaning of your words.   
   >   
   > Your problem is you can't define what HHH actually does and then have it   
   > follow that to get your answer, as your world is just based on lying.   
   >   
   > You don't seem to understand a fundamental principle of a program, that   
   > it actually only does what it has been programmed for. Since the only   
   > real code for HHH has the abort in it, that IS what HHH does, and your   
   > reasoning about HHH must include that behavior, or you are just lying to   
   > yourself, and then beleiving your own lies.   
   >   
   >>   
   >>> Or, DD doesn't HAVE behavior by the C language, since HHH isn't part   
   >>> of the input.   
   >>>   
   >>>>   
   >>>>> More importantly, you never tell what input to HHH would mean the   
   >>>>> same as DD per se so HHH is not a halt decider and is not relevant   
   >>>>> to any discossion about halt deciders.   
   >>>>>   
   >>>>   
   >>>>   
   >>>   
   >>   
   >>   
   >   
      
      
   --   
   Copyright 2025 Olcott

              My 28 year goal has been to make
       "true on the basis of meaning expressed in language"
       reliably computable.

              This required establishing a new foundation
              --- 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