XPost: comp.theory, sci.math, comp.ai.philosophy   
   From: polcott333@gmail.com   
      
   On 12/8/2025 3:04 AM, Mikko wrote:   
   > olcott kirjoitti 8.12.2025 klo 5.14:   
   >> Turing machine deciders only compute a mapping from   
   >> their [finite string] inputs to an accept or reject   
   >> state on the basis that this [finite string] input   
   >> specifies or fails to specify a semantic or syntactic   
   >> property.   
   >   
   >> Within the verified truth of the above paragraph   
   >> *that took me three years to write* the halting   
   >> problem is proved to be incorrect in that it requires   
   >> that halting be computed from behavior other than   
   >> the actual behavior that the actual input actually   
   >> specifies as measured by a UTM based halt decider.   
   >   
   > The halting problem as usually posed asks for a method to determine   
   > about every computation whether it halts or runs forever. Some   
   > formulations specify further that the solution shall be expressed   
   > as a Turing machine that can be given a description of the computation.   
   >   
      
   The mistake that I have fully elaborated many dozens   
   of times and so far everyone has ignored is that the   
   halting problem as specified requires a halt decider   
   to report on a behavior that differs from the behavior   
   that its actual finite string input actually specifies.   
      
   If you are simply going to ignore that then there is   
   no reason to provide additional details.   
      
   > The halting problem does not require that the halting be computed   
   > from behaviour other that the acrual input acutally specifies.   
      
   Alternatively you are requiring a halt decider to   
   have psychic power.   
      
   int sum(int x, int y){ return x + y; }   
   The halting problem is essentially requiring   
   sum(3,4) to return the sum of 5 + 6.   
      
      
   https://github.com/plolcott/x86utm/blob/master/Halt7.c   
   HHH on line 1081   
   DD on line 1355   
      
   typedef int (*ptr)();   
   int HHH(ptr P);   
      
   int DD()   
   {   
      int Halt_Status = HHH(DD);   
      if (Halt_Status)   
        HERE: goto HERE;   
      return Halt_Status;   
   }   
      
   int main()   
   {   
      HHH(DD);   
   }   
      
   DD is simulated by HHH (according to the semantics   
   of the C programming language) until HHH sees that   
   the behavior of DD correctly matches a correct   
   non-halting behavior pattern. Then HHH aborts it   
   simulation and returns 0 indicating rejection of   
   its input.   
      
   This is the correct measure of the behavior that   
   the input to HHH(DD) actually specifies.   
      
      
   > If the input does not specify the computation that is asked about   
   > then the input is wrong and another input should be used instead.   
   > If no input that can be given specifies the behaviour asked about   
   > then the decider is not a nalting decider.   
   >   
   > The measure of the actual behaviour that the actual input actually   
   > specifies is not a UTM based halt decider. Instead the measure is   
   > whether the computation asked about halts. If the designer has not   
   > specified encoding rules that ensure that the input actually   
   > specifies the computation asked about then the halting problem is   
   > not solved.   
   >   
      
      
   --   
   Copyright 2025 Olcott

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

   
      
   This required establishing a new foundation
   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)