XPost: comp.theory, sci.logic   
   From: flibble@red-dwarf.jmc.corp   
      
   On Sun, 03 Aug 2025 16:15:25 -0400, Richard Damon wrote:   
      
   > On 8/3/25 12:17 PM, olcott wrote:   
   >> On 8/3/2025 11:03 AM, Mr Flibble wrote:   
   >>> On Sun, 03 Aug 2025 10:56:17 -0500, olcott wrote:   
   >>>   
   >>>> On 8/3/2025 10:45 AM, Mr Flibble wrote:   
   >>>>>   
   >>>>> Halting problem proofs are predicated on total deciders so cannot be   
   >>>>> refuted using partial deciders.   
   >>>>>   
   >>>>> /Flibble   
   >>>>   
   >>>> You are incorrect about that.   
   >>>   
   >>> No I am correct about that: you do not get to change definition of the   
   >>> halting problem unless you are working on a different problem.   
   >>>   
   >>>   
   >> You are conflating the halting problem with its convetional proof.   
   >> They are not the same thing.   
   >   
   >   
   > Maybe your problem is you don't understand the proof, because it uses   
   > logic foreign to you.   
   >   
   > The standard proof, is a proof by contradiction, something you have   
   > shown a problem in understand, because you have problem with logic.   
   >   
   > The basic idea is we create a specific input, based on whatever decider   
   > you want to claim/assume to be correct, and show that it can not be   
   > correct. To counter-example that proof means you need to show a decider,   
   > that meets the requirements of that decider, that gives the correct   
   > answer, per the definition of the problem, for an input that is built   
   > exactly by the method of the proof.   
   >   
   > Your argument fails to do this, because you keep on not using the   
   > definitions and requirments of the problem.   
   >   
   > Let us look in detail at some of these requirements.   
   >   
   > First, you seem to not understand the requirements for things to be a   
   > "program" or more specifically a "computation" in the system.   
   >   
   > There requirements include:   
   >   
   > R1) That the algorithm of the program be a fully, completely, and in   
   > full detail listing of deterministic steps that are to be used. *ALL*   
   > the step of the algorithm are part of the program. there is no   
   > "reference" to some other program, but that code needs to be included   
   > into the code of that program.   
   >   
   > You have problem with that for DDD, as DDD when it calls HHH, doesn't   
   > call some external HHH, but the copy of the code that has been put   
   > inside the code of DDD.   
   >   
   > R2) That the algorithm of the program only depends on the values on its   
   > "tape", which starts as the contents of its input, to which it can   
   > modify or add more information to it, and at the end becomes part of its   
   > "output", completed with the final-state it ends in. In particular, it   
   > means the algorith can use "global" or "static" memory as a back channel   
   > between instances of the program or between other programs. All   
   > communication is done via the use of "input".   
   >   
   > Thus, for you HHH to simulate the code of "itself" that code needs to be   
   > part of the input, but since that code should have been part of the code   
   > of DDD in the first place, it should have been there.   
   >   
   > If the code of HHH isn't there, then HHH just can't simulate the input   
   > correctly past the call HHH instruction.   
   >   
   >   
   > Next we need to look at the DEFINITION of the problem. The decider H is   
   > to decide on the behavior of some machine M given input w, and since   
   > Turing Machines can't just be put on the input tape, are communicated by   
   > ways of a representation WM. Note, the string WM fully represents the   
   > machine W, and the method to prepare this representation is defined by   
   > the programmer of the decider, so if there is some machine for which you   
   > can't make a representation to mean what that machine does, that is an   
   > error in the definition of the representation.   
   >   
   > The existance of the UTM, which can EXACTLY reproduce the behavior of   
   > any machine, says that it is possible to define a representation that   
   > can correctly represent any machine and input.   
   >   
   > Nwxt, if the representation system is sufficient, but a given input   
   > doesn't represent the machine it is supposed to, but something else,   
   > then that is an error in the person preparing that usage of the decider.   
   >   
   > Since you are on both sides of this when trying to present you counter   
   > example, YOU are at fault if the input doesn't mean what it must mean.   
   >   
   > Now for the proof program D, We start with a definition of the decider   
   > we are going to show doesn't handle *ALL* inputs, by making an input,   
   > called WM, which is a representation for a program M, that *IT* (the   
   > specified decider) doesn't get right. Said proof program takes as an   
   > input, a description of an arbitrary program (that later we will make a   
   > specific program).   
   >   
   > The proof program then, using its copy of the decider to foil, asks that   
   > decider what M applied to WM will do, by applying H to WM WM.   
   >   
   > Again, since you are claiming to be following the proof, what ever D   
   > does to ask H what M WM does must be asking THAT question or you have   
   > failed to follow the proof, and you don't have a counter example.   
   >   
   > After D asks H about that input, it then does the opposite of that   
   > result, Halting if H says it will not halt, and looping forever if H   
   > says it will halt.   
   >   
   > Lastly we make the representation of D and make that be the input, WD   
   > and give it to D.   
   >   
   > So, D will ask H applied to WD WD, which means what does D applied to WD   
   > do, and it it doesn't mean that, then YOU didn't follow the proof. and   
   > then do the opposite.   
   >   
   > Because H and D are programs per the rules of Computation Theory, all   
   > instances of them will behave the same, so   
   >   
   > If H WD WD says non-halting, then D WD, whose behavior is the meaning of   
   > the behavior of the input to H, will also use H WD WD and get that same   
   > non-halting answer, and then Halt, and thus H was wrong.   
   >   
   > If H WD WD says halting, then D WD will get that same answer and loop   
   > forever, and H was wrong.   
   >   
   > If H WD WD says anything else, or fails to answer, it is just wrong as a   
   > halt decider.   
   >   
   > There is also a varient where D doesn't take an input. but has encoded   
   > in it a way to generate its own representation, but otherwise works the   
   > same.   
   >   
   > Again H WD is DEFINED to be asking about the behavior of the Machine D,   
   > as that is what D is defined to be asking H about with that call. WD   
   > must be created to ask that question, and if you can't make such an   
   > input, that just invalidates the counter-example.   
   >   
   >   
   > A quick summary of your errors.   
   >   
   > HHH must be a specific machine, not a set of infinite machines, you need   
   > to choose the ONE that you are going to call correct. (as you can't   
   > build an input based on the infinite set).   
   >   
   > DDD must be a full program, and thus includes the HHH that it calls, it   
   > doesn't "refer" to the HHH that is simulating/deciding it. It is based   
   > on a specific one, which to be the counter example, must be the one that   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)