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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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