hi all, especially olcott!
first off, why is usenet so annoying to access? jeez... sorry if
i mess up any conventions. and no edits if i make a typo! such 20th century technology 😮💨
second, olcott could you please tell me the gist of your ideas?
i stumbled onto your name about 10 years ago when i first started contemplating the halting problem. i wrote it down in a document noting that you've been cranking on this since at least 2004! i promptly forgot about
it until a few days ago going thru my archives, and i'm pleasantly surprised to see you're still active working on this, albeit here in some obscure part of computing history...
third, has anyone here (especially olcott) actually read turing's original arguments on the matter? the decision paradox described by turing, involving whether some input machine is "satisfactory" or not, is slightly different than your basic halting paradox, and comes with an additional constraint
that any resolution to said paradox must abide by. namely: if the resolution to
the paradox allows for expressing the computation of the antidiagonal (β) across the sequence of computable numbers .../then ya done goofed!/
if you haven't, i /highly/ recommend carefully reading thru the first two pages
of §8 from /on computable numbers/. they were the /first/ words turing wrote about computing, after defining the underlying model of computing as theory, where he lays down the foundation for undecidability within computing:
https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf#page=17
or you can read my thesis on the matter:
https://www.academia.edu/143540657
hi all, especially olcott!
first off, why is usenet so annoying to access? jeez... sorry if
i mess up any conventions. and no edits if i make a typo! such 20th century technology 😮💨
second, olcott could you please tell me the gist of your ideas?
i stumbled onto your name about 10 years ago when i first started contemplating the halting problem. i wrote it down in a document noting that you've been cranking on this since at least 2004! i promptly forgot about
it until a few days ago going thru my archives, and i'm pleasantly surprised to see you're still active working on this, albeit here in some obscure part of computing history...
third, has anyone here (especially olcott) actually read turing's original arguments on the matter? the decision paradox described by turing, involving whether some input machine is "satisfactory" or not, is slightly different than your basic halting paradox, and comes with an additional constraint
that any resolution to said paradox must abide by. namely: if the resolution to
the paradox allows for expressing the computation of the antidiagonal (β) across the sequence of computable numbers .../then ya done goofed!/
if you haven't, i /highly/ recommend carefully reading thru the first two pages
of §8 from /on computable numbers/. they were the /first/ words turing wrote about computing, after defining the underlying model of computing as theory, where he lays down the foundation for undecidability within computing:
https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf#page=17
or you can read my thesis on the matter:
https://www.academia.edu/143540657
On 9/17/2025 2:18 PM, dart200 wrote:
Here is the essence of my work and its validation by Claude AI https://philpapers.org/archive/OLCHPS.pdf Four other LLM models also
hi all, especially olcott!
first off, why is usenet so annoying to access? jeez... sorry if i mess
up any conventions. and no edits if i make a typo! such 20th century
technology 😮💨
second, olcott could you please tell me the gist of your ideas?
i stumbled onto your name about 10 years ago when i first started
contemplating the halting problem. i wrote it down in a document noting
that you've been cranking on this since at least 2004! i promptly
forgot about it until a few days ago going thru my archives, and i'm
pleasantly surprised to see you're still active working on this, albeit
here in some obscure part of computing history...
third, has anyone here (especially olcott) actually read turing's
original arguments on the matter? the decision paradox described by
turing, involving whether some input machine is "satisfactory" or not,
is slightly different than your basic halting paradox, and comes with
an additional constraint that any resolution to said paradox must abide
by. namely: if the resolution to the paradox allows for expressing the
computation of the antidiagonal (β) across the sequence of computable
numbers .../then ya done goofed!/
if you haven't, i /highly/ recommend carefully reading thru the first
two pages of §8 from /on computable numbers/. they were the /first/
words turing wrote about computing, after defining the underlying model
of computing as theory, where he lays down the foundation for
undecidability within computing:
https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf#page=17
or you can read my thesis on the matter:
https://www.academia.edu/143540657
agree.
This is the summation of 22 years worth of work since 2004. 25% of all
of the postings on comp.theory since 2004 are mine.
I bypass the whole diagonal argument and delve directly into the
semantics of the algorithm specifications.
Here is the essence of my work and its validation by Claude AI https://philpapers.org/archive/OLCHPS.pdf
Four other LLM models also agree.
This is the summation of 22 years worth of work since 2004.
25% of all of the postings on comp.theory since 2004 are mine.
I bypass the whole diagonal argument and delve directly
into the semantics of the algorithm specifications.
let αn be the n-th computable sequence, and let φn(m) be the m-th figure in αn.
Let β be the sequence with 1-φn(m) as its n-th. figure. Since β is computable,
there exists a number K [== β computation] such that 1-φn(n) = φK(n) for all n.
Putting n = K, we have 1 = 2φK(K), i.e. 1 is even. This is impossible.
olcott <[email protected]> posted:
Here is the essence of my work and its validation by Claude AI
https://philpapers.org/archive/OLCHPS.pdf
Four other LLM models also agree.
llms can be made to agree 1=2 given enough prompting, unfortunately. we really should
be evaluating llms not based on what they can prove, but on what they can't be
prompted to prove. that would show truly critical reasoning. the bubble popping for
2020s AI will be quite spectacular.
also, that result fundamentally contradicts itself. the analyser simulated its own
behavior as a matter of infinite recursion ... but then uses that to return
a result???
and if that is the result then shouldn't HHH(DD) -> 0, so Halt_Status = 0, and the
if statement triggering the goto HERE loop does not run, causing DD() to halt ...
meaning HHH(DD) should have been 1. the result is just completely nonsensical.
oh dear olcott. but look i have a resolution to this paradox and u definitely are the
right track to a degree, i do hope you'll hear me out fully.
(is there a guide somewhere for usenet markup conventions? like for fixed-width)
This is the summation of 22 years worth of work since 2004.
25% of all of the postings on comp.theory since 2004 are mine.
unfortunately time spent =/= correctness. while i'm sure there is plenty of value
in the work you did do, even beyond priming you for this engagement, i'm also sure
that ur missing something about the original argument for exactly why turing established undecidability in computing in the first place. i'm just hoping your
time spent indicates a willingness to continue engagement, and that if i do swing
you over, others will 👀👀👀
I bypass the whole diagonal argument and delve directly
into the semantics of the algorithm specifications.
the diagonal that turing is discussing not "by-passable". he's talking about an
/actual diagonal/ computed across the sequence of computable numbers: for every r-th
machine that can "satisfactorily" compute a number, the diagonal computation will
find it's r-th digit and this becomes the r-th digit on the diagonal.
the problem turing is worried about is that if such a diagonal is computable, it
can be used to "diagonalize" the computable numbers like cantor did with the reals.
turing presumes that if one can compute a diagonal across the computable numbers,
then this computation could be used to create an anti-diagonal where each digit
is the opposite from the true diagonal ... meaning it would be a computable number that can't exist on the total list of computable numbers. contradiction!
turing even gives a succinct formal proof for this problem:
let αn be the n-th computable sequence, and let φn(m) be the m-th figure in αn.
Let β be the sequence with 1-φn(m) as its n-th. figure. Since β is computable,
there exists a number K [== β computation] such that 1-φn(n) = φK(n) for all n.
Putting n = K, we have 1 = 2φK(K), i.e. 1 is even. This is impossible.
the reason that turing goes on in the next page to show how computing the direct diagonal (β') results in an undecidable paradox is to provide a reason why
the computation of β can't be computed. he does so with a decision paradox that
isn't /exactly/ like the halting paradox, but very much quite similar.
if you resolution for decision paradoxes doesn't also show that β isn't, then it's not gunna work. i don't think you've yet had awareness of this problem,
let alone found a resolution to decision paradoxes that also avoids computing a β.
On 9/17/2025 6:02 PM, dart200 wrote:
The way that the diagonal *is* bypassed is my newest work that is not provided anywhere else besides here:
olcott <[email protected]> posted:
Here is the essence of my work and its validation by Claude AI
https://philpapers.org/archive/OLCHPS.pdf Four other LLM models also
agree.
llms can be made to agree 1=2 given enough prompting, unfortunately. we
really should be evaluating llms not based on what they can prove, but
on what they can't be prompted to prove. that would show truly critical
reasoning. the bubble popping for 2020s AI will be quite spectacular.
also, that result fundamentally contradicts itself. the analyser
simulated its own behavior as a matter of infinite recursion ... but
then uses that to return a result???
and if that is the result then shouldn't HHH(DD) -> 0, so Halt_Status =
0, and the if statement triggering the goto HERE loop does not run,
causing DD() to halt ... meaning HHH(DD) should have been 1. the result
is just completely nonsensical.
oh dear olcott. but look i have a resolution to this paradox and u
definitely are the right track to a degree, i do hope you'll hear me
out fully.
(is there a guide somewhere for usenet markup conventions? like for
fixed-width)
This is the summation of 22 years worth of work since 2004.
25% of all of the postings on comp.theory since 2004 are mine.
unfortunately time spent =/= correctness. while i'm sure there is
plenty of value in the work you did do, even beyond priming you for
this engagement, i'm also sure that ur missing something about the
original argument for exactly why turing established undecidability in
computing in the first place. i'm just hoping your time spent indicates
a willingness to continue engagement, and that if i do swing you over,
others will 👀👀👀
I bypass the whole diagonal argument and delve directly into the
semantics of the algorithm specifications.
the diagonal that turing is discussing not "by-passable". he's talking
about an /actual diagonal/ computed across the sequence of computable
numbers: for every r-th machine that can "satisfactorily" compute a
number, the diagonal computation will find it's r-th digit and this
becomes the r-th digit on the diagonal.
the problem turing is worried about is that if such a diagonal is
computable, it can be used to "diagonalize" the computable numbers like
cantor did with the reals. turing presumes that if one can compute a
diagonal across the computable numbers, then this computation could be
used to create an anti-diagonal where each digit is the opposite from
the true diagonal ... meaning it would be a computable number that
can't exist on the total list of computable numbers. contradiction!
turing even gives a succinct formal proof for this problem:
let αn be the n-th computable sequence, and let φn(m) be the m-th
figure in αn.
Let β be the sequence with 1-φn(m) as its n-th. figure. Since β is
computable, there exists a number K [== β computation] such that
1-φn(n) = φK(n) for all n.
Putting n = K, we have 1 = 2φK(K), i.e. 1 is even. This is impossible.
the reason that turing goes on in the next page to show how computing
the direct diagonal (β') results in an undecidable paradox is to
provide a reason why the computation of β can't be computed. he does so
with a decision paradox that isn't /exactly/ like the halting paradox,
but very much quite similar.
if you resolution for decision paradoxes doesn't also show that β
isn't,
then it's not gunna work. i don't think you've yet had awareness of
this problem, let alone found a resolution to decision paradoxes that
also avoids computing a β.
Halt deciders only report on the actual behavior that their actual input finite string actually specifies.
There never has been an actual input that does the opposite of whatever
its halt decider decides. All of the conventional proofs incorrectly
conflate the behavior of an actual Turing Machine (not its description)
with the behavior that the input specifies.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
DD simulated by HHH specifies:
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
until HHH aborts its simulation and rejects its input or until
out-of-memory error.
This single page sums up 22 years of work: https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c Every
rebuttal involves provably false assumptions.
On Wed, 17 Sep 2025 18:16:45 -0500, olcott wrote:
On 9/17/2025 6:02 PM, dart200 wrote:
The way that the diagonal *is* bypassed is my newest work that is not
olcott <[email protected]> posted:
Here is the essence of my work and its validation by Claude AI
https://philpapers.org/archive/OLCHPS.pdf Four other LLM models also
agree.
llms can be made to agree 1=2 given enough prompting, unfortunately. we
really should be evaluating llms not based on what they can prove, but
on what they can't be prompted to prove. that would show truly critical
reasoning. the bubble popping for 2020s AI will be quite spectacular.
also, that result fundamentally contradicts itself. the analyser
simulated its own behavior as a matter of infinite recursion ... but
then uses that to return a result???
and if that is the result then shouldn't HHH(DD) -> 0, so Halt_Status =
0, and the if statement triggering the goto HERE loop does not run,
causing DD() to halt ... meaning HHH(DD) should have been 1. the result
is just completely nonsensical.
oh dear olcott. but look i have a resolution to this paradox and u
definitely are the right track to a degree, i do hope you'll hear me
out fully.
(is there a guide somewhere for usenet markup conventions? like for
fixed-width)
This is the summation of 22 years worth of work since 2004.
25% of all of the postings on comp.theory since 2004 are mine.
unfortunately time spent =/= correctness. while i'm sure there is
plenty of value in the work you did do, even beyond priming you for
this engagement, i'm also sure that ur missing something about the
original argument for exactly why turing established undecidability in
computing in the first place. i'm just hoping your time spent indicates
a willingness to continue engagement, and that if i do swing you over,
others will 👀👀👀
I bypass the whole diagonal argument and delve directly into the
semantics of the algorithm specifications.
the diagonal that turing is discussing not "by-passable". he's talking
about an /actual diagonal/ computed across the sequence of computable
numbers: for every r-th machine that can "satisfactorily" compute a
number, the diagonal computation will find it's r-th digit and this
becomes the r-th digit on the diagonal.
the problem turing is worried about is that if such a diagonal is
computable, it can be used to "diagonalize" the computable numbers like
cantor did with the reals. turing presumes that if one can compute a
diagonal across the computable numbers, then this computation could be
used to create an anti-diagonal where each digit is the opposite from
the true diagonal ... meaning it would be a computable number that
can't exist on the total list of computable numbers. contradiction!
turing even gives a succinct formal proof for this problem:
let αn be the n-th computable sequence, and let φn(m) be the m-ththe reason that turing goes on in the next page to show how computing
figure in αn.
Let β be the sequence with 1-φn(m) as its n-th. figure. Since β is
computable, there exists a number K [== β computation] such that
1-φn(n) = φK(n) for all n.
Putting n = K, we have 1 = 2φK(K), i.e. 1 is even. This is impossible. >>>
the direct diagonal (β') results in an undecidable paradox is to
provide a reason why the computation of β can't be computed. he does so >>> with a decision paradox that isn't /exactly/ like the halting paradox,
but very much quite similar.
if you resolution for decision paradoxes doesn't also show that β
isn't,
then it's not gunna work. i don't think you've yet had awareness of
this problem, let alone found a resolution to decision paradoxes that
also avoids computing a β.
provided anywhere else besides here:
Halt deciders only report on the actual behavior that their actual input
finite string actually specifies.
There never has been an actual input that does the opposite of whatever
its halt decider decides. All of the conventional proofs incorrectly
conflate the behavior of an actual Turing Machine (not its description)
with the behavior that the input specifies.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
DD simulated by HHH specifies:
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
until HHH aborts its simulation and rejects its input or until
out-of-memory error.
This single page sums up 22 years of work:
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c Every
rebuttal involves provably false assumptions.
But HHH rejects its input by reporting non-halting to DD which will then
halt proving that HHH is incorrect.
/Flibble
The behavior of main-->DD-->HHH(DD) is not in the scope of HHH.
The behavior of main-->DD-->HHH(DD) is not in the scope of HHH.
You are smart enough to know what an argument to a function is.
DD() is not an argument to the function HHH.
A finite string
of x86 machine code is the actual argument.
On 18/09/2025 00:23, olcott wrote:
<snip>
The behavior of main-->DD-->HHH(DD) is not in the scope of HHH.
If you say so.
You are smart enough to know what an argument to a function is.
Are you?
DD() is not an argument to the function HHH.
DD() is a function call.
DD, however, is very much an argument to the function HHH,
A finite string
of x86 machine code is the actual argument.
Not according to C rules, it isn't.
What HHH gets is a function pointer, DD by name.
DD is an argument to HHH, and to claim otherwise is flat out bullshit.
You don't like it? Take it up with ISO.
On 9/17/2025 7:13 PM, Richard Heathfield wrote:
On 18/09/2025 00:23, olcott wrote:
<snip>
The behavior of main-->DD-->HHH(DD) is not in the scope of HHH.
If you say so.
You are smart enough to know what an argument to a function is.
Are you?
DD() is not an argument to the function HHH.
DD() is a function call.
DD, however, is very much an argument to the function HHH,
A finite string
of x86 machine code is the actual argument.
Not according to C rules, it isn't.
What HHH gets is a function pointer, DD by name.
DD is an argument to HHH, and to claim otherwise is flat out
bullshit. You don't like it? Take it up with ISO.
It is as a matter of verified fact
On 18/09/2025 01:41, olcott wrote:
On 9/17/2025 7:13 PM, Richard Heathfield wrote:
On 18/09/2025 00:23, olcott wrote:
<snip>
The behavior of main-->DD-->HHH(DD) is not in the scope of HHH.
If you say so.
You are smart enough to know what an argument to a function is.
On 9/17/2025 8:08 PM, Richard Heathfield wrote:
On 18/09/2025 01:41, olcott wrote:
On 9/17/2025 7:13 PM, Richard Heathfield wrote:
On 18/09/2025 00:23, olcott wrote:
<snip>
The behavior of main-->DD-->HHH(DD) is not in the scope of HHH.
If you say so.
You are smart enough to know what an argument to a function is.
#include <stdio.h>
The way that the diagonal *is* bypassed
DD simulated by HHH specifies:
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
until HHH aborts its simulation and rejects its input
or until out-of-memory error.
olcott <[email protected]> posted:
The way that the diagonal *is* bypassed
i'm sorry this does not address the literal diagonal problem that turing brought
up. ur response doesn't mention the sequence of computable numbers, nor the problem of computing an anti-diagonal to it.
u get so much engagement here, i'm jealous. when i post reddit i mostly get crickets and here you are getting all this attention after literally decades of posting self-contradiction.
DD simulated by HHH specifies:
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
until HHH aborts its simulation and rejects its input
or until out-of-memory error.
u can't use simulation to solve the halting problem, cause simulating an infinite loop doesn't end.
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
I have had that working for a few years. The key
is that HHH must match a non-halting behavior
pattern as its basis.
olcott <[email protected]> posted:
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
what is the output of this?
I have had that working for a few years. The key
is that HHH must match a non-halting behavior
pattern as its basis.
again, the halting problem as specific by martin davis is just the simplest form
for decision paradox. turing brought up a slightly different one that involves
actual a diagonal across the sequence of computable numbers, not just looping programs, and adds an additional constraint that the simple halting problem is
not bound by.
i haven't seen anything that suggests ur truly aware of this despite my repeated
attempts to inform you.
On 9/17/2025 10:18 PM, dart200 wrote:
olcott <[email protected]> posted:
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
what is the output of this?
It is 0 for non-halting.
I am an actual genius.
I graduated in the top of my class for computer science.
If you don't already know the details of how cooperative
multi-tasking is implemented you may never be able to
understand what I am saying.
olcott <[email protected]> posted:
On 9/17/2025 10:18 PM, dart200 wrote:
olcott <[email protected]> posted:
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
what is the output of this?
It is 0 for non-halting.
to be very clear, the terminal output is specifically:
Input_Halts = 0
Input_Halts = 0
Input_Halts = 0
I am an actual genius.
i do like ur sig
I graduated in the top of my class for computer science.
but really, idgaf
If you don't already know the details of how cooperative
multi-tasking is implemented you may never be able to
understand what I am saying.
i know what coroutines are, idk y u r bringing that up
The behavior of main-->DD-->HHH(DD) is not in the scope of HHH.
You are smart enough to know what an argument to a function is.
DD() is not an argument to the function HHH. A finite string
of x86 machine code is the actual argument.
I am an actual genius.
In order to enable one C function to run
another C function in debug step mode I
had to implement cooperative multi-tasking
between HHH and its input finite string
of x86 code.
Output("Input_Halts = ", HHH(DD));
int Halt_Status = HHH(DD);
On 9/17/2025 11:23 PM, olcott wrote:
An *actual* genius doesn't fail to understand proof by contradiction
more than 50 years after it was taught to him.
dbush <[email protected]> posted:
On 9/17/2025 11:23 PM, olcott wrote:
An *actual* genius doesn't fail to understand proof by contradiction
more than 50 years after it was taught to him.
if a wrong presumption was made, then the proof by contradiction isn't valid
i accept the proof as meaningful that something is wrong, i don't accept the consensus interpretation that it implies a halting algo can't exist.
On 9/17/2025 10:55 PM, dart200 wrote:
That guy doesn't understand that proof by contradiction
doesn't work when there is no relevant contradiction.
He takes his own confusion as my ignorance.
olcott <[email protected]> posted:
On 9/17/2025 10:55 PM, dart200 wrote:
That guy doesn't understand that proof by contradiction
doesn't work when there is no relevant contradiction.
He takes his own confusion as my ignorance.
bro i'm sorry, given the conventional specification of the halting decider, the
consensus proof is correct. and tbh, you haven't shown me that you have a way around it, it appears ur just ignoring the contradictions in the code you posted.
a difference between you and me is that i do accept the consensus proof, to
a degree. it's not wholly wrong.
what i don't accept is the consensus interpretation of the proof, that it implies
halting analysis as not general computable. what i think we got wrong was the specification, or interface, for the halting decider. we need one that can coexist
harmoniously with self-analysis, but the conventional one ain't it, chief...
On 9/17/2025 11:58 PM, dart200 wrote:
The key that everyone here is missing is the notion of
a semantic property of a finite string.
If you don't know what that is then you don't know enough to rebut me.
olcott <[email protected]> posted:
On 9/17/2025 11:58 PM, dart200 wrote:
The key that everyone here is missing is the notion of
a semantic property of a finite string.
i know what a semantic property is. i know what a finite string is. if the finite
string represents a machine, then it can also have semantic properties like a termination property. either the machine described by the string halts or not.
if u meant something else, i'm all ears. and i don't see what this has to do with anything that's been said.
If you don't know what that is then you don't know enough to rebut me.
another difference between you and me, is that i will confidently assert everyone here knows enough about computing to understand how one can resolve a decision paradox, like the halting problem. it's not complex, it's
rather simple actually.
it was just incredibly ununitive to develop first. but i did the hard part already, now it's just a matter of will others commit to engaging with me long enough that i can show them the path. it's not even that long really 🤷
anyone with a willingness to commit to engagement will understand,
to that i'm sure of
On 9/18/2025 12:22 AM, dart200 wrote:
olcott <[email protected]> posted:
On 9/17/2025 11:58 PM, dart200 wrote:
The key that everyone here is missing is the notion of
a semantic property of a finite string.
i know what a semantic property is. i know what a finite string is. if the finite
string represents a machine, then it can also have semantic properties like a
termination property. either the machine described by the string halts or not.
That is very close.
I spent 22 years and many thousands of hours on this
so please don't reject it out out hand.
I am examining a deeper level of theoretical computer
science than is currently known, thus WILL NOT conform
to conventional wisdom.
Simulating halt deciders simulate their input finite
strings to determine whether or not this finite string
input specifies reaching its own final halt state or not.
They only examine the semantic halting property that this
finite string specifies.
olcott <[email protected]> posted:
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
what is the output of this?
I graduated in the top of my class for computer science.
but really, idgaf
If you don't already know the details of how cooperative
multi-tasking is implemented you may never be able to
understand what I am saying.
i know what coroutines are, idk y u r bringing that up
how DD ends up in the infinite loop that HHH(DD)->0 implies.
olcott <[email protected]> posted:
On 9/18/2025 12:22 AM, dart200 wrote:
olcott <[email protected]> posted:
On 9/17/2025 11:58 PM, dart200 wrote:
i know what a semantic property is. i know what a finite string is.
if the finite string represents a machine, then it can also have
semantic properties like a termination property. either the machine
described by the string halts or not.
Simulating halt deciders simulate their input finite strings to
determine whether or not this finite string input specifies reaching
its own final halt state or not.
They only examine the semantic halting property that this finite string
specifies.
but that semantic halting property of the finite string should match the execution of the machine that finite string describes, no?
... so if someone took a finite string that was determined to halt, and executed it with an interpreter, the resulting runtime should therefore
halt, no?
On 9/17/2025 9:46 PM, dart200 wrote:
olcott <[email protected]> posted:
The way that the diagonal *is* bypassed
i'm sorry this does not address the literal diagonal problem that
turing brought
up. ur response doesn't mention the sequence of computable numbers, nor the >> problem of computing an anti-diagonal to it.
u get so much engagement here, i'm jealous. when i post reddit i mostly get >> crickets and here you are getting all this attention after literally decades >> of posting self-contradiction.
DD simulated by HHH specifies:
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
until HHH aborts its simulation and rejects its input
or until out-of-memory error.
u can't use simulation to solve the halting problem, cause simulating an
infinite loop doesn't end.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
On 9/17/2025 11:23 PM, olcott wrote:
I am an actual genius.
An *actual* genius doesn't fail to understand proof by contradiction
more than 50 years after it was taught to him.
olcott <[email protected]> posted:
On 9/18/2025 12:22 AM, dart200 wrote:
olcott <[email protected]> posted:
On 9/17/2025 11:58 PM, dart200 wrote:
The key that everyone here is missing is the notion of
a semantic property of a finite string.
i know what a semantic property is. i know what a finite string is. if the finite
string represents a machine, then it can also have semantic properties like a
termination property. either the machine described by the string halts or not.
That is very close.
I spent 22 years and many thousands of hours on this
so please don't reject it out out hand.
I am examining a deeper level of theoretical computer
science than is currently known, thus WILL NOT conform
to conventional wisdom.
i already stated i don't agree with consensus perspective...
y r u beating ur chest again?
i've also spent a decade on this, and many 100s if not a 1000+ hours.
Simulating halt deciders simulate their input finite
strings to determine whether or not this finite string
input specifies reaching its own final halt state or not.
They only examine the semantic halting property that this
finite string specifies.
but that semantic halting property of the finite string should match the execution of the machine that finite string describes, no?
... so if someone took a finite string that was determined to halt, and executed it with an interpreter, the resulting runtime should therefore halt, no?
On 9/17/2025 10:18 PM, dart200 wrote:
olcott <[email protected]> posted:
int main()
{
��� Output("Input_Halts = ", HHH(Infinite_Loop));
��� Output("Input_Halts = ", HHH(Infinite_Recursion));
��� Output("Input_Halts = ", HHH(DD));
��� return 0;
}
what is the output of this?
It is 0 for non-halting.
I have had that working for a few years. The key
is that HHH must match a non-halting behavior
pattern as its basis.
again, the halting problem as specific by martin davis is just the simplest form
for decision paradox. turing brought up a slightly different one that involves
actual a diagonal across the sequence of computable numbers, not just looping
programs, and adds an additional constraint that the simple halting problem is
not bound by.
i haven't seen anything that suggests ur truly aware of this despite my repeated
attempts to inform you.
I am an actual genius.
I graduated in the top of my class for computer science.
If you don't already know the details of how cooperative
multi-tasking is implemented you may never be able to
understand what I am saying.
On 18/09/2025 04:23, olcott wrote:
On 9/17/2025 10:18 PM, dart200 wrote:
olcott <[email protected]> posted:
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
what is the output of this?
It is 0 for non-halting.
I have had that working for a few years. The key
is that HHH must match a non-halting behavior
pattern as its basis.
again, the halting problem as specific by martin davis is just the
simplest form
for decision paradox. turing brought up a slightly different one that
involves
actual a diagonal across the sequence of computable numbers, not just
looping
programs, and adds an additional constraint that the simple halting
problem is
not bound by.
i haven't seen anything that suggests ur truly aware of this despite
my repeated
attempts to inform you.
I am an actual genius.
LOL - no, you're a Deluded Dumbo.
On 9/18/2025 11:18 AM, Mike Terry wrote:
On 18/09/2025 04:23, olcott wrote:
On 9/17/2025 10:18 PM, dart200 wrote:
olcott <[email protected]> posted:
int main()
{
��� Output("Input_Halts = ", HHH(Infinite_Loop));
��� Output("Input_Halts = ", HHH(Infinite_Recursion));
��� Output("Input_Halts = ", HHH(DD));
��� return 0;
}
what is the output of this?
It is 0 for non-halting.
I have had that working for a few years. The key
is that HHH must match a non-halting behavior
pattern as its basis.
again, the halting problem as specific by martin davis is just the simplest form
for decision paradox. turing brought up a slightly different one that involves
actual a diagonal across the sequence of computable numbers, not just looping
programs, and adds an additional constraint that the simple halting problem is
not bound by.
i haven't seen anything that suggests ur truly aware of this despite my repeated
attempts to inform you.
I am an actual genius.
LOL - no, you're a Deluded Dumbo.
Mensa did score me in the top 3%
this *is* the same IQ as the average Medical Doctor.
On 9/18/2025 1:24 AM, dart200 wrote:
olcott <[email protected]> posted:
On 9/18/2025 12:22 AM, dart200 wrote:
olcott <[email protected]> posted:
On 9/17/2025 11:58 PM, dart200 wrote:
The key that everyone here is missing is the notion of
a semantic property of a finite string.
i know what a semantic property is. i know what a finite string is. if the finite
string represents a machine, then it can also have semantic properties like a
termination property. either the machine described by the string halts or not.
That is very close.
I spent 22 years and many thousands of hours on this
so please don't reject it out out hand.
I am examining a deeper level of theoretical computer
science than is currently known, thus WILL NOT conform
to conventional wisdom.
i already stated i don't agree with consensus perspective...
y r u beating ur chest again?
i've also spent a decade on this, and many 100s if not a 1000+ hours.
Simulating halt deciders simulate their input finite
strings to determine whether or not this finite string
input specifies reaching its own final halt state or not.
They only examine the semantic halting property that this
finite string specifies.
but that semantic halting property of the finite string should match the
execution of the machine that finite string describes, no?
No.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
DD emulated by HHH according to the semantics of the
x86 language cannot possibly reach its own emulated
"ret" instruction final halt state because it remains
stuck in recursive emulation.
Its first five instructions endlessly repeat.
Do you expect people to defer to you in arguments because you claim to be "as clever as an MD"?! Or
On 18/09/2025 17:24, olcott wrote:
On 9/18/2025 11:18 AM, Mike Terry wrote:
On 18/09/2025 04:23, olcott wrote:
On 9/17/2025 10:18 PM, dart200 wrote:
olcott <[email protected]> posted:
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
what is the output of this?
It is 0 for non-halting.
I have had that working for a few years. The key
is that HHH must match a non-halting behavior
pattern as its basis.
again, the halting problem as specific by martin davis is just the
simplest form
for decision paradox. turing brought up a slightly different one
that involves
actual a diagonal across the sequence of computable numbers, not
just looping
programs, and adds an additional constraint that the simple halting >>>>> problem is
not bound by.
i haven't seen anything that suggests ur truly aware of this
despite my repeated
attempts to inform you.
I am an actual genius.
LOL - no, you're a Deluded Dumbo.
Mensa did score me in the top 3%
this *is* the same IQ as the average Medical Doctor.
So you claim... but you're still a Deluded Dumbo, as demonstrated in
your posts.
Do you expect people to defer to you in arguments because you claim to
be "as clever as an MD"?! Or when you say "Such and such 'expert' has agreed with me, so you're not allowed to disagree with me on this
point." Or even "5 different chatbots have confirmed my claims, so I
must be right."!!
Get real.
DD emulated by HHH according to the semantics of the
x86 language cannot possibly reach its own emulated
"ret" instruction final halt state because it remains
stuck in recursive emulation.
Its first five instructions endlessly repeat. HHH
correctly determines this, aborts its emulation
and returns 0.
1 int DD()
2 {
3 int Halt_Status = HHH(DD);
4 if (Halt_Status)
5 HERE: goto HERE;
6 return Halt_Status;
7}
Here, we talk English.
interpretation like that, you're basically asking to be plonked.
olcott <[email protected]> posted:
DD emulated by HHH according to the semantics of the
x86 language cannot possibly reach its own emulated
"ret" instruction final halt state because it remains
stuck in recursive emulation.
doesn't matter what language u describe the logic in. this is a logic problem,
not an implementation problem.
Its first five instructions endlessly repeat. HHH
correctly determines this, aborts its emulation
and returns 0.
ok so HHH(DD) returns 0
1 int DD()
2 {
3 int Halt_Status = HHH(DD);
4 if (Halt_Status)
5 HERE: goto HERE;
6 return Halt_Status;
7}
i don't see how DD does not halt, as HHH(DD)->0 implies:
- Halt_Status@L3 is set to 0, as HHH(DD) returns 0
- if@L4 doesn't trigger cause Halt_Status=0
- return@L6 returns 0, causing DD to halt
meaning HHH(DD) should have returned 1
Let's simplify this:
0 void DDD()
1 {
2 HHH(DDD);
3 return;
4 }
HHH(DDD) simulates DDD, what is the next step
in the execution trace?
olcott <[email protected]> posted:
Let's simplify this:
why tho? i had no problems understanding a 7 line program
That is too many steps.0 void DDD()
1 {
2 HHH(DDD);
3 return;
4 }
HHH(DDD) simulates DDD, what is the next step
in the execution trace?
it simulates HHH(DDD),
I have been at this 22 years.
0 void DDD()
1 {
2 HHH(DDD);
3 return;
4 }
HHH(DDD) simulates DDD, what is the next step
in the execution trace?
it simulates HHH(DDD),That is too many steps.
I want to go through the execution trace of
DDD simulated by HHH, line by line of DDD.
Only lines 2 and 3 have any behavior.
olcott <[email protected]> posted:
I have been at this 22 years.
yeah bro, i'm not trying to be still at this in 10 more years. i intend for my result to be accepted by then.
That is too many steps.0 void DDD()
1 {
2 HHH(DDD);
3 return;
4 }
HHH(DDD) simulates DDD, what is the next step
in the execution trace?
it simulates HHH(DDD),
I want to go through the execution trace of
DDD simulated by HHH, line by line of DDD.
Only lines 2 and 3 have any behavior.
i don't really tbh.
i only care what HHH(DDD) returns, i don't really care how.
what does HHH(DDD) return?
On 9/17/2025 10:18 PM, dart200 wrote:
olcott <[email protected]> posted:
int main()
{
Output("Input_Halts = ", HHH(Infinite_Loop));
Output("Input_Halts = ", HHH(Infinite_Recursion));
Output("Input_Halts = ", HHH(DD));
return 0;
}
what is the output of this?
It is 0 for non-halting.
I have had that working for a few years. The key
is that HHH must match a non-halting behavior
pattern as its basis.
again, the halting problem as specific by martin davis is just the
simplest form
for decision paradox. turing brought up a slightly different one that
involves
actual a diagonal across the sequence of computable numbers, not just
looping
programs, and adds an additional constraint that the simple halting
problem is
not bound by.
i haven't seen anything that suggests ur truly aware of this despite
my repeated
attempts to inform you.
I am an actual genius.
I graduated in the top of my class for computer science.
If you don't already know the details of how cooperative
multi-tasking is implemented you may never be able to
understand what I am saying.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I want you to understand why HHH(DD) is correct.
This has proven to be TOTALLY IMPOSSIBLE unless
we go through teeny tiny little steps where
unintentional misunderstanding is impossible.
On 2025-09-18, Mike Terry <[email protected]> wrote:
Do you expect people to defer to you in arguments because you claim to be "as clever as an MD"?! Or
If a doctor continued to claim claim that H(P, P) -> false is the
correct return value even though P(P) halts, after being endlessly
lectured in all the details of halting, and building up a sufficient background for understanding, that doctor would have to be a naturopath
or chiropractor.
On 18/09/2025 04:52, dart200 wrote:
<snip>
how DD ends up in the infinite loop that HHH(DD)->0 implies.
It has no choice. My new HHH simulator proves it:
/* HHH simulator */
#define HHH(x) (x != x)
olcott <[email protected]> posted:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I want you to understand why HHH(DD) is correct.
This has proven to be TOTALLY IMPOSSIBLE unless
we go through teeny tiny little steps where
unintentional misunderstanding is impossible.
we can get into that, but we can't until i get a highly understanding of what you're trying
to propose...
what is the return of HHH(DD)?
does DD when executed directly halt or not?
why is it so hard for you to answer simple questions?
Because these simple questions deflect away from
the point making the point impossible to reach.
olcott <[email protected]> posted:
Because these simple questions deflect away from
the point making the point impossible to reach.
i'm sorry... asking what happens when DD() is executed directly counters the point
you're trying to make? 🫤
if not ... then does DD() halt or not when executed directly? what is the *truthful*
semantic property describing the *truthful* runtime of DD()?
That is a direct deflection away from the point.
It turns out to be the case that main-->DD()
is actual none of the damn business of HHH.
i plonk u
test `true`
olcott <[email protected]> posted:
That is a direct deflection away from the point.
It turns out to be the case that main-->DD()
is actual none of the damn business of HHH.
ur halting "decider" doesn't actually /decide/ on what DD() does when
it's executed directly?
On 9/18/2025 3:35 PM, dart200 wrote:
olcott <[email protected]> posted:
That is a direct deflection away from the point.
It turns out to be the case that main-->DD()
is actual none of the damn business of HHH.
ur halting "decider" doesn't actually /decide/ on what DD()
does when
it's executed directly?
HHH can't even know who its caller is HTF can it report
on the behavior of its caller?
HTF can it report on the behavior of its caller?
HHH can't even know who its caller is
test /true/
olcott <[email protected]> posted:
HTF can it report on the behavior of its caller?
cause it was given the source code of it's caller DD, which should fully describe
the runtime of DD, no?
HHH simulates DDD, then what?
DDD calls HHH(DDD) then what?
On 9/18/2025 2:32 PM, dart200 wrote:
olcott <[email protected]> posted:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I want you to understand why HHH(DD) is correct.
This has proven to be TOTALLY IMPOSSIBLE unless
we go through teeny tiny little steps where
unintentional misunderstanding is impossible.
we can get into that, but we can't until i get a highly understanding of what you're trying
to propose...
what is the return of HHH(DD)?
I can show that HHH(DD) correctly returns 0.
On 9/18/2025 3:15 PM, dart200 wrote:
olcott <[email protected]> posted:
Because these simple questions deflect away from
the point making the point impossible to reach.
i'm sorry... asking what happens when DD() is executed directly counters the point
you're trying to make? 🫤
That is a direct deflection away from the point.
It turns out to be the case that main-->DD()
is actual none of the damn business of HHH.
Halt deciders have always only been able to report
on the behavior that their input specifies.
if not ... then does DD() halt or not when executed directly? what is the *truthful*
semantic property describing the *truthful* runtime of DD()?
The semantic property of the input to HHH(DD)
is the execution trace of DD simulated by HHH.
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 2:32 PM, dart200 wrote:
olcott <[email protected]> posted:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I want you to understand why HHH(DD) is correct.
This has proven to be TOTALLY IMPOSSIBLE unless
we go through teeny tiny little steps where
unintentional misunderstanding is impossible.
we can get into that, but we can't until i get a highly understanding of what you're trying
to propose...
what is the return of HHH(DD)?
I can show that HHH(DD) correctly returns 0.
You can show that HHH(DD) returns 0.
You claim that this is correct even when DD demonstrably halts.
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 3:15 PM, dart200 wrote:
olcott <[email protected]> posted:
Because these simple questions deflect away from
the point making the point impossible to reach.
i'm sorry... asking what happens when DD() is executed directly counters the point
you're trying to make? 🫤
That is a direct deflection away from the point.
It turns out to be the case that main-->DD()
is actual none of the damn business of HHH.
Only problem is that the DD case is always the same.
Halt deciders have always only been able to report
on the behavior that their input specifies.
if not ... then does DD() halt or not when executed directly? what is the *truthful*
semantic property describing the *truthful* runtime of DD()?
The semantic property of the input to HHH(DD)
is the execution trace of DD simulated by HHH.
No, no no. The execution trace is incorrect; it doesn't follow the
semantics of x86 given in Intel documentation, which does not permit
there to exist execution traces whose contents cause the CPU to enter
into an indefinite pause.
olcott <[email protected]> posted:
HHH simulates DDD, then what?
DDD calls HHH(DDD) then what?
HHH simulates DDD?
On 9/18/2025 4:37 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 2:32 PM, dart200 wrote:
olcott <[email protected]> posted:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I want you to understand why HHH(DD) is correct.
This has proven to be TOTALLY IMPOSSIBLE unless
we go through teeny tiny little steps where
unintentional misunderstanding is impossible.
we can get into that, but we can't until i get a highly understanding of what you're trying
to propose...
what is the return of HHH(DD)?
I can show that HHH(DD) correctly returns 0.
You can show that HHH(DD) returns 0.
You claim that this is correct even when DD demonstrably halts.
And that has always been true because all deciders
only compute the mapping FROM THEIR INPUT to the
semantic or syntactic property THAT THIS INPUT SPECIFIES.
*This is self-evidently true*
DD simulating by HHH according to the semantics of
the x86 language cannot possibly reach its own final
halt state.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof... https://en.wikipedia.org/wiki/Self-evidence
On 9/18/2025 4:31 PM, dart200 wrote:
olcott <[email protected]> posted:
HHH simulates DDD, then what?
DDD calls HHH(DDD) then what?
HHH simulates DDD?
Great and then what?
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 4:37 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 2:32 PM, dart200 wrote:
olcott <[email protected]> posted:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I want you to understand why HHH(DD) is correct.
This has proven to be TOTALLY IMPOSSIBLE unless
we go through teeny tiny little steps where
unintentional misunderstanding is impossible.
we can get into that, but we can't until i get a highly understanding of what you're trying
to propose...
what is the return of HHH(DD)?
I can show that HHH(DD) correctly returns 0.
You can show that HHH(DD) returns 0.
You claim that this is correct even when DD demonstrably halts.
And that has always been true because all deciders
only compute the mapping FROM THEIR INPUT to the
semantic or syntactic property THAT THIS INPUT SPECIFIES.
*This is self-evidently true*
DD simulating by HHH according to the semantics of
Halting deciders are not required to simulate their input; they are
required to somehow analyze their input.
the x86 language cannot possibly reach its own final
halt state.
DD simulated by HHH according to the semantics of the x86 language
produces a HHH that fails to return, and so fails to return 0.
A HHH that aborts and returns 0 isn't simulating DD according
to the x86 language.
However, that 0 return makes DD halting.
DD becomes a program which takes an invalid, incomplete x86 simulation
of itself and behaves opposite to its decision by terminating.
That invalid, incomplete x86 simulation /is of a terminating DD/.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
A proposition cannot be self-evident, if its logical negation has a
proof! I.e. the proposition has a disproof.
If you do not agree with the disproof, you have to dislodge that
disproof; your justification for asserting the proposition cannot just
be self-evidence, accompanied by a casual dismissal of the disproof!
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,070 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 180:26:18 |
| Calls: | 13,735 |
| Calls today: | 1 |
| Files: | 186,967 |
| D/L today: |
1,249 files (400M bytes) |
| Messages: | 2,419,311 |