1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: Turing computable function for sum of two integers

    From Richard Heathfield@21:1/5 to olcott on Wed Apr 30 19:20:01 2025
    On 30/04/2025 18:36, olcott wrote:

    <snip>

    int sum(int x, int y) { return 5; }
    Is NOT a Turing Computable function for the sum of two integers.

    It is, however, a computable (albeit trivial and poorly-named)
    function.

    int sum(int x, int y) { x + y; }
    Is a Turing Computable function for the sum of two integers.

    Not quite. It's a computable function for the sum of two
    integers, both of which are in the range INT_MIN to INT_MAX, and
    whose sum is also within that range. sum(INT_MAX, INT_MAX)
    doesn't calculate what you claim, but merely invokes undefined
    behaviour.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Apr 30 19:55:37 2025
    On 4/30/25 1:36 PM, olcott wrote:
    On 4/29/2025 4:50 AM, Mikko wrote:
    On 2025-04-28 19:55:35 +0000, olcott said:

    On 4/28/2025 11:01 AM, dbush wrote:
    On 4/28/2025 11:52 AM, olcott wrote:
    On 4/28/2025 4:01 AM, Mikko wrote:
    On 2025-04-16 17:36:31 +0000, olcott said:

    On 4/16/2025 7:29 AM, Richard Heathfield wrote:
    On 16/04/2025 12:40, olcott wrote:
    sum(3,2) IS NOT THE SAME AS sum(5,2).
    IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO
    GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION
    INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS.

    Whether sum(3,2) is or is not the same as sum(5,2) is not the
    question. The question is whether a universal termination
    analyser can be constructed, and the answer is that it can't.

    This has been rigorously proved. If you want to overturn the
    proof you've got your work cut out to persuade anyone to listen, >>>>>>>> not least because anyone who tries to enter into a dialogue with >>>>>>>> you is met with contempt and scorn.

    The proof stands.


    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*

    Not freaking allowed to look at any damn thing
    else besides the freaking input. Must compute whatever
    mapping ACTUALLY EXISTS FROM THIS INPUT.

    A halt decider is is not allowed to compute "whatever" mapping. It is >>>>>> required to compute one specific mapping: to "no" if the computation >>>>>> described by the input can be continesd forever without halting, to >>>>>> "no" otherwise.


    It must do this by applying the finite string transformation
    rules specified by the x86 language to the input to HHH(DD).

    This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD.
    It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE
    EMULATION OF HHH EMULATING ITSELF EMULATING DD.



    In other words, no H exists that satisfies the following requirements,

    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.

    You have not proven that the requirements are wrong in any sense.


    int sum(int x, int y) { return 5; }
    Is NOT a Turing Computable function for the sum of two integers.

    But it *


    int sum(int x, int y) { x + y; }
    Is a Turing Computable function for the sum of two integers.


    No, it is an algorithm in the C language to compute the Computable
    Function for addition.

    No algorithm/program is a "Function" in the computation theory sense of
    the word, that is just a category error.

    algorithms/programs COMPUTE Functions, which are just the complete
    mapping of inputs to outputs that the Function Defines.

    Being Computable just means that an algorithm/program exists that
    computes it.

    Perhaps you need to go back to Freshman Programming to learn the
    meanings of the words you are misusing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu May 1 07:43:47 2025
    On 4/30/25 8:24 PM, olcott wrote:
    On 4/30/2025 6:55 PM, Richard Damon wrote:
    On 4/30/25 1:36 PM, olcott wrote:
    On 4/29/2025 4:50 AM, Mikko wrote:
    On 2025-04-28 19:55:35 +0000, olcott said:

    On 4/28/2025 11:01 AM, dbush wrote:
    On 4/28/2025 11:52 AM, olcott wrote:
    On 4/28/2025 4:01 AM, Mikko wrote:
    On 2025-04-16 17:36:31 +0000, olcott said:

    On 4/16/2025 7:29 AM, Richard Heathfield wrote:
    On 16/04/2025 12:40, olcott wrote:
    sum(3,2) IS NOT THE SAME AS sum(5,2).
    IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO
    GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION
    INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS.

    Whether sum(3,2) is or is not the same as sum(5,2) is not the >>>>>>>>>> question. The question is whether a universal termination
    analyser can be constructed, and the answer is that it can't. >>>>>>>>>>
    This has been rigorously proved. If you want to overturn the >>>>>>>>>> proof you've got your work cut out to persuade anyone to
    listen, not least because anyone who tries to enter into a >>>>>>>>>> dialogue with you is met with contempt and scorn.

    The proof stands.


    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*

    Not freaking allowed to look at any damn thing
    else besides the freaking input. Must compute whatever
    mapping ACTUALLY EXISTS FROM THIS INPUT.

    A halt decider is is not allowed to compute "whatever" mapping. >>>>>>>> It is
    required to compute one specific mapping: to "no" if the
    computation
    described by the input can be continesd forever without halting, to >>>>>>>> "no" otherwise.


    It must do this by applying the finite string transformation
    rules specified by the x86 language to the input to HHH(DD).

    This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD.
    It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE >>>>>>> EMULATION OF HHH EMULATING ITSELF EMULATING DD.



    In other words, no H exists that satisfies the following
    requirements,

    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED. >>>>> BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED. >>>>> BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED. >>>>> BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED. >>>>> BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED. >>>>
    You have not proven that the requirements are wrong in any sense.


    int sum(int x, int y) { return 5; }
    Is NOT a Turing Computable function for the sum of two integers.

    But it *


    int sum(int x, int y) { x + y; }
    Is a Turing Computable function for the sum of two integers.


    No, it is an algorithm in the C language to compute the Computable
    Function for addition.

    No algorithm/program is a "Function" in the computation theory sense
    of the word, that is just a category error.

    algorithms/programs COMPUTE Functions, which are just the complete
    mapping of inputs to outputs that the Function Defines.


    YES that means that HHH(DD) is not allowed to report
    on the direct execution of DD(DD) because the input
    to HHH(DD) maps to something else.

    No. The Halting Function maps the input DD to Halting.

    The fact that the algorithm of HHH maps DD to Non-Halting just says that
    HHH doesn't correctly compute the required mapping.


    When one maps an input to an output one must apply
    very specific finite string transformation rules.
    One cannot simply guess what one wants to end up
    with and simply assume that this mapping is correct.

    The mapping generated by an algorithm are limited by that.

    The mapping required of an algorithm are not, but are specified by the
    mapping of the function that is being asked to compute.

    That mapping is fully and completely specified by the mapping rule of
    the halting function:

    Halt(P, D) maps (P,D) to Halting if the program P when given the input D
    will halt in a finite number of steps, and to Non-Halting, if the
    program P when givne the input D will never halt, even after doing an
    unbonded number of steps.

    Since DD *WILL* reach a final state when run, it maps to Halting.

    The fact that HHH can't emulate it to that point is irrelevent, it just
    is part of what makes it non-computable.

    Note, input DD, to be a valid input, must be a program, and thus include
    the code of the specific HHH that it calls, which by your problem
    stipulations is the one that aborts and returns 0 as defined in Halt7.c


    *DD correctly emulated by HHH DOES NOT HALT*

    That is a NULL statement, as it is based on a lie.

    HHH doesn't do a correct emulation, and thus your house of cards has
    been blown to smithereens by being based on errors.


    Being Computable just means that an algorithm/program exists that
    computes it.

    Perhaps you need to go back to Freshman Programming to learn the
    meanings of the words you are misusing.

    No level of computer science education ever gets
    around to specifying the details of how the mapping
    from inputs to outputs must occur.

    I came up with this on my own. Turing Machine algorithms
    that compute functions must apply finite string transformations
    to inputs to derive outputs.

    That means that DD correctly emulated by HHH DOES NOT HALT!


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to dbush on Fri May 2 11:18:51 2025
    On 2025-04-30 19:57:00 +0000, dbush said:

    On 4/30/2025 1:36 PM, olcott wrote:
    On 4/29/2025 4:50 AM, Mikko wrote:
    On 2025-04-28 19:55:35 +0000, olcott said:

    On 4/28/2025 11:01 AM, dbush wrote:
    On 4/28/2025 11:52 AM, olcott wrote:
    On 4/28/2025 4:01 AM, Mikko wrote:
    On 2025-04-16 17:36:31 +0000, olcott said:

    On 4/16/2025 7:29 AM, Richard Heathfield wrote:
    On 16/04/2025 12:40, olcott wrote:
    sum(3,2) IS NOT THE SAME AS sum(5,2).
    IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO
    GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION
    INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS.

    Whether sum(3,2) is or is not the same as sum(5,2) is not the question.
    The question is whether a universal termination analyser can be >>>>>>>>> constructed, and the answer is that it can't.

    This has been rigorously proved. If you want to overturn the proof >>>>>>>>> you've got your work cut out to persuade anyone to listen, not least >>>>>>>>> because anyone who tries to enter into a dialogue with you is met with
    contempt and scorn.

    The proof stands.


    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*

    Not freaking allowed to look at any damn thing
    else besides the freaking input. Must compute whatever
    mapping ACTUALLY EXISTS FROM THIS INPUT.

    A halt decider is is not allowed to compute "whatever" mapping. It is >>>>>>> required to compute one specific mapping: to "no" if the computation >>>>>>> described by the input can be continesd forever without halting, to >>>>>>> "no" otherwise.


    It must do this by applying the finite string transformation
    rules specified by the x86 language to the input to HHH(DD).

    This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD.
    It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE
    EMULATION OF HHH EMULATING ITSELF EMULATING DD.



    In other words, no H exists that satisfies the following requirements, >>>>
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.

    You have not proven that the requirements are wrong in any sense.


    int sum(int x, int y) { return 5; }
    Is NOT an algorithm for the sum of two integers.

    int sum(int x, int y) { x + y; }
    Is an algorithm for the sum of two integers.

    Obviously, but that has nothing to do with a solution to the halting function:

    Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:

    It does. The first "sum" is analogous to Olcott's halting deciders that are like a real halting decider except that they compute another function.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Fri May 2 11:15:34 2025
    On 2025-04-30 17:36:44 +0000, olcott said:

    On 4/29/2025 4:50 AM, Mikko wrote:
    On 2025-04-28 19:55:35 +0000, olcott said:

    On 4/28/2025 11:01 AM, dbush wrote:
    On 4/28/2025 11:52 AM, olcott wrote:
    On 4/28/2025 4:01 AM, Mikko wrote:
    On 2025-04-16 17:36:31 +0000, olcott said:

    On 4/16/2025 7:29 AM, Richard Heathfield wrote:
    On 16/04/2025 12:40, olcott wrote:
    sum(3,2) IS NOT THE SAME AS sum(5,2).
    IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO
    GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION
    INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS.

    Whether sum(3,2) is or is not the same as sum(5,2) is not the question.
    The question is whether a universal termination analyser can be >>>>>>>> constructed, and the answer is that it can't.

    This has been rigorously proved. If you want to overturn the proof >>>>>>>> you've got your work cut out to persuade anyone to listen, not least >>>>>>>> because anyone who tries to enter into a dialogue with you is met with >>>>>>>> contempt and scorn.

    The proof stands.


    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*
    *corresponding output to the input*

    Not freaking allowed to look at any damn thing
    else besides the freaking input. Must compute whatever
    mapping ACTUALLY EXISTS FROM THIS INPUT.

    A halt decider is is not allowed to compute "whatever" mapping. It is >>>>>> required to compute one specific mapping: to "no" if the computation >>>>>> described by the input can be continesd forever without halting, to >>>>>> "no" otherwise.


    It must do this by applying the finite string transformation
    rules specified by the x86 language to the input to HHH(DD).

    This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD.
    It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE
    EMULATION OF HHH EMULATING ITSELF EMULATING DD.



    In other words, no H exists that satisfies the following requirements,

    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.
    BECAUSE THOSE REQUIREMENTS HAVE ALWAYS BEEN WRONG AND NO ONE NOTICED.

    You have not proven that the requirements are wrong in any sense.

    int sum(int x, int y) { return 5; }
    Is NOT a Turing Computable function for the sum of two integers.

    It is a Turing computable computable function of two integers. It is not
    the functiona that the vernacular term "sum" is usually understood to
    mean.

    int sum(int x, int y) { x + y; }
    Is a Turing Computable function for the sum of two integers.

    Right. But in order to compute the function the two integers and the
    value of the function must be reasonably encoded.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)