• Detecting infinite recursion

    From olcott@NoOne@NoWhere.com to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Fri Feb 26 13:53:42 2021
    From Newsgroup: comp.lang.c++

    (1) We know that every software function invoked with the same data must
    have the same execution trace.

    (2) When a software function invokes itself this is recursive invocation.

    (3) When the second recursive invocation of a software function calls
    itself with the same data as the prior invocation then it must have the
    same execution trace as the prior invocation.

    (4) When the second recursive invocation of a software function calls
    itself with the same data has no conditional branch instructions
    inbetween these two invocations then this is a case of infinite recursion.

    (5) When the recursive invocation is replaced with a call to a software
    system that simulates the execution of the calling function with its
    same data, then this is equivalent to a recursive invocation.

    // P has address of H_Hat
    void H_Hat(u32 P)
    {
    Simulate(P, P);
    }

    Does everyone agree?
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Siri Cruise@chine.bleu@yahoo.com to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Fri Feb 26 12:48:20 2021
    From Newsgroup: comp.lang.c++

    In article <3LadneKdoK8jzKT9nZ2dnUU78T3NnZ2d@giganews.com>,
    olcott <NoOne@NoWhere.com> wrote:

    Does everyone agree?

    P = \a.P(succ(a))
    P 0


    (1) We know that every software function invoked with the same data must have the same execution trace.

    When does a recursion use the same data?
    --
    :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
    'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \
    I am an Andrea Doria sockpuppet. insults Islam. Mohammed
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Mr Flibble@flibble@i42.REMOVETHISBIT.co.uk to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Fri Feb 26 21:37:29 2021
    From Newsgroup: comp.lang.c++

    On 26/02/2021 19:53, olcott wrote:
    (1) We know that every software function invoked with the same data must have
    the same execution trace.

    (2) When a software function invokes itself this is recursive invocation.

    (3) When the second recursive invocation of a software function calls itself with the same data as the prior invocation then it must have the same execution
    trace as the prior invocation.

    (4) When the second recursive invocation of a software function calls itself with the same data has no conditional branch instructions inbetween these two
    invocations then this is a case of infinite recursion.

    (5) When the recursive invocation is replaced with a call to a software system
    that simulates the execution of the calling function with its same data, then
    this is equivalent to a recursive invocation.

    // P has address of H_Hat
    void H_Hat(u32 P)
    {
      Simulate(P, P);
    }

    Does everyone agree?

    No.

    (-1) In general for an algorithm or program to perform useful work its functions
    contain branching logic.

    (0) Only pure functions may not modify mutable state.

    ...

    (6) ???

    (7) ???

    (8) ???

    ...

    (???) ???

    ...

    /Flibble
    --
    😎
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Siri Cruise@chine.bleu@yahoo.com to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Fri Feb 26 15:26:35 2021
    From Newsgroup: comp.lang.c++

    In article <tSd_H.261436$Wue5.69200@fx13.ams4>,
    Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk> wrote:

    (-1) In general for an algorithm or program to perform useful work its functions
    contain branching logic.

    (0) Only pure functions may not modify mutable state.

    goldbach = \n.[
    goldbachsum(n, 2, 2) -> goldbach(n+2);
    true -> halt
    ]
    goldbachsum = \n,r,s. [
    r>=n -> false;
    not prime(r, 2) -> goldbachsum(n, r+1, 2);
    not prime(s, 2) -> goldbachsum(n, r, s+1);
    r+s>n -> goldbachsum(n, r+1, 2);
    r+s<n -> goldbachsum(n, r, s+1);
    r+s=n -> true;
    ]
    prime = \n,r.[
    r*r>n -> true;
    n mod r=0 -> false;
    true -> prime(n, r+1)
    ]

    Prove goldbach(2) halts or never halts and you win a Hero of the
    Mathematics badge.
    --
    :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
    'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \
    I am an Andrea Doria sockpuppet. insults Islam. Mohammed
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Kaz Kylheku@563-365-8930@kylheku.com to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Sat Feb 27 01:58:53 2021
    From Newsgroup: comp.lang.c++

    On 2021-02-26, olcott <NoOne@NoWhere.com> wrote:
    (1) We know that every software function invoked with the same data must have the same execution trace.

    (2) When a software function invokes itself this is recursive invocation.

    (3) When the second recursive invocation of a software function calls
    itself with the same data as the prior invocation then it must have the
    same execution trace as the prior invocation.

    (4) When the second recursive invocation of a software function calls
    itself with the same data has no conditional branch instructions
    inbetween these two invocations then this is a case of infinite recursion.

    (5) When the recursive invocation is replaced with a call to a software system that simulates the execution of the calling function with its
    same data, then this is equivalent to a recursive invocation.

    // P has address of H_Hat
    void H_Hat(u32 P)
    {
    Simulate(P, P);
    }

    Does everyone agree?

    If Simulate(P, P) replaces P(P), and the simulation is a faithful
    replica of the processor, then nothing has changed.

    You have previosuly written about a scheme in which Simulate
    contains provisions for monitoring the execution. An outer Simulate has instruction stream information from all inner Simulate calls and is able
    to impose the rule that the simulation will only go to some fixed number
    of levels, like 3. Let's call that N.

    Firstly, what that does is change H_Hat: H_Hat is no longer infinitely recursive, because Simulate detects an internal halting condition and
    stops.

    Secondly, the different recursion levels of H_Hat are not equivalent
    to each other.

    The outer-most H_Hat goes to N levels of recursion/simulation nesting.

    The next lower nesting, though ostensibly executing the same logic,
    only has N-1 remaining levels available to it before it will be
    terminated.

    The one after that N-2.

    A function that terminates after U nestings is not the same function
    as a similar one which terminates after V nestings, for U != V.

    We must treat each H_Hat invocation at every nesting level i as a
    different function H_Hat_i.
    --
    TXR Programming Language: http://nongnu.org/txr
    Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Jeff Barnett@jbb@notatt.com to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Fri Feb 26 21:32:04 2021
    From Newsgroup: comp.lang.c++

    On 2/26/2021 12:53 PM, olcott wrote:
    (1) We know that every software function invoked with the same data must have the same execution trace.

    (2) When a software function invokes itself this is recursive invocation.

    (3) When the second recursive invocation of a software function calls
    itself with the same data as the prior invocation then it must have the
    same execution trace as the prior invocation.

    (4) When the second recursive invocation of a software function calls
    itself with the same data has no conditional branch instructions
    inbetween these two invocations then this is a case of infinite recursion.

    (5) When the recursive invocation is replaced with a call to a software system that simulates the execution of the calling function with its
    same data, then this is equivalent to a recursive invocation.

    // P has address of H_Hat
    void H_Hat(u32 P)
    {
      Simulate(P, P);
    }

    Does everyone agree?
    You took off all of this time to come up with this. Remember when you
    were pooping in the Lisp group without a clue of what you were talking
    about or knowledge of any modern Lisp? Disgraceful! Consider a function
    which accesses a variable bound outside its scope - there are many
    variations here and this is why you should have learned some Lisp
    instead of just pooping. Then the above is incorrect. Of course you have something different in mind but are making a pig of terminology. Above
    you say "software" function and that is what I'm talking about. If you
    mean "mathematical" function, well do you remember the definition of a mathematical function? In this case, you are correct but that has little or nothing to do with software. I suggest another hiatus for you but
    make it longer this time. Much longer.
    --
    Jeff Barnett
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From om@om@iki.fi (Otto J. Makela) to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Tue Mar 2 18:36:43 2021
    From Newsgroup: comp.lang.c++

    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve
    the halting problem for all possible program-input pairs cannot exist.
    --
    /* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
    /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
    /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
    /* * * Computers Rule 01001111 01001011 * * * * * * */
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 11:22:41 2021
    From Newsgroup: comp.lang.c++

    On 3/2/2021 10:36 AM, Otto J. Makela wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve
    the halting problem for all possible program-input pairs cannot exist.


    Yes. The key brand new insight that I had about this proof is that the
    actual execution trace never reaches the undecidable portion, thus
    making the conventional halting problem counter-examples {Linz, Sipser,
    Kozen} decidable.

    // P has the machine address of H_Hat()
    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    return;
    }

    "It looks like the original specification provided in
    the Linz text may be infinitely recursive in that each
    TM requires its own input."

    Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
    (concrete example) August 2016 https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example


    Infinitely Recursive input on HP Proofs (March 11, 2017) https://groups.google.com/g/comp.theory/c/NcFS02hKs1U/m/PlBF-1LRBAAJ



    Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company (315-320)

    Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
    PWS Publishing Company (165-167)

    Kozen, Dexter 1997. Automata and Computability. New York:
    Springer-Verlag. (231-234).
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Kaz Kylheku@563-365-8930@kylheku.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 17:46:31 2021
    From Newsgroup: comp.lang.c++

    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 10:36 AM, Otto J. Makela wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve
    the halting problem for all possible program-input pairs cannot exist.


    Yes. The key brand new insight that I had about this proof is that the actual execution trace never reaches the undecidable portion, thus

    The program has no "undecidable portion". We know perfectly well
    whether it terminates or not, because it is trivial.

    All that is undecidable, in the context of computability, is the problem
    of determining whether any program whatsoever on any input terminates.

    "Undecidable

    making the conventional halting problem counter-examples {Linz, Sipser, Kozen} decidable.

    Each such example is individually decidable, and everybody knows this.

    No example of anything even moderately hard to decide is ever presented
    in the proofs.

    // P has the machine address of H_Hat()
    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    return;
    }

    Everyone, including probably most CS undergrads by the time they reach
    senior year, that if Halts decides that it's a good idea to "decide"
    halting by simply running the code, runaway recursion will occur.

    When I first encountered the halting problem concept, I remember that
    the text I was reading mentioned this: if the decision function jus
    executes the function, it precipitates into infinite regress, and
    therefore does not terminate, in which case there is no decision.

    You have not discovered anything.

    Also, the idea of an insruction stream that has no branches corresponds
    to the well-known concept of a basic block in program control flow
    analysis, used in compilers. Again, something even CS undergrads know by
    the time they graduate.
    --
    TXR Programming Language: http://nongnu.org/txr
    Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 13:00:07 2021
    From Newsgroup: comp.lang.c++

    On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 10:36 AM, Otto J. Makela wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve >>> the halting problem for all possible program-input pairs cannot exist.


    Yes. The key brand new insight that I had about this proof is that the
    actual execution trace never reaches the undecidable portion, thus

    The program has no "undecidable portion". We know perfectly well
    whether it terminates or not, because it is trivial.


    Daryl McCullough https://groups.google.com/g/comp.theory/c/wgJjJR78FaU/m/_eWPqsSS8bEJ
    I can finally give credit where credit is due. Daryl McCullough was the
    one that originally came up with this analogy in March of 2012.

    When we ask Bill: Is your answer to this question "no" ?
    Bill cannot possibly provide a correct answer because both answers of
    "yes" and "no" form a contradiction.

    In this same way Halts() cannot possibly provide a correct return value indicating halting / non halting to H_Hat().

    // P has the machine address of H_Hat()
    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts2(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    return;
    }

    The brand new insight that I documented that I came up with in 2016 was
    that a halt decider that examines the simulation of its input as the
    basis for its halting decision would never reach the point where it
    returns any value to H_Hat().
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Kaz Kylheku@563-365-8930@kylheku.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 19:35:20 2021
    From Newsgroup: comp.lang.c++

    ["Followup-To:" header set to comp.lang.c.]
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 10:36 AM, Otto J. Makela wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve >>>> the halting problem for all possible program-input pairs cannot exist. >>>>

    Yes. The key brand new insight that I had about this proof is that the
    actual execution trace never reaches the undecidable portion, thus

    The program has no "undecidable portion". We know perfectly well
    whether it terminates or not, because it is trivial.


    Daryl McCullough https://groups.google.com/g/comp.theory/c/wgJjJR78FaU/m/_eWPqsSS8bEJ
    I can finally give credit where credit is due. Daryl McCullough was the
    one that originally came up with this analogy in March of 2012.

    When we ask Bill: Is your answer to this question "no" ?
    Bill cannot possibly provide a correct answer because both answers of
    "yes" and "no" form a contradiction.

    Since we are not part of the program, there is no contradiction in our
    answer when we decide whether the example terminates or not.

    If the example terminates and gives a result, that result may have
    the interpretation that it is wrong; i.e. a contradiction.

    If the program's is taken to mean "I do not halt", than that is wrong;
    That has no bearing on the fact that the program has halted, and
    that our own answer "it has halted" is right.

    The decider is only shown wrong on that one example, not that it's
    on all inputs. The decider is not absolutely contradicted.

    The brand new insight that I documented that I came up with in 2016 was
    that a halt decider that examines the simulation of its input as the
    basis for its halting decision would never reach the point where it
    returns any value to H_Hat().

    This is undergrad-level obvious that if the decider, instead of
    implementing some actual decision algorithm, simply executes the input,
    then if that input does not terminate, that "decision" will also not
    terminate, and that it is victim to infinite regress.

    The first time I learned about the halting problem, it was in a textbook
    which noted this obvious fact.

    You should be more humble in your claims that you have some brand new
    result.
    --
    TXR Programming Language: http://nongnu.org/txr
    Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 13:50:07 2021
    From Newsgroup: comp.lang.c++

    On 3/2/2021 1:00 PM, olcott wrote:
    On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 10:36 AM, Otto J. Makela wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to
    solve
    the halting problem for all possible program-input pairs cannot exist. >>>>

    Yes. The key brand new insight that I had about this proof is that the
    actual execution trace never reaches the undecidable portion, thus

    The program has no "undecidable portion". We know perfectly well
    whether it terminates or not, because it is trivial.


    There is a much earlier attribution to the same person:

    sci.logic Daryl McCullough June 25, 2004
    On Friday, June 25, 2004 at 6:30:39 PM UTC-5, Daryl McCullough wrote:
    You ask someone (we'll call him "Jack") to give a truthful
    yes/no answer to the following question:
    Will Jack's answer to this question be no?
    Jack can't possibly give a correct yes/no answer to the question.

    https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ

    Jack cannot possibly provide a correct answer because both answers of
    "yes" and "no" form a contradiction.

    In this same way Halts() cannot possibly provide a correct return value indicating halting / non halting to H_Hat().

    // P has the machine address of H_Hat()
    void H_Hat(u32 P)
    {
      u32 Input_Halts = Halts2(P, P);
      if (Input_Halts)
        HERE: goto HERE;
      return;
    }

    The brand new insight that I documented that I came up with in 2016 was
    that a halt decider that examines the simulation of its input as the
    basis for its halting decision would never reach the point where it
    returns any value to H_Hat().


    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Kaz Kylheku@563-365-8930@kylheku.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 19:57:24 2021
    From Newsgroup: comp.lang.c++

    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 1:00 PM, olcott wrote:
    On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 10:36 AM, Otto J. Makela wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to
    solve
    the halting problem for all possible program-input pairs cannot exist. >>>>>

    Yes. The key brand new insight that I had about this proof is that the >>>> actual execution trace never reaches the undecidable portion, thus

    The program has no "undecidable portion". We know perfectly well
    whether it terminates or not, because it is trivial.


    There is a much earlier attribution to the same person:

    sci.logic Daryl McCullough June 25, 2004
    On Friday, June 25, 2004 at 6:30:39 PM UTC-5, Daryl McCullough wrote:
    You ask someone (we'll call him "Jack") to give a truthful
    yes/no answer to the following question:
    Will Jack's answer to this question be no?
    Jack can't possibly give a correct yes/no answer to the question.

    https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ

    Jack cannot possibly provide a correct answer because both answers of
    "yes" and "no" form a contradiction.

    What you're perpetually missing is that a mathematical or
    computatational function isn't Jack. If it gives a "yes" answer for some
    input, it can give no other answer. Functions don't have the choice of re-evaluating their answer and changing it.

    Much of your rhetoric in this direction is laced with
    anthropomorphic fallacy.

    If we edit a function to give a different answer for the same input,
    we are creating a different function. Since the input is the function
    itself, the input has changed too!

    You continue to be confused by this point; your work history consists
    of producing different versions of code under the same names, taking
    different inputs under the same name, and speaking about it in terms as
    if they are all one thing.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 14:20:18 2021
    From Newsgroup: comp.lang.c++

    On 3/2/2021 1:57 PM, Kaz Kylheku wrote:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 1:00 PM, olcott wrote:
    On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    On 3/2/2021 10:36 AM, Otto J. Makela wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're >>>>>> trying to overturn Turing's proof that that a general algorithm to >>>>>> solve
    the halting problem for all possible program-input pairs cannot exist. >>>>>>

    Yes. The key brand new insight that I had about this proof is that the >>>>> actual execution trace never reaches the undecidable portion, thus

    The program has no "undecidable portion". We know perfectly well
    whether it terminates or not, because it is trivial.


    There is a much earlier attribution to the same person:

    sci.logic Daryl McCullough June 25, 2004
    On Friday, June 25, 2004 at 6:30:39 PM UTC-5, Daryl McCullough wrote:
    You ask someone (we'll call him "Jack") to give a truthful
    yes/no answer to the following question:
    Will Jack's answer to this question be no?
    Jack can't possibly give a correct yes/no answer to the question.

    https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ

    Jack cannot possibly provide a correct answer because both answers of
    "yes" and "no" form a contradiction.

    What you're perpetually missing is that a mathematical or
    computatational function isn't Jack. If it gives a "yes" answer for some input, it can give no other answer. Functions don't have the choice of re-evaluating their answer and changing it.

    Much of your rhetoric in this direction is laced with
    anthropomorphic fallacy.

    If we edit a function to give a different answer for the same input,
    we are creating a different function. Since the input is the function
    itself, the input has changed too!

    You continue to be confused by this point; your work history consists
    of producing different versions of code under the same names, taking different inputs under the same name, and speaking about it in terms as
    if they are all one thing.


    // P has the machine address of H_Hat()
    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    return;
    }

    Although you may endlessly dodge this point it remains perfectly true
    that both possible Boolean return values from Halts() to H_Hat() would
    be made incorrect on the basis that they are contradicted.

    It is also a verified fact that these return values are contradicted in
    the exact same pathological self-reference(Olcott 2004) way that makes
    it impossible for Jack to provide a correct answer to this question:
    Is the answer to this question no?
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Keith Thompson@Keith.S.Thompson+u@gmail.com to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Tue Mar 2 12:57:16 2021
    From Newsgroup: comp.lang.c++

    Kaz Kylheku <563-365-8930@kylheku.com> writes:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    [more of the same]

    Kaz, olcott's article to which you replied was posted to
    comp.theory, comp.lang.c, comp.lang.c++, and comp.software-eng,
    with followups directed to comp.lang.c. Your followup ignored the "Followup-To: comp.theory" header line and cross-posted to all
    four newsgroups.

    Is your newsreader buggy, or are you deliberately making
    inappropriate cross-posts, or is something else going on?

    I've cross-posted this article and set followups to comp.theory only.
    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips Healthcare
    void Void(void) { Void(); } /* The recursive call of the void */
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From gazelle@gazelle@shell.xmission.com (Kenny McCormack) to comp.theory,comp.lang.c,comp.lang.c++,comp.software-eng on Wed Mar 3 02:17:54 2021
    From Newsgroup: comp.lang.c++

    In article <874khtjmtv.fsf@nosuchdomain.example.com>,
    Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Kaz Kylheku <563-365-8930@kylheku.com> writes:
    On 2021-03-02, olcott <NoOne@NoWhere.com> wrote:
    [more of the same]

    Kaz, olcott's article to which you replied was posted to
    comp.theory, comp.lang.c, comp.lang.c++, and comp.software-eng,
    with followups directed to comp.lang.c. Your followup ignored the >"Followup-To: comp.theory" header line and cross-posted to all
    four newsgroups.

    Is your newsreader buggy, or are you deliberately making
    inappropriate cross-posts, or is something else going on?

    I've cross-posted this article and set followups to comp.theory only.

    Wow. I'm so impressed.
    --
    People who want to share their religious views with you
    almost never want you to share yours with them. -- Dave Barry
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 07:23:53 2021
    From Newsgroup: comp.lang.c++

    In comp.lang.c++ Otto J. Makela <om@iki.fi> wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve
    the halting problem for all possible program-input pairs cannot exist.

    If the halting problem could be solved, it would be great news for
    mathematics. Pretty much all unsolved problems in mathematics, at least
    those that can be computed with an algorithm, would be solved in one
    fell swoop.

    The Riemann hypothesis? Simply create a program that checks every
    single non-trivial zero of the zeta function and stops when it finds
    one that's not on the critical line. Then simply use the marvelous
    halting problem solution above to see if it ever terminates, and
    you'll have proven the Riemann hypothesis as true or false.

    Do odd perfect numbers exist? Simply create a program that goes
    through every odd number and checks if it's perfect, and terminates
    when it finds one. Use the halting problem proof to check if it will
    ever terminate and you'll have solved the problem.

    Collatz conjecture? Same thing. And so on and so forth.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Wed Mar 3 08:58:48 2021
    From Newsgroup: comp.lang.c++

    On 03/03/2021 08:23, Juha Nieminen wrote:
    In comp.lang.c++ Otto J. Makela <om@iki.fi> wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve
    the halting problem for all possible program-input pairs cannot exist.

    If the halting problem could be solved, it would be great news for mathematics. Pretty much all unsolved problems in mathematics, at least
    those that can be computed with an algorithm, would be solved in one
    fell swoop.

    The Riemann hypothesis? Simply create a program that checks every
    single non-trivial zero of the zeta function and stops when it finds
    one that's not on the critical line. Then simply use the marvelous
    halting problem solution above to see if it ever terminates, and
    you'll have proven the Riemann hypothesis as true or false.

    Do odd perfect numbers exist? Simply create a program that goes
    through every odd number and checks if it's perfect, and terminates
    when it finds one. Use the halting problem proof to check if it will
    ever terminate and you'll have solved the problem.

    Collatz conjecture? Same thing. And so on and so forth.


    I think Pete Olcott already said that he was not a mathematician. So
    that means he is not constrained by such simple mathematical logic, and
    can solve the impossible in an way that mathematicians cannot.

    You know, in the same way that non-physicists are not constrained by
    physical laws that they don't understand, and can thus make moon rockets
    in their garage powered by gravity-repulsive paint.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 08:50:22 2021
    From Newsgroup: comp.lang.c++

    David Brown <david.brown@hesbynett.no> wrote:
    I think Pete Olcott already said that he was not a mathematician. So
    that means he is not constrained by such simple mathematical logic, and
    can solve the impossible in an way that mathematicians cannot.

    You know, in the same way that non-physicists are not constrained by
    physical laws that they don't understand, and can thus make moon rockets
    in their garage powered by gravity-repulsive paint.

    I haven't followed what he has written and said about his approach, but
    if I were to guess, he's probably doing the same thing as so many other pseudomathematicians do with such things, when trying to contradict well-established corroborated mathematical proofs: Simply *redefine*
    the original problem so that it (possibly) fits his "proof".

    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Wed Mar 3 09:11:14 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 08:50:22 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    David Brown <david.brown@hesbynett.no> wrote:
    I think Pete Olcott already said that he was not a mathematician. So
    that means he is not constrained by such simple mathematical logic, and
    can solve the impossible in an way that mathematicians cannot.

    You know, in the same way that non-physicists are not constrained by
    physical laws that they don't understand, and can thus make moon rockets
    in their garage powered by gravity-repulsive paint.

    I haven't followed what he has written and said about his approach, but
    if I were to guess, he's probably doing the same thing as so many other >pseudomathematicians do with such things, when trying to contradict >well-established corroborated mathematical proofs: Simply *redefine*
    the original problem so that it (possibly) fits his "proof".

    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Wed Mar 3 10:23:06 2021
    From Newsgroup: comp.lang.c++

    On 03/03/2021 09:50, Juha Nieminen wrote:
    David Brown <david.brown@hesbynett.no> wrote:
    I think Pete Olcott already said that he was not a mathematician. So
    that means he is not constrained by such simple mathematical logic, and
    can solve the impossible in an way that mathematicians cannot.

    You know, in the same way that non-physicists are not constrained by
    physical laws that they don't understand, and can thus make moon rockets
    in their garage powered by gravity-repulsive paint.

    I haven't followed what he has written and said about his approach, but
    if I were to guess, he's probably doing the same thing as so many other pseudomathematicians do with such things, when trying to contradict well-established corroborated mathematical proofs: Simply *redefine*
    the original problem so that it (possibly) fits his "proof".

    I don't think anyone, including Olcott himself, really understands what
    he is trying to do - though I haven't bothered following the details
    either. He seems to propose some kind of simulator (for x86 assembly, bizarrely, rather than the usual Turing machine or similar) with all
    programs reduced to a "u32" type. Programs are split into a "decidable"
    bit and an "undecidable" bit, and he avoids the usual never-ending
    execution of the halting decider by only simulating the "decidable" bit.


    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)


    The difference is that you can often learn quite a bit of maths, and
    quite a bit about what works and doesn't work, by trying to solve that
    kind of problem. And for those that really think they have got the
    answer, they can learn about peer review and academic criticism. (There
    are some people, of course, who never listen and never learn - Olcott
    seems to be one of them.)

    Perhaps Olcott could try a political solution, as Edward Goodwin did -
    when the laws of mathematics stopped him from squaring the circle, he
    tried to get the "Indiana Pi Bill" passed to trump the mathematical laws.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 09:39:03 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well
    be defined, and computed to an arbitrary accuracy, using a finite
    description.

    Irrationality in itself has nothing to do with the squaring the
    circle problem. The square root of 2 is irrational, but if the square
    root could be used to define the area of a circle then it could be
    "squared" as per the original problem description.

    (The reason why the circle cannot be squared (using the tools in
    the original problem) is because pi is not an algebraic number.)
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Paavo Helde@myfirstname@osa.pri.ee to comp.lang.c++ on Wed Mar 3 11:53:57 2021
    From Newsgroup: comp.lang.c++

    03.03.2021 11:11 mickspud@potatofield.co.uk kirjutas:

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    You are confusing "definable" with "exactly representable in my favorite notation".

    The value of pi can be defined with no problems, and it can be also represented exactly. The most common exact representation makes use of a
    Greek letter.


    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Wed Mar 3 09:56:12 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life >>>example.)

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well
    be defined, and computed to an arbitrary accuracy, using a finite >description.

    You really are an aspie arn't you. You can't even spot a light heated remark when its signposted with a smiley.

    But if you want to be pedantic irrational numbers cannot be represented by
    the ratio of 2 integers therefor their true value is unknown and always will be.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Wed Mar 3 10:12:41 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 11:53:57 +0200
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    03.03.2021 11:11 mickspud@potatofield.co.uk kirjutas:

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    You are confusing "definable" with "exactly representable in my favorite >notation".

    It would appear you are confusing definable with representable. Infinity
    can be represented, that doesn't mean it can be defined especially given
    there are numerous different types.

    The value of pi can be defined with no problems, and it can be also >represented exactly. The most common exact representation makes use of a >Greek letter.

    I don't think you understand the meaning of an irrational number.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to comp.lang.c++ on Wed Mar 3 02:24:42 2021
    From Newsgroup: comp.lang.c++

    On 3/3/2021 2:12 AM, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 11:53:57 +0200
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    03.03.2021 11:11 mickspud@potatofield.co.uk kirjutas:

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    You are confusing "definable" with "exactly representable in my favorite
    notation".

    It would appear you are confusing definable with representable. Infinity
    can be represented, that doesn't mean it can be defined especially given there are numerous different types.

    The value of pi can be defined with no problems, and it can be also
    represented exactly. The most common exact representation makes use of a
    Greek letter.

    I don't think you understand the meaning of an irrational number.


    pi is pi, however, when I need to actually use it, I define a certain precision. Say, I need at least 301 digits of pi to accurately work with
    a certain fractal formula in a very deep zoom that uses an arbitrary
    floating number package. Anything less than 301 digits of precision will
    tend to start to creating "artifacts" that with ruin the rendering.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Wed Mar 3 11:48:12 2021
    From Newsgroup: comp.lang.c++

    On 03/03/2021 10:56, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well
    be defined, and computed to an arbitrary accuracy, using a finite
    description.

    You really are an aspie arn't you. You can't even spot a light heated remark when its signposted with a smiley.

    A smiley works to indicate a joke like this when it is clear that the
    poster knows that what they are writing is obviously and completely wrong.


    But if you want to be pedantic irrational numbers cannot be represented by the ratio of 2 integers therefor their true value is unknown and always will be.


    However, when you write this is is clear that you are not very familiar
    with the mathematics at this level. (Nothing wrong with that, of course
    - few people know or care what in means to be "computable".) The true
    value of π is known - it is π. It can't be written as a finite decimal expansion, but that has nothing to do with its "true value" - it's just
    a representation. (As an interesting aside, if you write π using a hexadecimal expansion, you can calculate any given digit without having
    to calculate the preceding digits. Weird and fascinating, IMHO.)

    And "pedantic" is a compliment to a mathematician!
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Wed Mar 3 12:07:30 2021
    From Newsgroup: comp.lang.c++

    On 03/03/2021 11:12, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 11:53:57 +0200
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    03.03.2021 11:11 mickspud@potatofield.co.uk kirjutas:

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    You are confusing "definable" with "exactly representable in my favorite
    notation".

    It would appear you are confusing definable with representable.

    No, he is not.

    Infinity
    can be represented, that doesn't mean it can be defined especially given there are numerous different types.

    You can define the infinities you want, by specifying characteristics of interest. Infinities are not computable numbers, but they are well-defined.


    The value of pi can be defined with no problems, and it can be also
    represented exactly. The most common exact representation makes use of a
    Greek letter.

    I don't think you understand the meaning of an irrational number.


    Why are you so concerned with irrational numbers here? I am confident
    that the others in this branch of the thread know exactly what the term
    means.

    The irrationality of pi is not relevant as to why its square root is not constructable with ruler-and-compass geometry. √2 is irrational, constructable, algebraic, and computable. π is irrational,
    non-constructable, non-algebraic (transcendental) and computable - as is √π.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 11:16:47 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of >>>>squaring the circle becomes correct. (This is an actual real-life >>>>example.)

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well
    be defined, and computed to an arbitrary accuracy, using a finite >>description.

    You really are an aspie arn't you. You can't even spot a light heated remark when its signposted with a smiley.

    There is no joke in your statement. It's an assertion with no punchline
    or anything. And it's an incorrect assertion.

    But if you want to be pedantic irrational numbers cannot be represented by the ratio of 2 integers therefor their true value is unknown and always will be.

    You said "definable value", which is rather different from "it has a non-recurring decimal expansion".

    Pi is a computable number, and therefore it's perfectly well definable.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Wed Mar 3 11:27:04 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 11:48:12 +0100
    David Brown <david.brown@hesbynett.no> wrote:
    On 03/03/2021 10:56, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well
    be defined, and computed to an arbitrary accuracy, using a finite
    description.

    You really are an aspie arn't you. You can't even spot a light heated remark >> when its signposted with a smiley.

    A smiley works to indicate a joke like this when it is clear that the
    poster knows that what they are writing is obviously and completely wrong.

    Ok, define the value of Pi then. And I don't mean just C/D.

    But if you want to be pedantic irrational numbers cannot be represented by >> the ratio of 2 integers therefor their true value is unknown and always will >> be.


    However, when you write this is is clear that you are not very familiar
    with the mathematics at this level. (Nothing wrong with that, of course

    So you are, good, then see above. Off you go...

    - few people know or care what in means to be "computable".) The true
    value of π is known - it is π. It can't be written as a finite decimal

    It can't be written as a finite expansion in any number base and a symbol
    is not a value - its a symbol.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Wed Mar 3 11:29:09 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 11:16:47 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of >>>>>squaring the circle becomes correct. (This is an actual real-life >>>>>example.)

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well
    be defined, and computed to an arbitrary accuracy, using a finite >>>description.

    You really are an aspie arn't you. You can't even spot a light heated remark >> when its signposted with a smiley.

    There is no joke in your statement. It's an assertion with no punchline
    or anything. And it's an incorrect assertion.

    Thank you for proving my point so emphatically and also proving that you
    don't know what "light hearted" means. But then English is a 2nd or 3rd language for you so fair enough.

    Pi is a computable number, and therefore it's perfectly well definable.

    Define it then.


    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to comp.lang.c++ on Wed Mar 3 03:50:18 2021
    From Newsgroup: comp.lang.c++

    On 3/3/2021 3:27 AM, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 11:48:12 +0100
    David Brown <david.brown@hesbynett.no> wrote:
    On 03/03/2021 10:56, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)

    Strictly speaking pi is an irrational number so doesn't actually have >>>>> a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well >>>> be defined, and computed to an arbitrary accuracy, using a finite
    description.

    You really are an aspie arn't you. You can't even spot a light heated remark
    when its signposted with a smiley.

    A smiley works to indicate a joke like this when it is clear that the
    poster knows that what they are writing is obviously and completely wrong.

    Ok, define the value of Pi then. And I don't mean just C/D.
    [...]

    atan(1) * 4 ? pi is pi.

    Infinite precision... ;^)
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Wed Mar 3 13:32:37 2021
    From Newsgroup: comp.lang.c++

    On 03/03/2021 12:27, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 11:48:12 +0100
    David Brown <david.brown@hesbynett.no> wrote:
    On 03/03/2021 10:56, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    A bit like trying to redefine the value of pi so that a proof of
    squaring the circle becomes correct. (This is an actual real-life
    example.)

    Strictly speaking pi is an irrational number so doesn't actually have >>>>> a definable value in the first place :)

    Of course it does. Pi is a computable number, so it can perfectly well >>>> be defined, and computed to an arbitrary accuracy, using a finite
    description.

    You really are an aspie arn't you. You can't even spot a light heated remark
    when its signposted with a smiley.

    A smiley works to indicate a joke like this when it is clear that the
    poster knows that what they are writing is obviously and completely wrong.

    Ok, define the value of Pi then. And I don't mean just C/D.

    Defining pi as the ratio of circumference to diameter of any circle is a perfectly good definition. But you can have lots of other definitions,
    all of which are equivalent, including Chris' suggestion :

    π = 4.tan⁻¹(1)

    or, if you prefer, the limit of

    π = 4 - 4/3 + 4/5 - 4/7 + 4/9 - ...

    You can define it as the first positive solution "x" to

    e ^ ix = -1

    All of these uniquely specify a single number - that makes them definitions.



    But if you want to be pedantic irrational numbers cannot be represented by >>> the ratio of 2 integers therefor their true value is unknown and always will
    be.


    However, when you write this is is clear that you are not very familiar
    with the mathematics at this level. (Nothing wrong with that, of course

    So you are, good, then see above. Off you go...

    See above.

    So, what do /you/ mean when you say "true value", or that the "true
    value" of a number is known? Do you just mean that when written down in decimal, the representation is either finite or ends in an infinite
    repetition of a finite sequence? That's a useful classification - so
    useful, that we give it a name: "the rational numbers". (It is an
    equivalent way to define them.) But mathematics does not pretend that
    only such numbers have a "true value".


    - few people know or care what in means to be "computable".) The true
    value of π is known - it is π. It can't be written as a finite decimal

    It can't be written as a finite expansion in any number base and a symbol
    is not a value - its a symbol.


    I assume you are restricting your number bases to those you are familiar
    with - using a positive integer greater than 1 as the base. It is
    perfectly valid, though somewhat obscure, to use other types of number
    base. For example, π can be represented as 10 in base π.

    You are mixing up representations and values here. A representation is
    just how you write a value, and mathematicians use many different representations for different purposes. Sometimes a given value can be
    written finitely in a particular representation, sometimes not.

    A good example would be the right angle. This is a well-defined
    concept, with a well-defined value. Represented in degrees, it is 90°,
    which in turn has a finite decimal representation. Represented in
    radians, it is π/2, which does not have a finite decimal representation.
    But the radian representation in different symbols is clear and finite.
    Equally, 1 radian is easily and finitely represented in decimal, while
    the degrees representation of the same angle is 180/π, which does not
    have a finite representation in decimal.


    In a desperate and feeble attempt to get on-topic for the group, the
    value of a C++ object is not dependent on how you choose to display it
    using an ostream.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 12:37:43 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 11:53:57 +0200
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    03.03.2021 11:11 mickspud@potatofield.co.uk kirjutas:

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    You are confusing "definable" with "exactly representable in my favorite >>notation".

    It would appear you are confusing definable with representable. Infinity
    can be represented, that doesn't mean it can be defined especially given there are numerous different types.

    Maybe you should specify what you mean by "definable".

    The number pi can certainly be defined in a completely unambiguous way
    with a finite expression. Just because it may have an infinite non-recurring decimal expansion doesn't mean it can't be defined.

    https://en.wikipedia.org/wiki/Definable_real_number

    There exist real numbers that cannot be defined (with a finite expression),
    and in fact almost all real numbers are like that, but pi is not one
    of them.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 12:41:33 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk wrote:
    Thank you for proving my point so emphatically and also proving that you don't know what "light hearted" means. But then English is a 2nd or 3rd language for you so fair enough.

    And assholery seems to be your first language.

    Pi is a computable number, and therefore it's perfectly well definable.

    Define it then.

    It's the ratio between the circumference and the diameter of a circle.

    Maybe you don't understand what a "definable number" is.

    https://en.wikipedia.org/wiki/Definable_real_number
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Paavo Helde@myfirstname@osa.pri.ee to comp.lang.c++ on Wed Mar 3 14:46:13 2021
    From Newsgroup: comp.lang.c++

    03.03.2021 13:29 mickspud@potatofield.co.uk kirjutas:
    On Wed, 3 Mar 2021 11:16:47 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:

    Pi is a computable number, and therefore it's perfectly well definable.

    Define it then.

    See e.g. Weierstrass definition from 1841:

    [math]
    \pi = \int_{-\infty}^\infty {dx \over 1+x^2}
    [/math]

    https://en.wikipedia.org/wiki/Pi#cite_note-16

    (Remmert, Reinhold (2012). "Ch. 5 What is π?". In Heinz-Dieter
    Ebbinghaus; Hans Hermes; Friedrich Hirzebruch; Max Koecher; Klaus
    Mainzer; Jürgen Neukirch; Alexander Prestel; Reinhold Remmert (eds.). Numbers. Springer. ISBN 978-1-4612-1005-4.)
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Wed Mar 3 14:43:36 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Thank you for proving my point so emphatically and also proving that you
    don't know what "light hearted" means. But then English is a 2nd or 3rd
    language for you so fair enough.

    And assholery seems to be your first language.

    Its spelt arsehole in England - the clue is in the name of the language. If I wanted to learn proper Finnish I wouldn't go to Sweden.

    Pi is a computable number, and therefore it's perfectly well definable.

    Define it then.

    It's the ratio between the circumference and the diameter of a circle.

    Maybe you don't understand what a "definable number" is.

    https://en.wikipedia.org/wiki/Definable_real_number

    I guess its a case of defining define.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 17:05:55 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Thank you for proving my point so emphatically and also proving that you >>> don't know what "light hearted" means. But then English is a 2nd or 3rd >>> language for you so fair enough.

    And assholery seems to be your first language.

    Its spelt arsehole in England - the clue is in the name of the language. If I wanted to learn proper Finnish I wouldn't go to Sweden.

    And then you call me an "aspie".

    Pi is a computable number, and therefore it's perfectly well definable.

    Define it then.

    It's the ratio between the circumference and the diameter of a circle.

    Maybe you don't understand what a "definable number" is.

    https://en.wikipedia.org/wiki/Definable_real_number

    I guess its a case of defining define.

    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Wed Mar 3 17:11:29 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 17:05:55 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Thank you for proving my point so emphatically and also proving that you >>>> don't know what "light hearted" means. But then English is a 2nd or 3rd >>>> language for you so fair enough.

    And assholery seems to be your first language.

    Its spelt arsehole in England - the clue is in the name of the language. If I

    wanted to learn proper Finnish I wouldn't go to Sweden.

    And then you call me an "aspie".

    Just being helpful :)

    I guess its a case of defining define.

    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.lang.c++,comp.theory,comp.lang.c,comp.software-eng on Wed Mar 3 12:52:46 2021
    From Newsgroup: comp.lang.c++

    On 3/3/2021 1:58 AM, David Brown wrote:
    On 03/03/2021 08:23, Juha Nieminen wrote:
    In comp.lang.c++ Otto J. Makela <om@iki.fi> wrote:
    I'm a bit late to the discussion, but this sounds a lot like you're
    trying to overturn Turing's proof that that a general algorithm to solve >>> the halting problem for all possible program-input pairs cannot exist.

    If the halting problem could be solved, it would be great news for
    mathematics. Pretty much all unsolved problems in mathematics, at least
    those that can be computed with an algorithm, would be solved in one
    fell swoop.

    The Riemann hypothesis? Simply create a program that checks every
    single non-trivial zero of the zeta function and stops when it finds
    one that's not on the critical line. Then simply use the marvelous
    halting problem solution above to see if it ever terminates, and
    you'll have proven the Riemann hypothesis as true or false.

    Do odd perfect numbers exist? Simply create a program that goes
    through every odd number and checks if it's perfect, and terminates
    when it finds one. Use the halting problem proof to check if it will
    ever terminate and you'll have solved the problem.

    Collatz conjecture? Same thing. And so on and so forth.


    I think Pete Olcott already said that he was not a mathematician. So
    that means he is not constrained by such simple mathematical logic, and
    can solve the impossible in an way that mathematicians cannot.

    You know, in the same way that non-physicists are not constrained by
    physical laws that they don't understand, and can thus make moon rockets
    in their garage powered by gravity-repulsive paint.


    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    return;
    }

    All of the halting problem proofs are based on the fact that it is
    impossible for Halts() to return a correct halting decision to H_Hat()
    because H_Hat() contradicts whatever value that Halts() returns.

    All of these same proofs ignore the fact that every halt decider that
    bases its halt decision on examining the execution trace of its own
    simulation of its input never reaches the point in the execution trace
    where it would return a value to H_Hat().

    On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
    A computation that would not halt if its simulation were not
    halted is indeed a non-halting computation.

    That I have shown how a halt decider could examine such an execution
    trace to determine that its input would not halt unless the simulation
    of this input was terminated proves that these computations are halt decidable.
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.lang.c++,comp.lang.c,comp.theory,comp.software-eng on Wed Mar 3 12:55:34 2021
    From Newsgroup: comp.lang.c++

    On 3/3/2021 6:37 AM, Juha Nieminen wrote:
    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 11:53:57 +0200
    Paavo Helde <myfirstname@osa.pri.ee> wrote:
    03.03.2021 11:11 mickspud@potatofield.co.uk kirjutas:

    Strictly speaking pi is an irrational number so doesn't actually have
    a definable value in the first place :)

    You are confusing "definable" with "exactly representable in my favorite >>> notation".

    It would appear you are confusing definable with representable. Infinity
    can be represented, that doesn't mean it can be defined especially given
    there are numerous different types.

    Maybe you should specify what you mean by "definable".

    The number pi can certainly be defined in a completely unambiguous way
    with a finite expression. Just because it may have an infinite non-recurring decimal expansion doesn't mean it can't be defined.

    https://en.wikipedia.org/wiki/Definable_real_number

    There exist real numbers that cannot be defined (with a finite expression), and in fact almost all real numbers are like that, but pi is not one
    of them.




    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    return;
    }

    All of the halting problem proofs are based on the fact that it is
    impossible for Halts() to return a correct halting decision to H_Hat()
    because H_Hat() contradicts whatever value that Halts() returns.

    All of these same proofs ignore the fact that every halt decider that
    bases its halt decision on examining the execution trace of its own
    simulation of its input never reaches the point in the execution trace
    where it would return a value to H_Hat().

    On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
    A computation that would not halt if its simulation were not
    halted is indeed a non-halting computation.

    That I have shown how a halt decider could examine such an execution
    trace to determine that its input would not halt unless the simulation
    of this input was terminated proves that these computations are halt decidable.
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Wed Mar 3 21:00:41 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    I think you are making stuff up as you go.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Keith Thompson@Keith.S.Thompson+u@gmail.com to comp.lang.c++ on Wed Mar 3 14:18:44 2021
    From Newsgroup: comp.lang.c++

    Juha Nieminen <nospam@thanks.invalid> writes:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    I think you are making stuff up as you go.

    I think he's making stuff up that has even less to do with C++ than the original topic of this thread. I suggest not replying.
    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips Healthcare
    void Void(void) { Void(); } /* The recursive call of the void */
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.lang.c++,comp.lang.c,comp.theory,comp.software-eng on Wed Mar 3 17:06:01 2021
    From Newsgroup: comp.lang.c++

    On 3/3/2021 4:18 PM, Keith Thompson wrote:
    Juha Nieminen <nospam@thanks.invalid> writes:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    I think you are making stuff up as you go.

    I think he's making stuff up that has even less to do with C++ than the original topic of this thread. I suggest not replying.


    Here is the original topic of this thread completely rewritten.

    Criteria for deciding that H_Hat() calls Simulate() in infinite
    recursion. I need to have this criteria validated.

    (1) The execution trace of H_Hat() shows that it calls Simulate() from
    the same machine address two times in sequence with the same data.

    (2) It is assumed that Simulate() either directly invokes its input (as
    shown below) or Simulate() emulates the execution of the x86 machine
    language of its input (functionally equivalent to the direct execution
    shown below).

    Does everyone agree that the above criteria is sufficient to definitely
    decide that H_Hat() is infinitely recursive?


    #include <stdint.h>
    #define u32 uint32_t


    int Simulate(u32 P, u32 I)
    {
    ((void(*)(u32))P)(I);
    }


    void H_Hat(u32 P)
    {
    Simulate(P, P);
    }


    int main()
    {
    Simulate((u32)H_Hat, (u32)H_Hat);
    }


    _Simulate()
    [00000478](01) 55 push ebp
    [00000479](02) 8bec mov ebp,esp
    [0000047b](03) 8b450c mov eax,[ebp+0c]
    [0000047e](01) 50 push eax
    [0000047f](03) ff5508 call dword [ebp+08]
    [00000482](03) 83c404 add esp,+04
    [00000485](01) 5d pop ebp
    [00000486](01) c3 ret

    _H_Hat()
    [00000868](01) 55 push ebp
    [00000869](02) 8bec mov ebp,esp
    [0000086b](03) 8b4508 mov eax,[ebp+08]
    [0000086e](01) 50 push eax
    [0000086f](03) 8b4d08 mov ecx,[ebp+08]
    [00000872](01) 51 push ecx
    [00000873](05) e800fcffff call 00000478
    [00000878](03) 83c408 add esp,+08
    [0000087b](01) 5d pop ebp
    [0000087c](01) c3 ret

    _main()
    [00000888](01) 55 push ebp
    [00000889](02) 8bec mov ebp,esp
    [0000088b](05) 6868080000 push 00000868
    [00000890](05) 6868080000 push 00000868
    [00000895](05) e8defbffff call 00000478
    [0000089a](03) 83c408 add esp,+08
    [0000089d](02) 33c0 xor eax,eax
    [0000089f](01) 5d pop ebp
    [000008a0](01) c3 ret


    Columns
    (1) Sequence number
    (2) Machine address of instruction
    (3) Machine address of top of stack
    (4) Value of top of stack after instruction executed
    (5) Number of bytes of machine code
    (6) Machine language bytes
    (7) Assembly language text

    (01)[00000888][00011194][00000000](01) 55 push ebp (02)[00000889][00011194][00000000](02) 8bec mov ebp,esp (03)[0000088b][00011190][00000868](05) 6868080000 push 00000868 (04)[00000890][0001118c][00000868](05) 6868080000 push 00000868 (05)[00000895][00011188][0000089a](05) e8defbffff call 00000478 (06)[00000868][00011178][00011184](01) 55 push ebp (07)[00000869][00011178][00011184](02) 8bec mov ebp,esp (08)[0000086b][00011178][00011184](03) 8b4508 mov eax,[ebp+08] (09)[0000086e][00011174][00000868](01) 50 push eax (10)[0000086f][00011174][00000868](03) 8b4d08 mov ecx,[ebp+08] (11)[00000872][00011170][00000868](01) 51 push ecx (12)[00000873][0001116c][00000878](05) e800fcffff call 00000478

    Line (09) pushes second parameter to Simulate() machine address 0x878
    Line (11) pushes first parameter to Simulate() machine address 0x878
    Line (12) Calls Simulate(0x878, 0x878);

    (13)[00000868][0001115c][00011168](01) 55 push ebp (14)[00000869][0001115c][00011168](02) 8bec mov ebp,esp (15)[0000086b][0001115c][00011168](03) 8b4508 mov eax,[ebp+08] (16)[0000086e][00011158][00000868](01) 50 push eax (17)[0000086f][00011158][00000868](03) 8b4d08 mov ecx,[ebp+08] (18)[00000872][00011154][00000868](01) 51 push ecx (19)[00000873][00011150][00000878](05) e800fcffff call 00000478

    Line (16) pushes second parameter to Simulate() machine address 0x878
    Line (18) pushes first parameter to Simulate() machine address 0x878
    Line (19) Calls Simulate(0x878, 0x878);

    (20)[00000868][00011140][0001114c](01) 55 push ebp (21)[00000869][00011140][0001114c](02) 8bec mov ebp,esp (22)[0000086b][00011140][0001114c](03) 8b4508 mov eax,[ebp+08] (23)[0000086e][0001113c][00000868](01) 50 push eax (24)[0000086f][0001113c][00000868](03) 8b4d08 mov ecx,[ebp+08] (25)[00000872][00011138][00000868](01) 51 push ecx (26)[00000873][00011134][00000878](05) e800fcffff call 00000478

    Line (23) pushes second parameter to Simulate() machine address 0x878
    Line (25) pushes first parameter to Simulate() machine address 0x878
    Line (26) Calls Simulate(0x878, 0x878);

    Now we have seen that Simulate() is invoked two times from the same
    machine address of H_Hat() with the same data. We also know that
    Simulate() either executes or emulates the machine language of its input
    and nothing more. This seems to provide a sufficient basis for deciding
    that H_Hat() is infinitely recursive, thus non-halting.
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Thu Mar 4 09:23:32 2021
    From Newsgroup: comp.lang.c++

    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    I think you are making stuff up as you go.

    As I've said before, English is not your first language so I won't blame you for not following everything.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Thu Mar 4 09:23:56 2021
    From Newsgroup: comp.lang.c++

    On Wed, 03 Mar 2021 14:18:44 -0800
    Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Juha Nieminen <nospam@thanks.invalid> writes:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    I think you are making stuff up as you go.

    I think he's making stuff up that has even less to do with C++ than the >original topic of this thread. I suggest not replying.

    You do realise this is usenet? Topics drift.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Thu Mar 4 11:42:12 2021
    From Newsgroup: comp.lang.c++

    On 04/03/2021 10:23, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    That is not what it would mean to a mathematician. It's good enough,
    perhaps, for a lot school maths. At a higher level, the term "number"
    can be dependent on the context. /You/ probably just mean "decimal
    digit", judging by your comment here. But to anyone interested in
    mathematics beyond school level, "number" will usually mean "real
    number" unless context dictates something else (integer, complex number, transfinite number, length of a line, etc.).

    You can't have a sensible conversation about mathematics (or indeed any
    topic) if you insist on using your own limited definitions that are
    different from other people's. You just make yourself look silly,
    arguing about "defined values" when all you are trying to say is basic
    facts about rational numbers that are well known to everyone else in the thread.

    Here's a clue for you - when everyone else in the discussion agrees with
    each other, and disagrees with you, then either you have got your terms
    wrong, or you are out of your depth. Many of us are happy to give you
    pointers on what you are getting wrong here, but you have to cooperate
    and understand that you /are/ wrong, rather than responding with insults
    and totally misplaced patronisation.


    I think you are making stuff up as you go.

    As I've said before, English is not your first language so I won't blame you for not following everything.


    Juha's written English is more accurate than yours. I believe I could
    point out a dozen (minor) errors in the spelling and grammar of your
    posts in this thread - I'm not sure I could find any in Juha's posts.
    It would certainly be petty of me to do so, but hopefully you can see
    the inappropriateness of railing on Juha's language skills.


    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickspud@mickspud@potatofield.co.uk to comp.lang.c++ on Thu Mar 4 10:56:41 2021
    From Newsgroup: comp.lang.c++

    On Thu, 4 Mar 2021 11:42:12 +0100
    David Brown <david.brown@hesbynett.no> wrote:
    On 04/03/2021 10:23, mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    That is not what it would mean to a mathematician. It's good enough, >perhaps, for a lot school maths. At a higher level, the term "number"
    can be dependent on the context. /You/ probably just mean "decimal
    digit", judging by your comment here. But to anyone interested in >mathematics beyond school level, "number" will usually mean "real
    number" unless context dictates something else (integer, complex number, >transfinite number, length of a line, etc.).

    Oh ok, thanks for the heads up there Euclid.

    As I've said before, English is not your first language so I won't blame you >> for not following everything.


    Juha's written English is more accurate than yours. I believe I could
    point out a dozen (minor) errors in the spelling and grammar of your

    No doubt you could, I don't bother to use a spell checker given its usenet.

    posts in this thread - I'm not sure I could find any in Juha's posts.
    It would certainly be petty of me to do so, but hopefully you can see
    the inappropriateness of railing on Juha's language skills.

    No, not really. Spelling is irrelevant, comprehension is far more important.
    I can speak passable French but I write it like a Martian. Far more useful
    than the other way around.

    No kindly shove your patronising attitude up your arse and fuck off.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Thu Mar 4 12:21:33 2021
    From Newsgroup: comp.lang.c++

    On 04/03/2021 11:56, mickspud@potatofield.co.uk wrote:

    <snip the irrelevant bits>

    If you value comprehension of what people write, then try re-reading the
    thread and comprehending what others have said. Once you have
    understood where you went wrong, you'll perhaps have learned something.

    In the meantime, perhaps we could get back to C++.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Bonita Montero@Bonita.Montero@gmail.com to comp.lang.c,comp.lang.c++ on Thu Mar 4 13:09:53 2021
    From Newsgroup: comp.lang.c++

    Can you pleas stop posting things not related to C/C++-language
    issues to comp.lang.c++/c ?
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Juha Nieminen@nospam@thanks.invalid to comp.lang.c++ on Thu Mar 4 13:56:37 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    You can't write the entire decimal expansion of 1/3.

    Consider *why* you think that you can, and then consider how is that
    different from, for example, sqrt(2) or pi.

    (Hint: What you can do is give a description, a definition, an algorithm
    to write arbitrarily many of the digits of the decimal expansion of
    that number. The same is true for all three examples above.)

    sqrt(2) and pi are not any less "well-defined" as 1/3 is. The exact
    algorithm to print out arbitrarily many digits of their decimal expansion
    may be a bit more complicated, but that means nothing in this context.

    I think you are making stuff up as you go.

    As I've said before, English is not your first language so I won't blame you for not following everything.

    One has to wonder why you feel the need to be so arrogant and condescending.

    Ironically, I think I know English better than you. At least I know what a "definable number" is.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From MrMeep@MrMeep@edgeoftheuniverse.com to comp.lang.c++ on Thu Mar 4 15:34:45 2021
    From Newsgroup: comp.lang.c++

    On Thu, 4 Mar 2021 13:56:37 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    You can't write the entire decimal expansion of 1/3.

    At the risk of getting drawn into this - the expansion of 1/3 can easily be written in a number of bases since its rational number. An irrational number cannot be written down in ANY real base.

    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.lang.c++ on Thu Mar 4 09:46:03 2021
    From Newsgroup: comp.lang.c++

    On 3/4/2021 9:34 AM, MrMeep@edgeoftheuniverse.com wrote:
    On Thu, 4 Mar 2021 13:56:37 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    You can't write the entire decimal expansion of 1/3.

    At the risk of getting drawn into this - the expansion of 1/3 can easily be written in a number of bases since its rational number. An irrational number cannot be written down in ANY real base.


    Thus algorithmic compression seems apt.
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From David Brown@david.brown@hesbynett.no to comp.lang.c++ on Thu Mar 4 17:19:19 2021
    From Newsgroup: comp.lang.c++

    On 04/03/2021 16:34, MrMeep@edgeoftheuniverse.com wrote:
    On Thu, 4 Mar 2021 13:56:37 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    You can't write the entire decimal expansion of 1/3.

    At the risk of getting drawn into this - the expansion of 1/3 can easily be written in a number of bases since its rational number. An irrational number cannot be written down in ANY real base.


    You can write any number x as 10 in base x. That applies to any /real/
    number - there is nothing (except perhaps a concern for your own sanity) stopping you using base π positional number systems. (Indeed, you don't
    have to restrict yourself to real numbers.) Representations are all
    just invented for convenience - you can invent any new own you like in
    order to write down what you want. Simple integer base positional
    numeral systems are merely the ones with which we are most familiar.

    <https://en.wikipedia.org/wiki/Non-integer_base_of_numeration#Base_%CF%80>


    You could define an "irrational number" as being a real number which
    cannot be written using a finite sequence of digits in any integer base representation. That would be a perfectly good definition - equivalent
    to more common definitions.

    But it bears no relationship to whether a number is "defined" or has a
    "value". Mick's argument that π does not have a "defined value" because
    you can't write it in a finite decimal expansion bears no more validity
    than saying "a tenth" does not have a "defined value" because you can't
    write it in Roman numerals.



    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to comp.lang.c++ on Thu Mar 4 10:00:33 2021
    From Newsgroup: comp.lang.c++

    On 3/4/2021 5:56 AM, Juha Nieminen wrote:
    mickspud@potatofield.co.uk wrote:
    On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    mickspud@potatofield.co.uk wrote:
    Let me ask it this way: Why do you consider a fraction, like 1/3,
    to be a definable number?

    It has a quantifiable value.

    What does that even mean?

    It means it has a value that can be written down using actual numbers.

    You can't write the entire decimal expansion of 1/3.

    0.333...

    ;^)



    Consider *why* you think that you can, and then consider how is that different from, for example, sqrt(2) or pi.

    (Hint: What you can do is give a description, a definition, an algorithm
    to write arbitrarily many of the digits of the decimal expansion of
    that number. The same is true for all three examples above.)

    sqrt(2) and pi are not any less "well-defined" as 1/3 is. The exact
    algorithm to print out arbitrarily many digits of their decimal expansion
    may be a bit more complicated, but that means nothing in this context.

    I think you are making stuff up as you go.

    As I've said before, English is not your first language so I won't blame you >> for not following everything.

    One has to wonder why you feel the need to be so arrogant and condescending.

    Ironically, I think I know English better than you. At least I know what a "definable number" is.


    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Keith Thompson@Keith.S.Thompson+u@gmail.com to comp.lang.c++ on Thu Mar 4 12:20:19 2021
    From Newsgroup: comp.lang.c++

    mickspud@potatofield.co.uk writes:
    [...]
    No kindly shove your patronising attitude up your arse and fuck off.
    [...]

    Welcome to my killfile. I encourage others to do likewise.
    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips Healthcare
    void Void(void) { Void(); } /* The recursive call of the void */
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From mickcarrot@mickcarrot@vegetables.com to comp.lang.c++ on Fri Mar 5 10:10:59 2021
    From Newsgroup: comp.lang.c++

    On Thu, 04 Mar 2021 12:20:19 -0800
    Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >mickspud@potatofield.co.uk writes:
    [...]
    No kindly shove your patronising attitude up your arse and fuck off.
    [...]

    Welcome to my killfile. I encourage others to do likewise.

    I hate to break the news to you, but killfiles stopped being any use sometime around the early 90s.


    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From Bonita Montero@Bonita.Montero@gmail.com to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Sun Mar 7 16:38:11 2021
    From Newsgroup: comp.lang.c++

    Detecting and handling infinite recursion is easy:

    __try
    {
    ...
    }
    __except( GetExceptionCode() == EXCEPTION_STACK_OVERFLOW ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH )
    {
    ...
    }

    Hrhr.
    --- Synchronet 3.18c-Linux NewsLink 1.113
  • From olcott@NoOne@NoWhere.com to comp.theory,comp.software-eng,comp.lang.c,comp.lang.c++ on Sun Mar 7 09:55:11 2021
    From Newsgroup: comp.lang.c++

    On 3/7/2021 9:38 AM, Bonita Montero wrote:
    Detecting and handling infinite recursion is easy:

        __try
        {
            ...
        }
        __except( GetExceptionCode() == EXCEPTION_STACK_OVERFLOW ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH )
        {
            ...
        }

    Hrhr.

    I am creating a halt decider that correctly decides the conventional
    halting problem counter examples on the basis of examining the x86
    machine language execution trace of the H_Hat() invocations of Halts().

    The halt decider decides that they are infinitely recursive, aborts its simulation of H_Hat() and decides not halting.

    Halts() has as its foundation a complete fully functional x86 emulator
    that has "been on the market" for 25 years.

    void H_Hat(u32 P)
    {
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
    HERE: goto HERE;
    }

    int main()
    {
    u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
    Output("Input_Would_Halt = ", Input_Would_Halt);
    }


    http://www.liarparadox.org/Eliminating_pathological_self_reference_error_from_the_halting_problem.pdf
    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre minds." Einstein
    --- Synchronet 3.18c-Linux NewsLink 1.113