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 |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca