XPost: comp.theory, comp.lang.c   
   From: polcott333@gmail.com   
      
   On 5/1/2025 8:58 PM, André G. Isaak wrote:   
   > On 2025-05-01 19:09, olcott wrote:   
   >> On 5/1/2025 7:32 PM, André G. Isaak wrote:   
   >>> On 2025-05-01 14:15, olcott wrote:   
   >>>> On 5/1/2025 10:14 AM, André G. Isaak wrote:   
   >>>>> On 2025-04-30 21:50, olcott wrote:   
   >>>>>> On 4/30/2025 7:17 PM, André G. Isaak wrote:   
   >>>>>   
   >>>>>>> You are still hopelessly confused about your terminology.   
   >>>>>>>   
   >>>>>>> Computable functions are a subset of mathematical functions, and   
   >>>>>>> mathematical functions are *not* the same thing as C functions.   
   >>>>>>> Functions do not apply "transformations". They are simply   
   >>>>>>> mappings, and a functions which maps every pair of natural   
   >>>>>>> numbers to 5 is a perfectly legitimate, albeit not very   
   >>>>>>> interesting, function.   
   >>>>>>>   
   >>>>>>> What makes this function a *computable function* is that fact   
   >>>>>>> that it is possible to construct a C function (or a Turing   
   >>>>>>> Machine, or some other type of algorithm) such as int foo(int x,   
   >>>>>>> int y) {return 5;} which computes that particular function; but   
   >>>>>>> the C function and the computable function it computes are   
   >>>>>>> entirely separate entities.   
   >>>>>>   
   >>>>>> computes the sum of two integers   
   >>>>>> by transforming the inputs into an output.   
   >>>>>> int sum(int x, int y) { return x + y; }   
   >>>>>>   
   >>>>>> Computes no function because it ignores its inputs.   
   >>>>>> int sum(int x, int y) { return 5; }   
   >>>>>   
   >>>>> All you're demonstrating here is that you have no clue what a   
   >>>>> function is, nor, apparently, do you have any desire to learn.   
   >>>>>   
   >>>>> André   
   >>>>>   
   >>>>   
   >>>> What I am explaining is that a halt decider   
   >>>> must compute the mapping FROM THE INPUTS ONLY   
   >>>> by applying a specific set of finite string   
   >>>> transformations to the inputs.   
   >>>   
   >>> No. Halt deciders weren't even mentioned above. I was addressing your   
   >>> absurd claim that int foo(int x, int y) { return 5; } does not   
   >>> compute a function. This clearly indicates that you do not grasp the   
   >>> concept of "function".   
   >>>   
   >>   
   >> This is a brand new elaboration of computer   
   >> science that I just came up with.   
   >   
   > IOW something you've pulled out of your ass.   
   >   
   >> It is common knowledge THAT inputs must correspond   
   >> to OUTPUTS. What is totally unknown and brand new   
   >> created by me is HOW inputs are made to correspond   
   >> to OUTPUTS.   
   >   
   > We were discussing functions. Functions don't have inputs or outputs;   
   > they have domains and codomains. ALGORITHMS have inputs and outputs, and   
   > you keep conflating the two.   
   >   
   >> Specific finite string transformation rules are   
   >> applied to inputs to derive outputs.   
   >   
   > Please point to a definition of 'function' which mentions "finite string   
   > transformation rules". This may be a useful way of viewing some (but   
   > certainly not all) algorithms, but it has nothing to do with functions.   
   > Functions are simply a mapping from one set (the domain) to another set   
   > (the codomain) such that every element of the domain maps to one and   
   > only one element of the codomain.   
   >   
   >> What everyone else has been doing is simply GUESSING   
   >> that they correspond or relying on some authority   
   >> that say they must correspond. (Appeal to authority error).   
   >   
   > This is another baseless assertion that you've simply pulled out of your   
   > ass. If you think otherwise, please provide a concrete example   
   >   
   >> DD correctly emulated by HHH maps to NON-HALTING BEHAVIOR.   
   >> It really does, all that you have to do is PAY ATTENTION.   
   >   
   > Whether DD emulated by HH maps to halting or non-halting behaviour is   
   > entirely dependent on which function is being computed.   
   >   
   > André   
   >   
      
   We are computing the halt function   
   FOR THE INPUT NOT ANY DAMN THING ELSE   
   FOR THE INPUT NOT ANY DAMN THING ELSE   
   FOR THE INPUT NOT ANY DAMN THING ELSE   
   FOR THE INPUT NOT ANY DAMN THING ELSE   
      
   FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG   
   FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG   
   FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG   
      
   int DD()   
   {   
      int Halt_Status = HHH(DD);   
      if (Halt_Status)   
        HERE: goto HERE;   
      return Halt_Status;   
   }   
      
   DD correctly simulated by HHH specifies recursive   
   simulation such that DD cannot possibly reach its   
   "return instruction" (final halt state). Thus HHH   
   is correct to reject DD as non halting.   
      
      
        If simulating halt decider H correctly simulates its input D   
        until H correctly determines that its simulated D would never   
        stop running unless aborted then   
      
        H can abort its simulation of D and correctly report that D   
        specifies a non-halting sequence of configurations.   
      
      
      
   --   
   Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius   
   hits a target no one else can see." Arthur Schopenhauer   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)