Am Tue, 19 Aug 2025 21:09:14 -0500 schrieb olcott:
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 5:58 PM, André G. Isaak wrote:
On 2025-08-19 11:42, olcott wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You should just go ahead and do it. It would show the behaviour better.But if (**execution_trace == 0x90909090) creates the exact sameI have known that for years.
problem as using a static variable. You're creating a global state
which your HHH accesses and thus HHH is not a pure function.
After I got people here to quit lying about the behavior of DD correct >>>> simulated by HHH I had intended to fix that issue.
I can assure you everybody will be completely honest about that.The correct simulation doesn't matter.I know that yet if I corrected that everyone here besides you would lie
The static flag (whether using a "static" variable, or de-facto static
data stored in the code segment) throws a monkey wrench into the claim
you are making based on a correct simulation.
about my having eliminated all static data as they lie about nearly
everything else.
The input isn’t even doing anything, it’s just data. The simulator is doing all the futile work. *That* is the one that can’t reach pastThe if statement testing the value of *execution_trace, together withThe fact that the counter-example input cannot even reach its own "do
another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
The fact that HHH (top level) can correctly decide something that HH
(recursive) doesn't decide is not interesting and doesn't speak to the
Halting Theorem.
the opposite" code and remains stuck in recursive simulation does apply
to the halting problem proofs.
itself, when it quite clearly does halt. HHH(HHH) thinks itself doesn’t halt, and yet it does.
The proof shows that the assumption is wrong. D halts, and H does notContrary to your repeatedly stated belief, The Halting Theorem doesn'tThe halting problem proofs depend on the assumption that there is an H/D
say that there exist test cases whose halting is indeterminate such
that they cannot be decided by /any/ decider.
pair such that D is undecidable by H. When I show how D is correctly
decided by H these proofs fail.
return that.
I am not just using execution_trace as a flag.You are *also* using it as a flag.
Am Tue, 19 Aug 2025 21:58:46 -0500 schrieb olcott:
On 8/19/2025 9:55 PM, Mike Terry wrote:
On 19/08/2025 23:27, Chris M. Thomasson wrote:
On 8/19/2025 3:21 PM, olcott wrote:
On 8/19/2025 5:16 PM, Chris M. Thomasson wrote:
On 8/19/2025 3:02 PM, olcott wrote:
On 8/19/2025 1:29 PM, Richard Heathfield wrote:
She did correct me once.Oh. I did not know. Sorry.She is not Joe S, she is Joes.This is where you apologise to joe for falsely accusing him of >>>>>>>> lying.
I have never seen any evidence to suggest that Joes is female, other
than PO correcting people when they say otherwise. I put little/no
store in that.
Not that it matters one iota whether Joes is male or female. Joes
doesn't confirm either way which is fine.
Thanks, Mike.
You can use „they” or any funny neopronouns, or just my name.
On 8/20/2025 4:58 AM, joes wrote:
Thanks, Mike.
You can use „they” or any funny neopronouns, or just my name.
Do you prefer she to other pronouns?
On 8/19/2025 7:55 PM, Mike Terry wrote:
On 19/08/2025 23:27, Chris M. Thomasson wrote:
On 8/19/2025 3:21 PM, olcott wrote:
On 8/19/2025 5:16 PM, Chris M. Thomasson wrote:
On 8/19/2025 3:02 PM, olcott wrote:
On 8/19/2025 1:29 PM, Richard Heathfield wrote:
On 19/08/2025 19:23, olcott wrote:
On 8/19/2025 1:21 PM, Richard Heathfield wrote:
On 19/08/2025 19:07, olcott wrote:
On 8/19/2025 1:05 PM, joes wrote:<snip>
Am Tue, 19 Aug 2025 12:50:31 -0500 schrieb olcott:
Is it possible to create a halt decider: H that consistently >>>>>>>>>>>> reports the
halt status of the behavior specified by its input finite >>>>>>>>>>>> string Turing
machine description: P as measured by P correctly simulated >>>>>>>>>>>> by H?
Yes, behold:
return 0;
It simulates no instructions incorrectly
Now you are a Liar.
Are you claiming that his H simulates some instructions
incorrectly, or that his H returns non-zero?
That was my mistake for not paying close enough
attention. All the instructions that HHH emulates
are emulated correctly.
This is where you apologise to joe for falsely accusing him of
lying.
Her.
Huh?
She is not Joe S, she is Joes.
Oh. I did not know. Sorry.
I have never seen any evidence to suggest that Joes is female, other
than PO correcting people when they say otherwise. I put little/no
store in that.
Yeah. Its better to try to agree with the potentially "unstable" from
time to time?
Not that it matters one iota whether Joes is male or female. Joes
doesn't confirm either way which is fine.
Yeah. Totally fine.
On 8/19/2025 6:20 PM, Richard Heathfield wrote:
On 20/08/2025 02:00, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
<snip>
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
If HHH(DD) doens't have that value, it's just wrong.
Exercise for the discerning student: come up with a return value for
HHH(DD) that /isn't/ "just wrong".
Flip a coin and say mostly wrong?
On 20/08/2025 14:48, olcott wrote:
On 8/20/2025 4:58 AM, joes wrote:
<snip>
Thanks, Mike.
You can use „they” or any funny neopronouns, or just my name.
Do you prefer she to other pronouns?
Do you?
Who gives a turkey? This is comp.theory, not soc.bullshit.
Op 20.aug.2025 om 03:39 schreef olcott:
On 8/19/2025 8:00 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by the >>>>> HHH(1) The static flag is dead and not used.
embedded into it, a /different/ HHH (using the same procedure name and >>>>> body, distinguished from DD's HHH by a hidden static flag) can decide >>>>
if (**execution_trace == 0x90909090) is used instead.
It's the same thing. "static data" doesn't mean that "static" keyword
must be used.
Yes I know that yet I wanted you to understand
my actual code, not a misconception of it.
String literals like char *s = "abc" are understood to be static data
in C. Yet, no static keyworcd is used. Moreover, it's common for
compilers to place them into the text segment, right where the code
is---much like your *execution_trace word!
External variables without the "static" keyword are also in static
storage. At file scope "static" doesn't control the kind of storage,
but the linkage of the identifier: it give sinternal versus external
linkage.
In this debate when I say "static flag" I mean that it's something in
a persistent memory outside of the function (not allocated and
initialized on entry into the function, but externally accessed
and shared by all activations of the function).
It is not so much a flag as it is a location
to store the required execution trace.
I don't mean that the static keyword is used, which is a distracting,
irrelevant issue.
On this topic, also ...
You should go back to the static variable because it's a much more
portable way to obtain a piece of static storage associated with
a function than modifying its code. static variables are defined
by the C language, whereas self-modifying code is undefined behavior.
It clutters your code with weird gotos around inline assembly.
I envisioned my way of doing it as analogous to a UTM
setting aside a portion of its own tape for its slave
UTMs to use as their own tape.
I envision HHH as a UTM with extra features.
Moreover, you're assuming that the EAX register is free for you
to clobber. That is false; there are calling conventions for X86
where EAX is the first parameter; if you do some LEA EAX, WHATEVER,
you will obliterate the argument. Maybe that's not happening with
your toolchain but it's a threat.
I could easily see all the generated x86 code verifying
that this is in fact not an issue in this case.
that DD does not halt. Bravo! You also know that when you remove the >>>>> static flag, of course the whole show doesn't halt: you get runaway
simulation. You know that this is because the outside and inside
HHH are
then exactly the same (except that the inner one is emulated wheras >>>>> the
outside one is native).
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
Deducing what its return value should be on the basis
of the actual behavior of DD correctly simulated by
HHH is proven to be correctly 0.
If HHH(DD) doens't have that value, it's just wrong.
Not exactly. The static analysis of the C code does
prove that HHH(DD) returning 0 would be correct.
As usual incorrect claims without evidence.
No, it proves the failure of HHH to reach the final halt state specified
in the input.
If you edit HHH tro try to give it a different value, you
change DD, because DD is built on HHH. That new DD contradicts
the new HHH.
When 0 to ∞ instructions of DD are correctly
simulated by HHH the DD simulated by its HHH never
reaches its own simulated "return" statement final
halt state thus the difference between HHH/DD pairs
is of no relevant consequence.
It makes a difference, because it proves that for each HHH another DD
can be constructed for which this HHH fails.
Each input specifies a final halt state, as can be proven by other simulators using exactly the same input.
But for each HHH there is an input for which it fails to predict the
correct halting behaviour.
This is inline with the halting theorem.
It shows that simulation is not the correct tool to analyse halting behaviour, because, no matter how many steps are simulated, it is always possible to construct an input that needs more steps.
Your ownly way out is to split HHH into two (top level and recursive)
while pretending it's the same decider, but that is utterly bogus.
DD simulated by HHH that includes HHH simulating
and instance of itself simulating another instance
of DD is all a pure function of the input to HHH(DD).
Not, if the simulated HHH behaves differently because of the cheat with
the Root variable.
Not if HHH does not analyse the conditional branch instructions when simulating its own code.
It is a matter of self evident truth
(stronger than verified fact) that DD
correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state.
This self evident truth
proves that HHH(DD)==0 is correct.
Nearly everyone here has been telling lies
about this for three years, the ones that
were not lying were mistaken.
On 20/08/2025 15:07, olcott wrote:
<snip>
It is a matter of self evident truth
(stronger than verified fact) that DD
correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state.
I can fix that, by correctly simulating HHH.
typedef int (*ptr)();
#define HHH(x) 0
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
This self evident truth
...is self-evidently wrong (see above).
proves that HHH(DD)==0 is correct.
As correctly simulated by my macro.
And yet DD halts.
Nearly everyone here has been telling lies
about this for three years, the ones that
were not lying were mistaken.
Of course, it couldn't possibly be that you got it wrong.
I will quit even glancing at your posts.
On 20/08/2025 15:34, olcott wrote:
I will quit even glancing at your posts.
That's a very gracious offer. It would indeed be most helpful, if you
would be so kind.
On 8/20/2025 9:37 AM, Richard Heathfield wrote:
On 20/08/2025 15:34, olcott wrote:
I will quit even glancing at your posts.
That's a very gracious offer. It would indeed be most helpful,
if you would be so kind.
I don't know why you insist on lying about
these things. Do you also lie about climate change?
On 20/08/2025 16:21, olcott wrote:
On 8/20/2025 9:37 AM, Richard Heathfield wrote:
On 20/08/2025 15:34, olcott wrote:
I will quit even glancing at your posts.
That's a very gracious offer. It would indeed be most helpful, if you
would be so kind.
I don't know why you insist on lying about
these things. Do you also lie about climate change?
Mu.
Your question is based on a false premise,
and has no meaningful answer.
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 5:58 PM, Andr G. Isaak wrote:
On 2025-08-19 11:42, olcott wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by the HHH >>>>> embedded into it, a /different/ HHH (using the same procedure name and >>>>> body, distinguished from DD's HHH by a hidden static flag) can decide >>>>(1) The static flag is dead and not used.
if (**execution_trace == 0x90909090) is used instead.
But if (**execution_trace == 0x90909090) creates the exact same problem
as using a static variable. You're creating a global state which your
HHH accesses and thus HHH is not a pure function. Except you're doing it >>> in a far messier and more questionable way.
Andr
I have known that for years.
After I got people here to quit lying about the
behavior of DD correct simulated by HHH I had
intended to fix that issue.
The correct simulation doesn't matter.
The static flag (whether using a "static" variable, or de-facto static
data stored in the code segment) throws a monkey wrench into the
claim you are making based on a correct simulation.
The if statement testing the valueo of *execution_trace, together
with another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
The fact that HHH (top level) can correctly decide something
that HH (recursive) doesn't decide is not interesting and
doesn't speak to the Halting Theorem.
Contrary to your repeatedly stated belief, The Halting Theorem doesn't
say that there exist test cases whose halting is indeterminate such that
they cannot be decided by /any/ decider.
Any case not correctly decided by one decider is susceptible to being perfectly well decided by a different decider. Anyone who groks halting already knows this and that is all you have shown.
The honest thing would be to eliminate static variable mutations
and if tests in your code and use different names, as I suggested
years ago.
Use HHH_toplevel for the top-level decider, and HHH_recursive
for the recursive one.
void DD(void)
{
if (HH_recursive(DD)) {
// if decider says halts, loop; otherwise return.
for (;;);
}
}
main() {
puts(HHH_toplevel(DD) ? "Halts!" : "Halts not!");
return 0;
}
Exercise; just complete the implementations of HH_toplevel and
HH_recursive.
HH_toplevel contains all the logic of the original HHH when
*execution_trace is 0x90909090.
HH_recursive contains all the logic of the original HHH
when *execution_trace was not found to be 0x90909090.
It's 100% equivalent to what you are doing, except for names. Names
don't mean anything. But distinct entities should be given distinct
names, so that we don't confuse ourselves and keep our arguments
honest.
None of your rebuttals of my work have
any basis in correct reasoning.
On 19/08/2025 23:27, Chris M. Thomasson wrote:
On 8/19/2025 3:21 PM, olcott wrote:
She is not Joe S, she is Joes.
Oh. I did not know. Sorry.
I have never seen any evidence to suggest that Joes is female, other than PO correcting people when
they say otherwise. I put little/no store in that.
It is utterly unsurprising that it can obtain a correct answer;^^^^^^^
that doesn't contradict anything int the Halting Theorem.
On 2025-08-20, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
It is utterly unsurprising that it can obtain a correct answer;^^^^^^^
that doesn't contradict anything int the Halting Theorem.
Correction, "unsigned int the Halting Theorem". Sorry about that.
On 20/08/2025 02:18, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 5:58 PM, André G. Isaak wrote:
On 2025-08-19 11:42, olcott wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by(1) The static flag is dead and not used.
the HHH
embedded into it, a /different/ HHH (using the same procedure name >>>>>> and
body, distinguished from DD's HHH by a hidden static flag) can decide >>>>>
if (**execution_trace == 0x90909090) is used instead.
But if (**execution_trace == 0x90909090) creates the exact same problem >>>> as using a static variable. You're creating a global state which your
HHH accesses and thus HHH is not a pure function. Except you're
doing it
in a far messier and more questionable way.
André
I have known that for years.
After I got people here to quit lying about the
behavior of DD correct simulated by HHH I had
intended to fix that issue.
The correct simulation doesn't matter.
The static flag (whether using a "static" variable, or de-facto static
data stored in the code segment) throws a monkey wrench into the
claim you are making based on a correct simulation.
I agree. PO should eliminate the global variables in HHH et al:
a) Make the global trace table local to HHH. So there is no
need for the Root variable controlling once-off global
initialisation.
b) Also make each outer and inner HHH processing the same. All simulation
levels capture trace records from their nested simulations, and all levels
perform the same abort checking.
c) Get rid of the _ASM directives storing data directly into the code segment.
(That's the same as using static variables, but we've got rid of that
anyway with (a),(b).)
Then the (partial) simulation would be "correct" at the instruction+data level, and nested simulations would match the outer ones etc. [Up to the point simulations are aborted of course.]
The if statement testing the valueo of *execution_trace, together
with another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
I don't believe that's PO's intention, or even a good way of looking at things. This is just a judgement, not a factual claim, but I'll try to justify my thinking...
WHY does PO make the outer HHH different? It's NOT because he needs it
to be for his argument - he doesn't. If PO fixed (a),(b),(c) above,
then inner and outer HHHs and DDs would become completely identical in
their simulations, completely matching the stand-alone execution of HHH/ DD. [Exactly as they must be!] And I suggest nothing in PO's argument would change. It would /still/ be the case that DD halts when run stand-alone, and HHH(DD) would still decide never-halts even though DD halts, for the same reason they does now:
- HHH [SL0: Simulation level 0, i.e.outer HHH] would simulate DD [SL1]
and spot PO's so-called "infinite recursive emulation" pattern in the simulation, and abort [SL1], then return never-halts.
- DD [SL0] would call HHH[SL0] which would behave as above and return never-halts (after a bit of simulating and so on), then DD will return.
Nothing in PO's argument changes. He doesn't need inner HHH[DD]s to
"never terminate" when considered as computations in their own right. HHH[SL0] has spotted PO's so-called non-halting pattern regardless, so "non-halting behaviour has been expressed" and outer HHH is right [in PO-world] to return non-halting. Of course, PO will /claim/ that DD [SL1,2,3...] "would never halt if Also it is still the case that as in
PO's most famous fly-spray phrase "DD correctly simulated by HHH can
never be simulated as far as its return instruction" remains true.
One difference in actual behaviour compared to PO's current design using globals: the HHH [SL1,2,3...] (nested) simulations would execute the instructions to capture their own nested traces, and check them for
abort patterns, JUST LIKE OUTER HHH. Well that's fine and as it should be! The "big picture" flow of control is not significantly changed, because HHH [SL0] is way ahead of [SL1] and way way ahead of [SL2] etc.,
and as both are treading exactly the same computation path, SL0 is
always going to spot the abort pattern before SL1,2,3... simulations.
And the new code running in HHH [SL1,2,3...] does not affect HHH [SL0]
abort decisions.
----
So if PO's use of globals is NOT to make SL1,2,3... behave differently regarding halting, WHY did PO do it that way? Answer: he simply could not see how to do it "properly"! So he did it "wrong" and just carried on. It's not key to any of his arguments...
On 20/08/2025 17:02, olcott wrote:
None of your rebuttals of my work have
any basis in correct reasoning.
My rebuttals of what you choose to call your "work" have their general
basis in the classic proof of The Halting Problem, but my specific
rebuttals have to do with your flawed simulation of the function you
call DD. Your simulator, HHH, completely fails to capture DD's
character, and doesn't even attempt to simulate more than one line. You claim that one line is enough to give you a correct simulation.
So be it. By correctly simulating one line of HHH (the call to it), I
can demonstrate DD's character easily. Spoiler: it halts.
$ cat dd.c
#include <stdio.h>
#define HHH(x) 0
On 2025-08-20, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
On 19/08/2025 23:27, Chris M. Thomasson wrote:
On 8/19/2025 3:21 PM, olcott wrote:
She is not Joe S, she is Joes.
Oh. I did not know. Sorry.
I have never seen any evidence to suggest that Joes is female, other than PO correcting people when
they say otherwise. I put little/no store in that.
It could be a nickname for Josephine. Except that:
https://en.wikipedia.org/wiki/Josephine_(given_name)#Nicknames
has a fairly large list of these, none of them being exactly "Joes".
It's a huge guess to pull out of the local part of an example.com e-mail address used for Usenet posting.
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
#define HHH(x) 0
Moronically counter-factual.
On 20/08/2025 18:13, olcott wrote:
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
<snip>
#define HHH(x) 0
Moronically counter-factual.
Which bit?
It looks exactly right to me. It yields 0, which is the only important bit.
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the >> one input he needs, but it decides incorrectly, saying that it never halts >> when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns >>> 0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ >>> input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/
decide the
one input he needs, but it decides incorrectly, saying that it never
halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly >>> returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a
while now! All his current posting amounts to PO trying to justify /
why/ the obviously wrong answer is /really/ correct. It's all nonsense
of course.
Mike.
On 8/20/2025 12:18 PM, Richard Heathfield wrote:
On 20/08/2025 18:13, olcott wrote:
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
<snip>
#define HHH(x) 0
Moronically counter-factual.
Which bit?
It looks exactly right to me. It yields 0, which is the only
important bit.
It skips the required inference steps,
thus is not
any sort of reasoning at all.
On 20/08/2025 18:20, olcott wrote:
On 8/20/2025 12:18 PM, Richard Heathfield wrote:
On 20/08/2025 18:13, olcott wrote:
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
<snip>
#define HHH(x) 0
Moronically counter-factual.
Which bit?
It looks exactly right to me. It yields 0, which is the only
important bit.
It skips the required inference steps,
And yours skips the Turing tail in DD. If you're allowed to skip stuff,
so are other people.
Besides which, we may take as read that you've done all that inference
stuff in a previous run - use one of your magic statics - and written it down if it really matters (which I doubt, because it ends up with the
wrong answer).
The key part of HHH is that it yields 0 (which I capture), just as the
key part of DD is the if/forever/return logic, which you singularly fail
to capture.
thus is not
any sort of reasoning at all.
And your skipping DD's tail is thus not any sort of simulation at all.
Here is it 89 years later and even when
specifically told that:
Turing machine deciders only compute the mapping
from their inputs...
And it is self-evident that the caller of HHH(DD)
cannot possibly be its input
On 8/20/2025 12:29 PM, Richard Heathfield wrote:
On 20/08/2025 18:20, olcott wrote:
On 8/20/2025 12:18 PM, Richard Heathfield wrote:
On 20/08/2025 18:13, olcott wrote:
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
<snip>
#define HHH(x) 0
Moronically counter-factual.
Which bit?
It looks exactly right to me. It yields 0, which is the only
important bit.
It skips the required inference steps,
And yours skips the Turing tail in DD. If you're allowed to
skip stuff, so are other people.
Besides which, we may take as read that you've done all that
inference stuff in a previous run - use one of your magic
statics - and written it down if it really matters (which I
doubt, because it ends up with the wrong answer).
The key part of HHH is that it yields 0 (which I capture), just
as the key part of DD is the if/forever/return logic, which you
singularly fail to capture.
thus is not
any sort of reasoning at all.
And your skipping DD's tail is thus not any sort of simulation
at all.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Thus HHH(Infinite_Loop) would reach the "return"
statement final halt state of Infinite_Loop()
according to your lying ways.
On 20/08/2025 18:29, olcott wrote:
<snip>
Here is it 89 years later and even when
specifically told that:
Turing machine deciders only compute the mapping
from their inputs...
And it is self-evident that the caller of HHH(DD)
cannot possibly be its input
On the contrary, it is self-evident that you can pass in the executable
file (DD.EXE, presumably), and have the whole thing available to you via fopen and fread and so on.
If you can't see the whole of DD, you don't have a DD simulator.
On 8/19/2025 9:59 PM, Kaz Kylheku wrote:
On 2025-08-20, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
Contrary to your repeatedly stated belief, The Halting Theorem doesn't >>>> say that there exist test cases whose halting is indeterminate such that >>>> they cannot be decided by /any/ decider.
The halting problem proofs depend on the assumption
that there is an H/D pair such that D is undecidable by H.
Not quite. That should be "such that D is is either /incorrectly/
decided by H, or else H does not terminate".
OK that seems to make sense.
"Undecidable" is the situation of not having an algorithm (computational
function) to calculate some abstract Boolean math function.
Its a little more concrete when we add a model of computation.
H has some algorithm. D is chosen to make the algorithm come up
with the wrong answer, or else not to halt.
Turing machine deciders only compute the mapping
from their inputs...
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*From the bottom of page 319 has been adapted to this*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
I have gone over the HP many times.
Mensa scored me in the top 3%.
I was in the top 20% of my BSCS classes.
(You've repeatedly claimed that halting claims that D is undecidable, and
that that is obviously and pathologically wrong.)
The proofs claim that: D is undecidable by H.
When I show how D is correctly decided by H these proofs fail.
When you show how D is correctly decided by H, you are equivocating
between two definitions of H that are active simultaneously.
Not exactly. The x86utm operating system does
cooperative multi-tasking.
HHH executes then HHH simulates DD that calls HHH(DD)^^^^^^
then and HHH simulates this instance of itself simulating
There is no self-reference.
HHH is deciding on the behavior of:
DD simulated by HHH that calls HHH(DD)
that simulates DD that calls HHH(DD)...
HHH just needs the sequential list of every DD insruction
that is simulated at any level stored in execution_trace.
On 20/08/2025 18:33, olcott wrote:
On 8/20/2025 12:29 PM, Richard Heathfield wrote:
On 20/08/2025 18:20, olcott wrote:
On 8/20/2025 12:18 PM, Richard Heathfield wrote:
On 20/08/2025 18:13, olcott wrote:
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
<snip>
#define HHH(x) 0
Moronically counter-factual.
Which bit?
It looks exactly right to me. It yields 0, which is the only
important bit.
It skips the required inference steps,
And yours skips the Turing tail in DD. If you're allowed to skip
stuff, so are other people.
Besides which, we may take as read that you've done all that
inference stuff in a previous run - use one of your magic statics -
and written it down if it really matters (which I doubt, because it
ends up with the wrong answer).
The key part of HHH is that it yields 0 (which I capture), just as
the key part of DD is the if/forever/return logic, which you
singularly fail to capture.
thus is not
any sort of reasoning at all.
And your skipping DD's tail is thus not any sort of simulation at all.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Thus HHH(Infinite_Loop) would reach the "return"
statement final halt state of Infinite_Loop()
according to your lying ways.
Who cares?
On 8/20/2025 12:34 PM, Richard Heathfield wrote:
On 20/08/2025 18:29, olcott wrote:
<snip>
Here is it 89 years later and even when
specifically told that:
Turing machine deciders only compute the mapping
from their inputs...
And it is self-evident that the caller of HHH(DD)
cannot possibly be its input
On the contrary, it is self-evident that you can pass in the
executable file (DD.EXE, presumably), and have the whole thing
available to you via fopen and fread and so on.
If you can't see the whole of DD, you don't have a DD simulator.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
DD();
}
The same thing can be accomplished by making HHH()
an operating system function that gets automatically
invoked on main() before main is invoked. Same result
DD() is rejected as non-halting and main() is never
invoked.
On 8/19/2025 8:00 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by the HHH >>>> embedded into it, a /different/ HHH (using the same procedure name and >>>> body, distinguished from DD's HHH by a hidden static flag) can decide
(1) The static flag is dead and not used.
if (**execution_trace == 0x90909090) is used instead.
It's the same thing. "static data" doesn't mean that "static" keyword
must be used.
Yes I know that yet I wanted you to understand
my actual code, not a misconception of it.
String literals like char *s = "abc" are understood to be static data
in C. Yet, no static keyworcd is used. Moreover, it's common for
compilers to place them into the text segment, right where the code
is---much like your *execution_trace word!
External variables without the "static" keyword are also in static
storage. At file scope "static" doesn't control the kind of storage,
but the linkage of the identifier: it give sinternal versus external
linkage.
In this debate when I say "static flag" I mean that it's something in
a persistent memory outside of the function (not allocated and
initialized on entry into the function, but externally accessed
and shared by all activations of the function).
It is not so much a flag as it is a location
to store the required execution trace.
On this topic, also ...
You should go back to the static variable because it's a much more
portable way to obtain a piece of static storage associated with
a function than modifying its code. static variables are defined
by the C language, whereas self-modifying code is undefined behavior.
It clutters your code with weird gotos around inline assembly.
I envisioned my way of doing it as analogous to a UTM
setting aside a portion of its own tape for its slave
UTMs to use as their own tape.
I envision HHH as a UTM with extra features.
Moreover, you're assuming that the EAX register is free for you
to clobber. That is false; there are calling conventions for X86
where EAX is the first parameter; if you do some LEA EAX, WHATEVER,
you will obliterate the argument. Maybe that's not happening with
your toolchain but it's a threat.
I could easily see all the generated x86 code verifying
that this is in fact not an issue in this case.
that DD does not halt. Bravo! You also know that when you remove the
static flag, of course the whole show doesn't halt: you get runaway
simulation. You know that this is because the outside and inside HHH are >>>> then exactly the same (except that the inner one is emulated wheras the >>>> outside one is native).
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
Deducing what its return value should be on the basis
of the actual behavior of DD correctly simulated by
HHH is proven to be correctly 0.
If HHH(DD) doens't have that value, it's just wrong.
Not exactly. The static analysis of the C code does
prove that HHH(DD) returning 0 would be correct.
Linz shows such a machine that is simulating its
own machine description by his definition of his
Ĥ template. Ĥ applied to ⟨Ĥ⟩ does remain stuck in
recursive simulation unless Ĥ.embedded_H aborts
this simulation.
If Ĥ.embedded_H is smart enough to see the repeating
state then it has the basis to abort and reject.
It might be that no Ĥ.embedded_H is smart enough
to see the repeating state.
I really think you should try to get it. You are really wasting a lot of >>>> time on this. You have some programming skills. You could be doing
something useful, like teaching a kids' computer camp.
Please, re-read my post, and don't get hung up on "static", etc.
I just wanted to to understand that the only static
data needed in my current code is execution_trace.
On 8/20/2025 12:39 PM, Richard Heathfield wrote:
On 20/08/2025 18:33, olcott wrote:
On 8/20/2025 12:29 PM, Richard Heathfield wrote:
On 20/08/2025 18:20, olcott wrote:
On 8/20/2025 12:18 PM, Richard Heathfield wrote:
On 20/08/2025 18:13, olcott wrote:
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
<snip>
#define HHH(x) 0
Moronically counter-factual.
Which bit?
It looks exactly right to me. It yields 0, which is the
only important bit.
It skips the required inference steps,
And yours skips the Turing tail in DD. If you're allowed to
skip stuff, so are other people.
Besides which, we may take as read that you've done all that
inference stuff in a previous run - use one of your magic
statics - and written it down if it really matters (which I
doubt, because it ends up with the wrong answer).
The key part of HHH is that it yields 0 (which I capture),
just as the key part of DD is the if/forever/return logic,
which you singularly fail to capture.
thus is not
any sort of reasoning at all.
And your skipping DD's tail is thus not any sort of
simulation at all.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Thus HHH(Infinite_Loop) would reach the "return"
statement final halt state of Infinite_Loop()
according to your lying ways.
Who cares?
That I just proved that you lied about HHH(DD)?
On 8/20/2025 12:24 PM, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the >>>> analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ >>>> input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input. >>>>
To cut a long story short, it turns out that his decider /does/
decide the
one input he needs, but it decides incorrectly, saying that it never
halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly >>>> returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO >>> has been quite clear that 0 is the correct return value. When asked he >>> said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a
while now! All his current posting amounts to PO trying to justify /
why/ the obviously wrong answer is /really/ correct. It's all
nonsense of course.
Mike.
Here is it 89 years later and even when
specifically told that:
Turing machine deciders only compute the mapping
from their inputs...
And it is self-evident that the caller of HHH(DD)
cannot possibly be its input
with another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
I don't believe that's PO's intention, or even a good way of looking at things. This is just a
On 2025-08-20, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 9:59 PM, Kaz Kylheku wrote:
On 2025-08-20, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
Contrary to your repeatedly stated belief, The Halting Theorem doesn't >>>>> say that there exist test cases whose halting is indeterminate such that >>>>> they cannot be decided by /any/ decider.
The halting problem proofs depend on the assumption
that there is an H/D pair such that D is undecidable by H.
Not quite. That should be "such that D is is either /incorrectly/
decided by H, or else H does not terminate".
OK that seems to make sense.
"Undecidable" is the situation of not having an algorithm (computational >>> function) to calculate some abstract Boolean math function.
Its a little more concrete when we add a model of computation.
The model is Turing computation. The domain is all Turing computations
and there is an abstract funtion which assigns absolutely all of them
a termination value.
The question is, can some of these Turing computations calculate
that function in its entirety (the whole domain?)
For a Turing computation to do that, it has to calculate its own
halting.
Not just one instance, but an infinite variety. It has to
calculate its own halting when it is applied to itself calculating the halting of something else.
In turn, it has to be able to calculate the
halting of /that/ and so on. Everything imaginable, both involving
itself and not involving itself, in any number of nestings.
H has some algorithm. D is chosen to make the algorithm come up
with the wrong answer, or else not to halt.
Turing machine deciders only compute the mapping
from their inputs...
That's nice; but you have to drop the plural and work with
one decideer.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*From the bottom of page 319 has been adapted to this*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
I don't think you understand Linz. In any case, he doesn't
talk about using two different deciders, with an embedded H
being different from the master H.
Linz also makes it clear that halting is undecidable,
right there in that text.
If you think he is wrong (he wrote a chapter claiming that halting
is undecidable when obviously to you it is) he must be another idiot.
Therefore, stop referencing his text in support of your claims!!!
I have gone over the HP many times.
Mensa scored me in the top 3%.
I was in the top 20% of my BSCS classes.
Yet somehow you think that you can use the result from one decider to hand-wave away the nontermination of another one.
(You've repeatedly claimed that halting claims that D is undecidable, and >>> that that is obviously and pathologically wrong.)
The proofs claim that: D is undecidable by H.
No competent presentation of the proof uses the word
undecidable for the situation between D and H, that
D is incorrectly decided by H.
All that is undecidable is the universal halting of
a Turing machine, by a Turing machine.
When I show how D is correctly decided by H these proofs fail.
When you show how D is correctly decided by H, you are equivocating
between two definitions of H that are active simultaneously.
Not exactly. The x86utm operating system does
cooperative multi-tasking.
By active simultaneously I mean that the two are activated.
There is a outer one which starts the simulation, and remains
activated while the inner one executes.
HHH executes then HHH simulates DD that calls HHH(DD)^^^^^^
then and HHH simulates this instance of itself simulating
Wrong! Your "itself" pronoun is doing a lot of work here,
and it is wrong.
The top-level HHH invocation simulates an instance of D
containing an embedded HHH.
They are different deciders rolled into one C procedure.
HHH examines a non-local fuse variable. Seeing that
the fuse is unburned, it proceeds to behave like the toplevel
decider (and also burns the fuse). When HHH_embedded sees the burned
fuse value and behaves like the embedded decider.
Mr 3% Mensa rolled two halting deciders into one C function,
distinguished by a nonlocal, mutating piece of data.
I agree with everything that you say about your system, in
regard to what it does. Correctly simulates and all that.
The two-decider situation is the problem; it produces
a result that is unsurprising.
Nothing in the Halting Theorem prevents HHH(toplevel)
from being able to see that the simulation of DD which
calls HHH(embedded) is nonterminating.
You are not contradicting anything.
Here is how one C procedure can encode two functions
under the same name:
int mystery_op(int arg)
{
static op;
op != op;
if (op)
return putchar(arg);
else
return getchar();
}
The mystery_op function alternates between being getchar
and putchar. It is one procedure, but two functions.
We can factor out the static flag and make it an
argument. We can enumerate the states and give then
names:
#define OP_GETCHAR 0
#define OP_PUTCHAR 1
int mystery_op(int flag, int arg)
{
if (flag)
return putchar(arg);
else
return getchar();
}
Now we can call mystery_op(OP_GETCHAR, 0) to
select getchar() and mystery_op(OP_PUTCHAR, 'x')
to call putchar(x).
In Unix, the ioctl() procedure combines a large number
of procedures under one name.
Your HHH isn't a decider; it is a decider-dispatcher.
There is no self-reference.
HHH is deciding on the behavior of:
DD simulated by HHH that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Even if it were true that there is only one HHH,
which it isn't, it is not self-reference.
Operating on a copy of yourself isn't self-reference.
HHH just needs the sequential list of every DD insruction
that is simulated at any level stored in execution_trace.
That's all great, but HHH isn't the same HHH as the one
called by D, and so all that work deosn't put a dent in
the Halting Theorem.
Every C programmer knows that HHH(DD) cannot see its
own caller thus has no idea if its caller is DD or main.
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:Ĥ.embedded_H ⟨Ĥ⟩
On 2025-08-20, olcott <polcott333@gmail.com> wrote:More concretely every sequence of steps of a Turing machine either
On 8/19/2025 9:59 PM, Kaz Kylheku wrote:
On 2025-08-20, olcott <polcott333@gmail.com> wrote:OK that seems to make sense.
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
Contrary to your repeatedly stated belief, The Halting TheoremThe halting problem proofs depend on the assumption that there is an >>>>> H/D pair such that D is undecidable by H.
doesn't say that there exist test cases whose halting is
indeterminate such that they cannot be decided by /any/ decider.
Not quite. That should be "such that D is is either /incorrectly/
decided by H, or else H does not terminate".
"Undecidable" is the situation of not having an algorithmIts a little more concrete when we add a model of computation.
(computational function) to calculate some abstract Boolean math
function.
The model is Turing computation. The domain is all Turing computations
and there is an abstract funtion which assigns absolutely all of them a
termination value.
reaches a final halt state or fails to reach a final halt state.
The question is, can some of these Turing computations calculate thatWhen we are careful to make sure to keep this in mind:
function in its entirety (the whole domain?)
Turing machine deciders only compute the mapping from their inputs...
The the mistake of believing that one TM can directly report on the
behavior of its own caller is never made.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, Ĥ.q0 ⟨Ĥ⟩ ⊢*
⟨Ĥ⟩ ⊢* Ĥ.qn
Linz incorrectly requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
to report on the behavior of its caller/itself.
All the proofs make this same mistake.
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus has
no idea if its caller is DD or main.
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
So HHH is broken.
On 20/08/2025 08:37, Chris M. Thomasson wrote:
On 8/19/2025 6:20 PM, Richard Heathfield wrote:
On 20/08/2025 02:00, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
<snip>
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
If HHH(DD) doens't have that value, it's just wrong.
Exercise for the discerning student: come up with a return value for
HHH(DD) that /isn't/ "just wrong".
Flip a coin and say mostly wrong?
Is that your best crack at "discerning"?
Try and reason it out.
On 8/20/2025 12:44 AM, Richard Heathfield wrote:
On 20/08/2025 08:37, Chris M. Thomasson wrote:
On 8/19/2025 6:20 PM, Richard Heathfield wrote:
On 20/08/2025 02:00, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
<snip>
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
If HHH(DD) doens't have that value, it's just wrong.
Exercise for the discerning student: come up with a return value for
HHH(DD) that /isn't/ "just wrong".
Flip a coin and say mostly wrong?
Is that your best crack at "discerning"?
Try and reason it out.
Humm... Perhaps examine the source code passed into the decider as an
input. We look at said code and use a LLM or something to see if it can detect any run away recursions, or infinite loops from that state alone. Then it can compile the code and run it many times, the original as a control, and other "versions" (cheating by altering the source code) to
try to understand aspects about the source code passed into the decider
and how it runs. It might say it calls into some sort of known TRNG API,
so we cannot know if it halts or not. 50% halt, 50% non-halt. We have
not studied the source code good enough (at this time) to determine if
the TRNG results are being used in some sort of "probability" in the
target program or not...
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it is only concerned with what is passed to it as an input which *just happens to be* its caller (well, a description thereof).
/Flibble
On Wed, 20 Aug 2025 13:20:28 -0500, olcott wrote:
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:Ĥ.embedded_H ⟨Ĥ⟩
On 2025-08-20, olcott <polcott333@gmail.com> wrote:More concretely every sequence of steps of a Turing machine either
On 8/19/2025 9:59 PM, Kaz Kylheku wrote:
On 2025-08-20, olcott <polcott333@gmail.com> wrote:OK that seems to make sense.
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
Contrary to your repeatedly stated belief, The Halting TheoremThe halting problem proofs depend on the assumption that there is an >>>>>> H/D pair such that D is undecidable by H.
doesn't say that there exist test cases whose halting is
indeterminate such that they cannot be decided by /any/ decider. >>>>>>>
Not quite. That should be "such that D is is either /incorrectly/
decided by H, or else H does not terminate".
"Undecidable" is the situation of not having an algorithmIts a little more concrete when we add a model of computation.
(computational function) to calculate some abstract Boolean math
function.
The model is Turing computation. The domain is all Turing computations
and there is an abstract funtion which assigns absolutely all of them a
termination value.
reaches a final halt state or fails to reach a final halt state.
The question is, can some of these Turing computations calculate thatWhen we are careful to make sure to keep this in mind:
function in its entirety (the whole domain?)
Turing machine deciders only compute the mapping from their inputs...
The the mistake of believing that one TM can directly report on the
behavior of its own caller is never made.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, Ĥ.q0 ⟨Ĥ⟩ ⊢*
⟨Ĥ⟩ ⊢* Ĥ.qn
Linz incorrectly requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
to report on the behavior of its caller/itself.
All the proofs make this same mistake.
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus has
no idea if its caller is DD or main.
Nobody is suggesting that HHH(DD) can see its caller however we are
passing a *description* of DD to HHH and HHH needs to return a decision to its caller, DD.
/Flibble
On 20/08/2025 18:05, Kaz Kylheku wrote:
On 2025-08-20, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
It is utterly unsurprising that it can obtain a correct answer;^^^^^^^
that doesn't contradict anything int the Halting Theorem.
Correction, "unsigned int the Halting Theorem". Sorry about that.
You're slipping. Should be "size_t the Halting Theorem".
On 8/20/2025 12:44 AM, Richard Heathfield wrote:
On 20/08/2025 08:37, Chris M. Thomasson wrote:
On 8/19/2025 6:20 PM, Richard Heathfield wrote:
On 20/08/2025 02:00, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
<snip>
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
If HHH(DD) doens't have that value, it's just wrong.
Exercise for the discerning student: come up with a return value for
HHH(DD) that /isn't/ "just wrong".
Flip a coin and say mostly wrong?
Is that your best crack at "discerning"?
Try and reason it out.
Humm... Perhaps examine the source code passed into the decider as an
input. We look at said code and use a LLM or something to see if it can detect any run away recursions, or infinite loops from that state alone.
Then it can compile the code and run it many times, the original as a control, and other "versions" (cheating by altering the source code) to--
try to understand aspects about the source code passed into the decider
and how it runs. It might say it calls into some sort of known TRNG API,
so we cannot know if it halts or not. 50% halt, 50% non-halt. We have
not studied the source code good enough (at this time) to determine if
the TRNG results are being used in some sort of "probability" in the
target program or not...
On 8/20/2025 12:18 PM, Richard Heathfield wrote:
On 20/08/2025 18:13, olcott wrote:
On 8/20/2025 11:44 AM, Richard Heathfield wrote:
<snip>
#define HHH(x) 0
Moronically counter-factual.
Which bit?
It looks exactly right to me. It yields 0, which is the only important
bit.
It skips the required inference steps, thus is not
any sort of reasoning at all.
On 2025-08-20, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 8:00 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
I envisioned my way of doing it as analogous to a UTM
setting aside a portion of its own tape for its slave
UTMs to use as their own tape.
But that's not a useful analogy because whereas Turing Machines have
only the tape and nothing but the tape for storage, in the C programs
you have multiple kinds of storage. All those storage types and areas
are analogous to the tape. It's not just rows of instructions that are analogous to the tape. This direction of thinking is nonproductive.
I envision HHH as a UTM with extra features.
Deducing what its return value should be on the basis
of the actual behavior of DD correctly simulated by
HHH is proven to be correctly 0.
Sure, but, again, HHH is a different decider. It is not that
decider that was shown being necessarily wrong by DD.
If HHH(DD) doens't have that value, it's just wrong.
Not exactly. The static analysis of the C code does
prove that HHH(DD) returning 0 would be correct.
What "static analysis", carried out by whom?
Linz shows such a machine that is simulating its
own machine description by his definition of his
Ĥ template. Ĥ applied to ⟨Ĥ⟩ does remain stuck in
recursive simulation unless Ĥ.embedded_H aborts
this simulation.
Linz assumes that the machines are identical;
you wrecked that and therefore you are not refuting
Linz's reasoning which remains rooted in his
assumptions and not yours.
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the >> one input he needs, but it decides incorrectly, saying that it never halts >> when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
On 8/20/2025 4:10 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns >>> 0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ >>> input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/
decide the
one input he needs, but it decides incorrectly, saying that it never
halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly >>> returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
It might mean that olcott is a hyper finitist that simply cannot
conceive of an infinite process, therefore he assumes that they all must halt?
On 8/20/2025 3:22 PM, Chris M. Thomasson wrote:
On 8/20/2025 4:10 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the >>>> analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ >>>> input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input. >>>>
To cut a long story short, it turns out that his decider /does/
decide the
one input he needs, but it decides incorrectly, saying that it never
halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly >>>> returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO >>> has been quite clear that 0 is the correct return value. When asked he >>> said:
"Yes that is the correct answer even though P(P) halts."
It might mean that olcott is a hyper finitist that simply cannot
conceive of an infinite process, therefore he assumes that they all
must halt?
You misunderstood Ben.
On 8/20/2025 1:28 PM, olcott wrote:
On 8/20/2025 3:22 PM, Chris M. Thomasson wrote:
On 8/20/2025 4:10 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or >>>>> one of his so-called "non-termination" patterns occurs in the >>>>> analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues >>>>> indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand >>>>> this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ >>>>> input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input. >>>>>
To cut a long story short, it turns out that his decider /does/
decide the
one input he needs, but it decides incorrectly, saying that it
never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being >>>>> simulated halts. So his decider aborts the simulation and
incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing
piece. PO
has been quite clear that 0 is the correct return value. When asked he >>>> said:
"Yes that is the correct answer even though P(P) halts."
It might mean that olcott is a hyper finitist that simply cannot
conceive of an infinite process, therefore he assumes that they all
must halt?
You misunderstood Ben.
How did I misunderstand him?
On 8/20/2025 3:32 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:28 PM, olcott wrote:
On 8/20/2025 3:22 PM, Chris M. Thomasson wrote:
On 8/20/2025 4:10 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or >>>>>> one of his so-called "non-termination" patterns occurs in the >>>>>> analysis of the simulation. If that happens, the decider >>>>>> returns
0 [does not halt].
If the simulation never halts and never matches one of his >>>>>> so-called non-termination pattern, the simulation continues >>>>>> indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider, >>>>>> which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand >>>>>> this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ >>>>>> input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input. >>>>>>
To cut a long story short, it turns out that his decider /does/
decide the
one input he needs, but it decides incorrectly, saying that it
never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being >>>>>> simulated halts. So his decider aborts the simulation and
incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing
piece. PO
has been quite clear that 0 is the correct return value. When
asked he
said:
"Yes that is the correct answer even though P(P) halts."
It might mean that olcott is a hyper finitist that simply cannot
conceive of an infinite process, therefore he assumes that they all
must halt?
You misunderstood Ben.
How did I misunderstand him?
Since you have sufficiently proven that you don't
care about the truth I don't care how you misunderstood
him.
On 8/20/2025 1:44 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it is only
concerned with what is passed to it as an input which *just happens to
be*
its caller (well, a description thereof).
/Flibble
That merely proves that you are not an expert programmer.
On Wed, 20 Aug 2025 14:47:20 -0500, olcott wrote:
On 8/20/2025 1:44 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller thus >>>>> has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it is only
concerned with what is passed to it as an input which *just happens to
be*
its caller (well, a description thereof).
/Flibble
That merely proves that you are not an expert programmer.
If that were true you could point out the error in what I said (hint: you can't because I made no error, unlike yourself).
/Flibble
On 8/20/2025 4:19 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 14:47:20 -0500, olcott wrote:
On 8/20/2025 1:44 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller
thus has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it is
only concerned with what is passed to it as an input which *just
happens to be*
its caller (well, a description thereof).
/Flibble
That merely proves that you are not an expert programmer.
If that were true you could point out the error in what I said (hint:
you can't because I made no error, unlike yourself).
/Flibble
You corrected yourself on the next post that I replied to.
On 2025-08-20, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
The if statement testing the valueo of *execution_trace, together
with another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
I don't believe that's PO's intention, or even a good way of looking at things. This is just a
PO keeps talking about HHH simulating "itself", so it's like he doesn't realize that the deciders are not the same.
This isn't stupidity; it's more like a mental illness.
Believing that the inner HHH is the same as outer is probably in a
similar category to believing that some living person (e.g. oneself) is Jesus.
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or one of his so-called "non-termination" patterns occurs in the analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his so-called non-termination pattern, the simulation continues indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider, which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ input - he does not claim to have a Halt Decider, just a /partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called "non-termination pattern" matches, even though the computation being simulated halts. So his decider aborts the simulation and incorrectly returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO has been quite clear that 0 is the correct return value. When asked he said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now! All his currentThen, the next question is why people like to jump into the nonsense (POO simulation)?
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/ correct. It's
all nonsense of course.
Mike.
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or >>>> one of his so-called "non-termination" patterns occurs in the >>>> analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/ >>>> input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input. >>>>
To cut a long story short, it turns out that his decider /does/ decide the >>>> one input he needs, but it decides incorrectly, saying that it never halts >>>> when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly >>>> returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO >>> has been quite clear that 0 is the correct return value. When asked he >>> said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/ correct. It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
I don't think that is the shell game. PO really /has/ an H--
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: the case the Linz HP proof constructs for a given decider, which "does the opposite of what the decider decides". [If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.] So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a /partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called "non-termination pattern" matches, even though the computation being simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctlyEverbody? now knows that you cannot square a circle. But, now if I change the idea, sentence to:
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or >>>>>> one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his >>>>>> so-called non-termination pattern, the simulation continues >>>>>> indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider, >>>>>> which "does the opposite of what the decider decides". >>>>>> [If you're not familiar with the proof you won't understand >>>>>> this bit, but it would take too long to explain here.] >>>>>> So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a >>>>>> /partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being >>>>>> simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO >>>>> has been quite clear that 0 is the correct return value. When asked he >>>>> said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
; I don't think that is the shell game. PO really /has/ an H
; (it's trivial to do for this one case) that correctly determines
; that P(P) *would* never stop running *unless* aborted.
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called "non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now! All his
current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/
correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report theIf you claim HHH is such a halt decider (defined by HP), then DD is a valid input (by adding simple instructions):
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
They keep saying that I am wrong entirely--- Synchronet 3.21a-Linux NewsLink 1.2
on the basis of their own failure to pay attention.
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider
returns
0 [does not halt].
If the simulation never halts and never matches one of his >>>>>>> so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider, >>>>>>> which "does the opposite of what the decider decides". >>>>>>> [If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.] >>>>>>> So it makes no difference that his decider can't decide / >>>>>>> every/
input - he does not claim to have a Halt Decider, just a >>>>>>> /partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ >>>>>>> decide the
one input he needs, but it decides incorrectly, saying that it
never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being >>>>>>> simulated halts. So his decider aborts the simulation and
incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing
piece. PO
has been quite clear that 0 is the correct return value. When
asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite
a while now! All his current
posting amounts to PO trying to justify /why/ the obviously wrong
answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense
(POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I
change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
On Wed, 2025-08-20 at 18:56 -0500, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>> the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides". >>>>>>>> [If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.] >>>>>>>> So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a >>>>>>>> /partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being >>>>>>>> simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>
Right - it's been clear that PO really does believe that for quite a while now! All his
current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/
correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines >>>> > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
If you claim HHH is such a halt decider (defined by HP), then DD is a valid input (by adding simple instructions):
void DD() {
if(HHH(DD)) while(1);
}
Do you claim DD is not a valid input, or HHH is not a valid decider?
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in
the
analysis of the simulation. If that happens, the decider
returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>> the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides". >>>>>>>> [If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.] >>>>>>>> So it makes no difference that his decider can't decide /
every/
input - he does not claim to have a Halt Decider, just a >>>>>>>> /partial/ halt decider that correctly decides that one >>>>>>>> input.
To cut a long story short, it turns out that his decider /does/ >>>>>>>> decide the
one input he needs, but it decides incorrectly, saying that it >>>>>>>> never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation >>>>>>>> being
simulated halts. So his decider aborts the simulation and >>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing
piece. PO
has been quite clear that 0 is the correct return value. When >>>>>>> asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>
Right - it's been clear that PO really does believe that for quite >>>>>> a while now! All his current
posting amounts to PO trying to justify /why/ the obviously wrong >>>>>> answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the
nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I
change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines >>>> > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally >>>>>>>>> halts, or
one of his so-called "non-termination" patterns occurs >>>>>>>>> in the
analysis of the simulation. If that happens, the >>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>> the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides". >>>>>>>>> [If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.] >>>>>>>>> So it makes no difference that his decider can't >>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, just a >>>>>>>>> /partial/ halt decider that correctly decides that one >>>>>>>>> input.
To cut a long story short, it turns out that his decider /does/ >>>>>>>>> decide the
one input he needs, but it decides incorrectly, saying that it >>>>>>>>> never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>> "non-termination pattern" matches, even though the computation >>>>>>>>> being
simulated halts. So his decider aborts the simulation and >>>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing >>>>>>>> piece. PO
has been quite clear that 0 is the correct return value. When >>>>>>>> asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>
Right - it's been clear that PO really does believe that for
quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously wrong >>>>>>> answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the
nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I
change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise." >>>>
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines >>>>> > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
No input exists because a total halt decider does not exist. The
assumption that a total halt decider exists is what allows the creation
of a Turing machine, and therefore a finite string description of that
machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing was
right."
On 8/20/2025 7:04 PM, wij wrote:
On Wed, 2025-08-20 at 18:56 -0500, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called "non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now! All his
current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/
correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H > (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
If you claim HHH is such a halt decider (defined by HP), then DD is a valid input (by adding simple instructions):
void DD() {
if(HHH(DD)) while(1);
}
Do you claim DD is not a valid input, or HHH is not a valid decider?
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
The DD that is calling HHH(DD) is not its input.DD just adds several additional instructions to HHH.
No C function or Turing machine can have its actualYou need to make the statement more clearly/precisely (otherwise, meaningless). --- Synchronet 3.21a-Linux NewsLink 1.2
self as its input.
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>> He simulates until either the simulation naturally >>>>>>>>>> halts, or
one of his so-called "non-termination" patterns occurs >>>>>>>>>> in the
analysis of the simulation. If that happens, the >>>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation >>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>> the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides". >>>>>>>>>> [If you're not familiar with the proof you won't >>>>>>>>>> understand
this bit, but it would take too long to explain here.] >>>>>>>>>> So it makes no difference that his decider can't >>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one >>>>>>>>>> input.
To cut a long story short, it turns out that his decider / >>>>>>>>>> does/ decide the
one input he needs, but it decides incorrectly, saying that it >>>>>>>>>> never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>> "non-termination pattern" matches, even though the computation >>>>>>>>>> being
simulated halts. So his decider aborts the simulation and >>>>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing >>>>>>>>> piece. PO
has been quite clear that 0 is the correct return value. When >>>>>>>>> asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>
Right - it's been clear that PO really does believe that for
quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously
wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the
nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I
change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise." >>>>>
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines >>>>>> > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is written
below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by contradiction
over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The
assumption that a total halt decider exists is what allows the
creation of a Turing machine, and therefore a finite string
description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing
was right."
On Wed, 2025-08-20 at 19:34 -0500, olcott wrote:
On 8/20/2025 7:04 PM, wij wrote:
On Wed, 2025-08-20 at 18:56 -0500, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>> He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>> the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>> "non-termination pattern" matches, even though the computation being >>>>>>>>>> simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>
Right - it's been clear that PO really does believe that for quite a while now! All his
current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/
correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise." >>>>>
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>> > (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
If you claim HHH is such a halt decider (defined by HP), then DD is a valid >>> input (by adding simple instructions):
void DD() {
if(HHH(DD)) while(1);
}
Do you claim DD is not a valid input, or HHH is not a valid decider?
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
The DD that is calling HHH(DD) is not its input.
DD just adds several additional instructions to HHH.
Maybe you are talking some non-TM systems which does not allow it
No C function or Turing machine can have its actual
self as its input.
You need to make the statement more clearly/precisely (otherwise, meaningless).
On 8/20/2025 1:44 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own
caller thus
has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it
is only
concerned with what is passed to it as an input which *just
happens to be*
its caller (well, a description thereof).
/Flibble
That merely proves that you are not an expert programmer.
On 8/20/2025 8:07 PM, wij wrote:
On Wed, 2025-08-20 at 19:34 -0500, olcott wrote:
On 8/20/2025 7:04 PM, wij wrote:
On Wed, 2025-08-20 at 18:56 -0500, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now! All
his
current
posting amounts to PO trying to justify /why/ the obviously wrong answer is /really/
correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem. Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
If you claim HHH is such a halt decider (defined by HP), then DD is a valid
input (by adding simple instructions):
void DD() {
if(HHH(DD)) while(1);
}
Do you claim DD is not a valid input, or HHH is not a valid decider?
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
The DD that is calling HHH(DD) is not its input.
DD just adds several additional instructions to HHH.
Maybe you are talking some non-TM systems which does not allow it
No C function or Turing machine can have its actual
self as its input.
You need to make the statement more clearly/precisely (otherwise, meaningless).
Every first year CS student knows thatYou need to make the statement more clearly/precisely (otherwise, meaningless). --- Synchronet 3.21a-Linux NewsLink 1.2
the caller of a function cannot possibly
be an input to this same called function.
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>> He simulates until either the simulation naturally >>>>>>>>>>> halts, or
one of his so-called "non-termination" patterns occurs
in the
analysis of the simulation. If that happens, the >>>>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one of
his
so-called non-termination pattern, the simulation >>>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>>> the case the Linz HP proof constructs for a given >>>>>>>>>>> decider,
which "does the opposite of what the decider decides". >>>>>>>>>>> [If you're not familiar with the proof you won't >>>>>>>>>>> understand
this bit, but it would take too long to explain here.] >>>>>>>>>>> So it makes no difference that his decider can't >>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one
input.
To cut a long story short, it turns out that his decider / >>>>>>>>>>> does/ decide the
one input he needs, but it decides incorrectly, saying that >>>>>>>>>>> it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>>> "non-termination pattern" matches, even though the
computation being
simulated halts. So his decider aborts the simulation and >>>>>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing >>>>>>>>>> piece. PO
has been quite clear that 0 is the correct return value. When >>>>>>>>>> asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>>
Right - it's been clear that PO really does believe that for >>>>>>>>> quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously >>>>>>>>> wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the
nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I >>>>>> change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves
otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>> > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is written
below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The
assumption that a total halt decider exists is what allows the
creation of a Turing machine, and therefore a finite string
description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing
was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
then it becomes
dead obvious that
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally
halts, or
one of his so-called "non-termination" patterns occurs
in the
analysis of the simulation. If that happens, the
decider returns
0 [does not halt].
If the simulation never halts and never matches one of
his
so-called non-termination pattern, the simulation
continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given
decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't
understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't
decide / every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one
input.
To cut a long story short, it turns out that his decider /
does/ decide the
one input he needs, but it decides incorrectly, saying that
it never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and
incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing
piece. PO
has been quite clear that 0 is the correct return value. When
asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for
quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously
wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I
change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem. Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The assumption that a total halt decider exists is what allows the creation of a Turing machine, and therefore a finite string description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
So, I think the whole story is that since olcott thinks he can see the HP is undecidable, therefore he thus decides the HP is decidable,... then the long journeythen it becomes
dead obvious that
No total halt decider exists.
So you're saying the proof is wrong because what it proves is right.
Error: assuming the conclusion.
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>> He simulates until either the simulation naturally >>>>>>>>>>>> halts, or
one of his so-called "non-termination" patterns >>>>>>>>>>>> occurs in the
analysis of the simulation. If that happens, the >>>>>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one >>>>>>>>>>>> of his
so-called non-termination pattern, the simulation >>>>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>>>> the case the Linz HP proof constructs for a given >>>>>>>>>>>> decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't >>>>>>>>>>>> understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't >>>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that >>>>>>>>>>>> one input.
To cut a long story short, it turns out that his decider / >>>>>>>>>>>> does/ decide the
one input he needs, but it decides incorrectly, saying that >>>>>>>>>>>> it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>>>> "non-termination pattern" matches, even though the
computation being
simulated halts. So his decider aborts the simulation and >>>>>>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing >>>>>>>>>>> piece. PO
has been quite clear that 0 is the correct return value. >>>>>>>>>>> When asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>>>
Right - it's been clear that PO really does believe that for >>>>>>>>>> quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously >>>>>>>>>> wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the >>>>>>>>> nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if >>>>>>> I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves
otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>>> > (it's trivial to do for this one case) that correctly
determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is written
below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The
assumption that a total halt decider exists is what allows the
creation of a Turing machine, and therefore a finite string
description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing
was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
On 20/08/2025 20:47, olcott wrote:HHH uses cooperative multi-tasking to switch between
On 8/20/2025 1:44 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller thus >>>>> has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it is only
concerned with what is passed to it as an input which *just happens
to be*
its caller (well, a description thereof).
/Flibble
That merely proves that you are not an expert programmer.
No, it doesn't. It only proves he missed my point, which you do all the time. He apparently thinks (as I do not) that HHH doesn't need to
simulate what happens in DD after the HHH call.
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>> He simulates until either the simulation naturally >>>>>>>>>>>>> halts, or
one of his so-called "non-termination" patterns >>>>>>>>>>>>> occurs in the
analysis of the simulation. If that happens, the >>>>>>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one >>>>>>>>>>>>> of his
so-called non-termination pattern, the simulation >>>>>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>>>>> the case the Linz HP proof constructs for a given >>>>>>>>>>>>> decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't >>>>>>>>>>>>> understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't >>>>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, >>>>>>>>>>>>> just a
/partial/ halt decider that correctly decides that >>>>>>>>>>>>> one input.
To cut a long story short, it turns out that his decider / >>>>>>>>>>>>> does/ decide the
one input he needs, but it decides incorrectly, saying that >>>>>>>>>>>>> it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>>>>> "non-termination pattern" matches, even though the
computation being
simulated halts. So his decider aborts the simulation and >>>>>>>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return value. >>>>>>>>>>>> When asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>>>>
Right - it's been clear that PO really does believe that for >>>>>>>>>>> quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously >>>>>>>>>>> wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the >>>>>>>>>> nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if >>>>>>>> I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves
otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>>>> > (it's trivial to do for this one case) that correctly >>>>>>>>> determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is
written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The >>>>>> assumption that a total halt decider exists is what allows the
creation of a Turing machine, and therefore a finite string
description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing >>>>>> was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
Dishonestly saying that HHH emulates zero
instructions of DD proves that you don't tell
the truth.
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
On Wed, 2025-08-20 at 20:25 -0500, olcott wrote:
On 8/20/2025 8:07 PM, wij wrote:
On Wed, 2025-08-20 at 19:34 -0500, olcott wrote:
On 8/20/2025 7:04 PM, wij wrote:
On Wed, 2025-08-20 at 18:56 -0500, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now!
All
his
current
posting amounts to PO trying to justify /why/ the obviously wrong answer is
/really/
correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO
simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem. Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
If you claim HHH is such a halt decider (defined by HP), then DD is a valid
input (by adding simple instructions):
void DD() {
if(HHH(DD)) while(1);
}
Do you claim DD is not a valid input, or HHH is not a valid decider?
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
The DD that is calling HHH(DD) is not its input.
DD just adds several additional instructions to HHH.
Maybe you are talking some non-TM systems which does not allow it
No C function or Turing machine can have its actual
self as its input.
You need to make the statement more clearly/precisely (otherwise, meaningless).
What? You don't know what you said?Every first year CS student knows that
the caller of a function cannot possibly
be an input to this same called function.
You need to make the statement more clearly/precisely (otherwise, meaningless).
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>>> He simulates until either the simulation naturally >>>>>>>>>>>>>> halts, or
one of his so-called "non-termination" patterns >>>>>>>>>>>>>> occurs in the
analysis of the simulation. If that happens, the >>>>>>>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one
of his
so-called non-termination pattern, the simulation >>>>>>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input >>>>>>>>>>>>>> case:
the case the Linz HP proof constructs for a given >>>>>>>>>>>>>> decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't >>>>>>>>>>>>>> understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't >>>>>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, >>>>>>>>>>>>>> just a
/partial/ halt decider that correctly decides that >>>>>>>>>>>>>> one input.
To cut a long story short, it turns out that his decider / >>>>>>>>>>>>>> does/ decide the
one input he needs, but it decides incorrectly, saying >>>>>>>>>>>>>> that it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>>>>>> "non-termination pattern" matches, even though the >>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the simulation >>>>>>>>>>>>>> and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return value. >>>>>>>>>>>>> When asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>>>>>
Right - it's been clear that PO really does believe that for >>>>>>>>>>>> quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously >>>>>>>>>>>> wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the >>>>>>>>>>> nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now >>>>>>>>> if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves
otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>>>>> > (it's trivial to do for this one case) that correctly >>>>>>>>>> determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is
written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The >>>>>>> assumption that a total halt decider exists is what allows the
creation of a Turing machine, and therefore a finite string
description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because
Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a total
halt decider exists, it can be shown through a series of truth
preserving operations that the "impossible input" can be created.
Dishonestly saying that HHH emulates zero
instructions of DD proves that you don't tell
the truth.
You are proven to be the dishonest one by making the above false claim.
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
On Thu, 2025-08-21 at 09:33 +0800, wij wrote:
On Wed, 2025-08-20 at 20:25 -0500, olcott wrote:
On 8/20/2025 8:07 PM, wij wrote:
On Wed, 2025-08-20 at 19:34 -0500, olcott wrote:
On 8/20/2025 7:04 PM, wij wrote:
On Wed, 2025-08-20 at 18:56 -0500, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>> He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>>>>> the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the
one input he needs, but it decides incorrectly, saying that it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>>>>> "non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for quite a while now!
All
his
current
posting amounts to PO trying to justify /why/ the obviously wrong answer is
/really/
correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the nonsense (POO
simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise." >>>>>>>>
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>>>> > (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
If you claim HHH is such a halt decider (defined by HP), then DD is a valid
input (by adding simple instructions):
void DD() {
if(HHH(DD)) while(1);
}
Do you claim DD is not a valid input, or HHH is not a valid decider? >>>>>>
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
The DD that is calling HHH(DD) is not its input.
DD just adds several additional instructions to HHH.
Maybe you are talking some non-TM systems which does not allow it
No C function or Turing machine can have its actual
self as its input.
You need to make the statement more clearly/precisely (otherwise, meaningless).
Every first year CS student knows that
the caller of a function cannot possibly
be an input to this same called function.
You need to make the statement more clearly/precisely (otherwise, meaningless).
What? You don't know what you said?
On 8/20/2025 8:57 PM, dbush wrote:
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>>>> He simulates until either the simulation naturally
halts, or
one of his so-called "non-termination" patterns >>>>>>>>>>>>>>> occurs in the
analysis of the simulation. If that happens, the
decider returns
0 [does not halt].
If the simulation never halts and never matches >>>>>>>>>>>>>>> one of his
so-called non-termination pattern, the simulation >>>>>>>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input >>>>>>>>>>>>>>> case:
the case the Linz HP proof constructs for a given >>>>>>>>>>>>>>> decider,
which "does the opposite of what the decider >>>>>>>>>>>>>>> decides".
[If you're not familiar with the proof you won't >>>>>>>>>>>>>>> understand
this bit, but it would take too long to explain >>>>>>>>>>>>>>> here.]
So it makes no difference that his decider can't >>>>>>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, >>>>>>>>>>>>>>> just a
/partial/ halt decider that correctly decides that
one input.
To cut a long story short, it turns out that his >>>>>>>>>>>>>>> decider / does/ decide the
one input he needs, but it decides incorrectly, saying >>>>>>>>>>>>>>> that it never halts
when in fact the input is easily seen to halt. [His so- >>>>>>>>>>>>>>> called
"non-termination pattern" matches, even though the >>>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the simulation >>>>>>>>>>>>>>> and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return value. >>>>>>>>>>>>>> When asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that >>>>>>>>>>>>> for quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously >>>>>>>>>>>>> wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the >>>>>>>>>>>> nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now >>>>>>>>>> if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves >>>>>>>>>> otherwise."
This pattern of argument applies to every existing theorem. >>>>>>>>>> Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>>>>>> > (it's trivial to do for this one case) that correctly >>>>>>>>>>> determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is
written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. >>>>>>>> The assumption that a total halt decider exists is what allows >>>>>>>> the creation of a Turing machine, and therefore a finite string >>>>>>>> description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because
Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a total
halt decider exists, it can be shown through a series of truth
preserving operations that the "impossible input" can be created.
Yes and it has been 89 years and no one besides me
ever noticed that this *input* was never an actual
*input*.
For 89 years everyone conflated a directly executed
Turing machine as EXACTLY the same thing as a finite
string machine description.
On 8/20/2025 10:11 PM, olcott wrote:
On 8/20/2025 8:57 PM, dbush wrote:
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:No such input exists therefore the conventional proof
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote: >>>>>>>>>>>>>> On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>> On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>>>>> He simulates until either the simulation >>>>>>>>>>>>>>>> naturally halts, or
one of his so-called "non-termination" patterns >>>>>>>>>>>>>>>> occurs in the
analysis of the simulation. If that happens, the
decider returns
0 [does not halt].
If the simulation never halts and never matches >>>>>>>>>>>>>>>> one of his
so-called non-termination pattern, the simulation
continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input >>>>>>>>>>>>>>>> case:
the case the Linz HP proof constructs for a given
decider,
which "does the opposite of what the decider >>>>>>>>>>>>>>>> decides".
[If you're not familiar with the proof you won't >>>>>>>>>>>>>>>> understand
this bit, but it would take too long to explain >>>>>>>>>>>>>>>> here.]
So it makes no difference that his decider can't >>>>>>>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider,
just a
/partial/ halt decider that correctly decides >>>>>>>>>>>>>>>> that one input.
To cut a long story short, it turns out that his >>>>>>>>>>>>>>>> decider / does/ decide the
one input he needs, but it decides incorrectly, saying >>>>>>>>>>>>>>>> that it never halts
when in fact the input is easily seen to halt. [His so- >>>>>>>>>>>>>>>> called
"non-termination pattern" matches, even though the >>>>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the simulation >>>>>>>>>>>>>>>> and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return value. >>>>>>>>>>>>>>> When asked he
said:
"Yes that is the correct answer even though P(P) >>>>>>>>>>>>>>> halts."
Right - it's been clear that PO really does believe that >>>>>>>>>>>>>> for quite a while now! All his current
posting amounts to PO trying to justify /why/ the >>>>>>>>>>>>>> obviously wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the >>>>>>>>>>>>> nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now >>>>>>>>>>> if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves >>>>>>>>>>> otherwise."
This pattern of argument applies to every existing theorem. >>>>>>>>>>> Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>>>>>>> > (it's trivial to do for this one case) that correctly >>>>>>>>>>>> determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist. >>>>>>>>
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is
written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. >>>>>>>>> The assumption that a total halt decider exists is what allows >>>>>>>>> the creation of a Turing machine, and therefore a finite string >>>>>>>>> description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because >>>>>>>>> Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a total
halt decider exists, it can be shown through a series of truth
preserving operations that the "impossible input" can be created.
Yes and it has been 89 years and no one besides me
ever noticed that this *input* was never an actual
*input*.
For 89 years everyone conflated a directly executed
Turing machine as EXACTLY the same thing as a finite
string machine description.
In other words, you don't understand representations.
On 8/20/2025 9:36 PM, dbush wrote:
On 8/20/2025 10:11 PM, olcott wrote:
On 8/20/2025 8:57 PM, dbush wrote:
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:No such input exists therefore the conventional proof
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote: >>>>>>>>>>>>>>> On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>>> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>>> On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>>>>>> He simulates until either the simulation >>>>>>>>>>>>>>>>> naturally halts, or
one of his so-called "non-termination" patterns >>>>>>>>>>>>>>>>> occurs in the
analysis of the simulation. If that happens, >>>>>>>>>>>>>>>>> the decider returns
0 [does not halt].
If the simulation never halts and never matches >>>>>>>>>>>>>>>>> one of his
so-called non-termination pattern, the >>>>>>>>>>>>>>>>> simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC >>>>>>>>>>>>>>>>> input case:
the case the Linz HP proof constructs for a >>>>>>>>>>>>>>>>> given decider,
which "does the opposite of what the decider >>>>>>>>>>>>>>>>> decides".
[If you're not familiar with the proof you won't
understand
this bit, but it would take too long to explain >>>>>>>>>>>>>>>>> here.]
So it makes no difference that his decider can't
decide / every/
input - he does not claim to have a Halt >>>>>>>>>>>>>>>>> Decider, just a
/partial/ halt decider that correctly decides >>>>>>>>>>>>>>>>> that one input.
To cut a long story short, it turns out that his >>>>>>>>>>>>>>>>> decider / does/ decide the
one input he needs, but it decides incorrectly, saying >>>>>>>>>>>>>>>>> that it never halts
when in fact the input is easily seen to halt. [His so- >>>>>>>>>>>>>>>>> called
"non-termination pattern" matches, even though the >>>>>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the simulation >>>>>>>>>>>>>>>>> and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return value. >>>>>>>>>>>>>>>> When asked he
said:
"Yes that is the correct answer even though P(P) >>>>>>>>>>>>>>>> halts."
Right - it's been clear that PO really does believe that >>>>>>>>>>>>>>> for quite a while now! All his current
posting amounts to PO trying to justify /why/ the >>>>>>>>>>>>>>> obviously wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into >>>>>>>>>>>>>> the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, >>>>>>>>>>>> now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves >>>>>>>>>>>> otherwise."
This pattern of argument applies to every existing theorem. >>>>>>>>>>>> Therefore, your idea is meaningless from the beginning. >>>>>>>>>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H >>>>>>>>>>>>> > (it's trivial to do for this one case) that correctly >>>>>>>>>>>>> determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist. >>>>>>>>>
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is >>>>>>>> written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. >>>>>>>>>> The assumption that a total halt decider exists is what allows >>>>>>>>>> the creation of a Turing machine, and therefore a finite
string description of that machine, that does the opposite. >>>>>>>>>>
All of your arguments boil down to "it's impossible because >>>>>>>>>> Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a
total halt decider exists, it can be shown through a series of truth
preserving operations that the "impossible input" can be created.
Yes and it has been 89 years and no one besides me
ever noticed that this *input* was never an actual
*input*.
For 89 years everyone conflated a directly executed
Turing machine as EXACTLY the same thing as a finite
string machine description.
In other words, you don't understand representations.
Do you understand that you cannot eat the word: "food"?
On Wed, 2025-08-20 at 21:35 -0400, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>> He simulates until either the simulation naturally >>>>>>>>>>>>> halts, or
one of his so-called "non-termination" patterns occurs >>>>>>>>>>>>> in the
analysis of the simulation. If that happens, the >>>>>>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one of >>>>>>>>>>>>> his
so-called non-termination pattern, the simulation >>>>>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>>>>> the case the Linz HP proof constructs for a given >>>>>>>>>>>>> decider,
which "does the opposite of what the decider decides". >>>>>>>>>>>>> [If you're not familiar with the proof you won't >>>>>>>>>>>>> understand
this bit, but it would take too long to explain here.] >>>>>>>>>>>>> So it makes no difference that his decider can't >>>>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, just a >>>>>>>>>>>>> /partial/ halt decider that correctly decides that one >>>>>>>>>>>>> input.
To cut a long story short, it turns out that his decider / >>>>>>>>>>>>> does/ decide the
one input he needs, but it decides incorrectly, saying that >>>>>>>>>>>>> it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>>>>> "non-termination pattern" matches, even though the
computation being
simulated halts. So his decider aborts the simulation and >>>>>>>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing >>>>>>>>>>>> piece. PO
has been quite clear that 0 is the correct return value. When >>>>>>>>>>>> asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>>>>
Right - it's been clear that PO really does believe that for >>>>>>>>>>> quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously >>>>>>>>>>> wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the >>>>>>>>>> nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I >>>>>>>> change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves
otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
; I don't think that is the shell game. PO really /has/ an H >>>>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>>>> > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is written
below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The
assumption that a total halt decider exists is what allows the
creation of a Turing machine, and therefore a finite string
description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing >>>>>> was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
then it becomes
dead obvious that
No total halt decider exists.
So you're saying the proof is wrong because what it proves is right.
Error: assuming the conclusion.
So, I think the whole story is that since olcott thinks he can see the HP is undecidable, therefore he thus decides the HP is decidable,... then the long journey
began: "Talent hits a target no one else can hit; Genius hits a target no one else can see."
On 8/20/2025 10:38 PM, olcott wrote:
On 8/20/2025 9:36 PM, dbush wrote:
On 8/20/2025 10:11 PM, olcott wrote:
On 8/20/2025 8:57 PM, dbush wrote:
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:No such input exists therefore the conventional proof
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote: >>>>>>>>>>>>>>>> On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry
<news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote: >>>>>>>>>>>>>>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>>>> On 10/08/2025 23:17, Keith Thompson wrote: >>>>>>>>>>>>>>>>> ...
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of >>>>>>>>>>>>>>>>>> steps.
He simulates until either the simulation >>>>>>>>>>>>>>>>>> naturally halts, or
one of his so-called "non-termination" patterns
occurs in the
analysis of the simulation. If that happens, >>>>>>>>>>>>>>>>>> the decider returns
0 [does not halt].
If the simulation never halts and never matches
one of his
so-called non-termination pattern, the >>>>>>>>>>>>>>>>>> simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC >>>>>>>>>>>>>>>>>> input case:
the case the Linz HP proof constructs for a >>>>>>>>>>>>>>>>>> given decider,
which "does the opposite of what the decider >>>>>>>>>>>>>>>>>> decides".
[If you're not familiar with the proof you >>>>>>>>>>>>>>>>>> won't understand
this bit, but it would take too long to explain
here.]
So it makes no difference that his decider >>>>>>>>>>>>>>>>>> can't decide / every/
input - he does not claim to have a Halt >>>>>>>>>>>>>>>>>> Decider, just a
/partial/ halt decider that correctly decides >>>>>>>>>>>>>>>>>> that one input.
To cut a long story short, it turns out that his >>>>>>>>>>>>>>>>>> decider / does/ decide the
one input he needs, but it decides incorrectly, saying >>>>>>>>>>>>>>>>>> that it never halts
when in fact the input is easily seen to halt. [His >>>>>>>>>>>>>>>>>> so- called
"non-termination pattern" matches, even though the >>>>>>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the >>>>>>>>>>>>>>>>>> simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return >>>>>>>>>>>>>>>>> value. When asked he
said:
"Yes that is the correct answer even though P(P) >>>>>>>>>>>>>>>>> halts."
Right - it's been clear that PO really does believe that >>>>>>>>>>>>>>>> for quite a while now! All his current
posting amounts to PO trying to justify /why/ the >>>>>>>>>>>>>>>> obviously wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into >>>>>>>>>>>>>>> the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, >>>>>>>>>>>>> now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves >>>>>>>>>>>>> otherwise."
This pattern of argument applies to every existing theorem. >>>>>>>>>>>>> Therefore, your idea is meaningless from the beginning. >>>>>>>>>>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ >>>>>>>>>>>>>> an H
> (it's trivial to do for this one case) that correctly >>>>>>>>>>>>>> determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist. >>>>>>>>>>
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is >>>>>>>>> written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. >>>>>>>>>>> The assumption that a total halt decider exists is what >>>>>>>>>>> allows the creation of a Turing machine, and therefore a >>>>>>>>>>> finite string description of that machine, that does the >>>>>>>>>>> opposite.
All of your arguments boil down to "it's impossible because >>>>>>>>>>> Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a
total halt decider exists, it can be shown through a series of
truth preserving operations that the "impossible input" can be
created.
Yes and it has been 89 years and no one besides me
ever noticed that this *input* was never an actual
*input*.
For 89 years everyone conflated a directly executed
Turing machine as EXACTLY the same thing as a finite
string machine description.
In other words, you don't understand representations.
Do you understand that you cannot eat the word: "food"?
In other words, you don't think Turing machines can do arithmetic.
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted.
On 21/08/2025 00:40, olcott wrote:
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted.
It's an easily verified fact that HHH is part of DD.
int DD()
{
int Halt_Status = HHH(DD);
Verified.
It's an easily verified fact that HHH(DD) stops the DD simulation, at
least according to the author of HHH:
"The execution trace is not needed to correctly determine that DD
correctly simulated by HHH is non-halting. All five LLM systems figured
that out on the basis of static analysis of the C text
that HHH(DD)==0 is correct." P Olcott, 20/8/2025 in Usenet message <1085e5p$idn8$1@dont-email.me>.
THEREFORE, HHH (which is a part of DD - see above) terminates DD, and THEREFORE DD is self-terminating, which means in turn that HHH is
incorrect to claim that DD is non-halting; the seeds for DD's halting
are baked right into its fabric.
HHH must return 1, because DD must halt (as the simulation proves when
it *forces* DD to halt).
And when HHH is fixed to /correctly/ return 1, DD will prove it wrong by engaging its infinite goto loop and not halting. But that's okay,
because apparently that part of DD is beneath HHH's dignity to inspect.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
On 8/20/2025 9:38 PM, dbush wrote:
On 8/20/2025 10:38 PM, olcott wrote:
On 8/20/2025 9:36 PM, dbush wrote:
On 8/20/2025 10:11 PM, olcott wrote:
On 8/20/2025 8:57 PM, dbush wrote:
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:No such input exists therefore the conventional proof
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote: >>>>>>>>>>>>>>>>> On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry
<news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote: >>>>>>>>>>>>>>>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>>>>> On 10/08/2025 23:17, Keith Thompson wrote: >>>>>>>>>>>>>>>>>> ...
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of >>>>>>>>>>>>>>>>>>> steps.
He simulates until either the simulation >>>>>>>>>>>>>>>>>>> naturally halts, or
one of his so-called "non-termination" >>>>>>>>>>>>>>>>>>> patterns occurs in the
analysis of the simulation. If that happens,
the decider returns
0 [does not halt].
If the simulation never halts and never >>>>>>>>>>>>>>>>>>> matches one of his
so-called non-termination pattern, the >>>>>>>>>>>>>>>>>>> simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC >>>>>>>>>>>>>>>>>>> input case:
the case the Linz HP proof constructs for a >>>>>>>>>>>>>>>>>>> given decider,
which "does the opposite of what the decider >>>>>>>>>>>>>>>>>>> decides".
[If you're not familiar with the proof you >>>>>>>>>>>>>>>>>>> won't understand
this bit, but it would take too long to >>>>>>>>>>>>>>>>>>> explain here.]
So it makes no difference that his decider >>>>>>>>>>>>>>>>>>> can't decide / every/
input - he does not claim to have a Halt >>>>>>>>>>>>>>>>>>> Decider, just a
/partial/ halt decider that correctly decides >>>>>>>>>>>>>>>>>>> that one input.
To cut a long story short, it turns out that his >>>>>>>>>>>>>>>>>>> decider / does/ decide the
one input he needs, but it decides incorrectly, >>>>>>>>>>>>>>>>>>> saying that it never halts
when in fact the input is easily seen to halt. [His >>>>>>>>>>>>>>>>>>> so- called
"non-termination pattern" matches, even though the >>>>>>>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the >>>>>>>>>>>>>>>>>>> simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return >>>>>>>>>>>>>>>>>> value. When asked he
said:
"Yes that is the correct answer even though P(P) >>>>>>>>>>>>>>>>>> halts."
Right - it's been clear that PO really does believe >>>>>>>>>>>>>>>>> that for quite a while now! All his current >>>>>>>>>>>>>>>>> posting amounts to PO trying to justify /why/ the >>>>>>>>>>>>>>>>> obviously wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into >>>>>>>>>>>>>>>> the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless >>>>>>>>>>>>>>> aborted. People here have been consistently lying >>>>>>>>>>>>>>> about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, >>>>>>>>>>>>>> now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves >>>>>>>>>>>>>> otherwise."
This pattern of argument applies to every existing theorem. >>>>>>>>>>>>>> Therefore, your idea is meaningless from the beginning. >>>>>>>>>>>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ >>>>>>>>>>>>>>> an H
> (it's trivial to do for this one case) that correctly >>>>>>>>>>>>>>> determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist. >>>>>>>>>>>
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is >>>>>>>>>> written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by >>>>>>>>>> contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. >>>>>>>>>>>> The assumption that a total halt decider exists is what >>>>>>>>>>>> allows the creation of a Turing machine, and therefore a >>>>>>>>>>>> finite string description of that machine, that does the >>>>>>>>>>>> opposite.
All of your arguments boil down to "it's impossible because >>>>>>>>>>>> Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a
total halt decider exists, it can be shown through a series of
truth preserving operations that the "impossible input" can be
created.
Yes and it has been 89 years and no one besides me
ever noticed that this *input* was never an actual
*input*.
For 89 years everyone conflated a directly executed
Turing machine as EXACTLY the same thing as a finite
string machine description.
In other words, you don't understand representations.
Do you understand that you cannot eat the word: "food"?
In other words, you don't think Turing machines can do arithmetic.
Every mere representation of a thing leaves out
most of the details.
Turing machine descriptions by
themselves say nothing at all about Turing machines.
On 21/08/2025 00:56, olcott wrote:
<snip>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
On the contrary, what everyone except you has noticed is that it's impossible for the decider (of the halting status of any arbitrary
program with any arbitrary input) to exist, and therefore - lacking existence - it is obviously not in a position to report anything.
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
They pay attention to the proof, which clearly you don't.
On 8/20/2025 10:47 PM, olcott wrote:
On 8/20/2025 9:38 PM, dbush wrote:
On 8/20/2025 10:38 PM, olcott wrote:
On 8/20/2025 9:36 PM, dbush wrote:
On 8/20/2025 10:11 PM, olcott wrote:
On 8/20/2025 8:57 PM, dbush wrote:
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:No such input exists therefore the conventional proof
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote: >>>>>>>>>>>>>>>> On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote: >>>>>>>>>>>>>>>>>> On 20/08/2025 12:10, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> Mike Terry
<news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote: >>>>>>>>>>>>>>>>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>>>>>> On 10/08/2025 23:17, Keith Thompson wrote: >>>>>>>>>>>>>>>>>>> ...
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of >>>>>>>>>>>>>>>>>>>> steps.
He simulates until either the simulation >>>>>>>>>>>>>>>>>>>> naturally halts, or
one of his so-called "non-termination" >>>>>>>>>>>>>>>>>>>> patterns occurs in the
analysis of the simulation. If that happens,
the decider returns
0 [does not halt].
If the simulation never halts and never >>>>>>>>>>>>>>>>>>>> matches one of his
so-called non-termination pattern, the >>>>>>>>>>>>>>>>>>>> simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC >>>>>>>>>>>>>>>>>>>> input case:
the case the Linz HP proof constructs for a >>>>>>>>>>>>>>>>>>>> given decider,
which "does the opposite of what the decider >>>>>>>>>>>>>>>>>>>> decides".
[If you're not familiar with the proof you >>>>>>>>>>>>>>>>>>>> won't understand
this bit, but it would take too long to >>>>>>>>>>>>>>>>>>>> explain here.]
So it makes no difference that his decider >>>>>>>>>>>>>>>>>>>> can't decide / every/
input - he does not claim to have a Halt >>>>>>>>>>>>>>>>>>>> Decider, just a
/partial/ halt decider that correctly decides
that one input.
To cut a long story short, it turns out that his >>>>>>>>>>>>>>>>>>>> decider / does/ decide the
one input he needs, but it decides incorrectly, >>>>>>>>>>>>>>>>>>>> saying that it never halts
when in fact the input is easily seen to halt. [His >>>>>>>>>>>>>>>>>>>> so- called
"non-termination pattern" matches, even though the >>>>>>>>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the >>>>>>>>>>>>>>>>>>>> simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final >>>>>>>>>>>>>>>>>>> missing piece. PO
has been quite clear that 0 is the correct return >>>>>>>>>>>>>>>>>>> value. When asked he
said:
"Yes that is the correct answer even though P(P) >>>>>>>>>>>>>>>>>>> halts."
Right - it's been clear that PO really does believe >>>>>>>>>>>>>>>>>> that for quite a while now! All his current >>>>>>>>>>>>>>>>>> posting amounts to PO trying to justify /why/ the >>>>>>>>>>>>>>>>>> obviously wrong answer is /really/ correct. >>>>>>>>>>>>>>>>>> It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into >>>>>>>>>>>>>>>>> the nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless >>>>>>>>>>>>>>>> aborted. People here have been consistently lying >>>>>>>>>>>>>>>> about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, >>>>>>>>>>>>>>> now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof >>>>>>>>>>>>>>> proves otherwise."
This pattern of argument applies to every existing theorem. >>>>>>>>>>>>>>> Therefore, your idea is meaningless from the beginning. >>>>>>>>>>>>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really / >>>>>>>>>>>>>>>> has/ an H
> (it's trivial to do for this one case) that >>>>>>>>>>>>>>>> correctly determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist. >>>>>>>>>>>>
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is >>>>>>>>>>> written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by >>>>>>>>>>> contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not >>>>>>>>>>>>> exist. The assumption that a total halt decider exists is >>>>>>>>>>>>> what allows the creation of a Turing machine, and therefore >>>>>>>>>>>>> a finite string description of that machine, that does the >>>>>>>>>>>>> opposite.
All of your arguments boil down to "it's impossible because >>>>>>>>>>>>> Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a >>>>>>> total halt decider exists, it can be shown through a series of
truth preserving operations that the "impossible input" can be
created.
Yes and it has been 89 years and no one besides me
ever noticed that this *input* was never an actual
*input*.
For 89 years everyone conflated a directly executed
Turing machine as EXACTLY the same thing as a finite
string machine description.
In other words, you don't understand representations.
Do you understand that you cannot eat the word: "food"?
In other words, you don't think Turing machines can do arithmetic.
Every mere representation of a thing leaves out
most of the details.
False. By definition, the representation contains all necessary details about the object being represented.
Turing machine descriptions by
On 21/08/2025 02:45, wij wrote:
On Wed, 2025-08-20 at 21:35 -0400, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally
halts, or
one of his so-called "non-termination" patterns occurs
in the
analysis of the simulation. If that happens, the
decider returns
0 [does not halt].
If the simulation never halts and never matches one of
his
so-called non-termination pattern, the simulation
continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given
decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't
understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't
decide / every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one
input.
To cut a long story short, it turns out that his decider /
does/ decide the
one input he needs, but it decides incorrectly, saying that
it never halts
when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and
incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing
piece. PO
has been quite clear that 0 is the correct return value. When
asked he
said:
"Yes that is the correct answer even though P(P) halts."
Right - it's been clear that PO really does believe that for
quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously
wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the
nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I
change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves otherwise."
This pattern of argument applies to every existing theorem. Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is written below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The
assumption that a total halt decider exists is what allows the creation of a Turing machine, and therefore a finite string description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing
was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
then it becomes
dead obvious that
No total halt decider exists.
So you're saying the proof is wrong because what it proves is right.
Error: assuming the conclusion.
So, I think the whole story is that since olcott thinks he can see the HP is
undecidable, therefore he thus decides the HP is decidable,... then the long journey
began: "Talent hits a target no one else can hit; Genius hits a target no one else can see."
"Talent hits a target no one else can hit; Genius hits a target no one else can see; Dumbo shoots
himself in the foot." (PO would like that as a fan of "categorically exhaustive reasoning")
Mike.Also, olcott might think the chance of 'hit' is high (50-50%, whatever). He began the
On 8/20/2025 9:53 PM, dbush wrote:
On 8/20/2025 10:47 PM, olcott wrote:
On 8/20/2025 9:38 PM, dbush wrote:
On 8/20/2025 10:38 PM, olcott wrote:
On 8/20/2025 9:36 PM, dbush wrote:
On 8/20/2025 10:11 PM, olcott wrote:
On 8/20/2025 8:57 PM, dbush wrote:
On 8/20/2025 9:48 PM, olcott wrote:
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:No such input exists therefore the conventional proof >>>>>>>>>>>>> that no universal decider exists FAILS.
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote: >>>>>>>>>>>>>>>>> On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote: >>>>>>>>>>>>>>>>>>> On 20/08/2025 12:10, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>> Mike Terry
<news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote: >>>>>>>>>>>>>>>>>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>>>>>>> On 10/08/2025 23:17, Keith Thompson wrote: >>>>>>>>>>>>>>>>>>>> ...
Is this what olcott is trying to do? >>>>>>>>>>>>>>>>>>>>>Pretty much. Except:
1. PO does not specify any limit for the number of >>>>>>>>>>>>>>>>>>>>> steps.
He simulates until either the simulation >>>>>>>>>>>>>>>>>>>>> naturally halts, or
one of his so-called "non-termination" >>>>>>>>>>>>>>>>>>>>> patterns occurs in the
analysis of the simulation. If that >>>>>>>>>>>>>>>>>>>>> happens, the decider returns
0 [does not halt].
If the simulation never halts and never >>>>>>>>>>>>>>>>>>>>> matches one of his
so-called non-termination pattern, the >>>>>>>>>>>>>>>>>>>>> simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC >>>>>>>>>>>>>>>>>>>>> input case:
the case the Linz HP proof constructs for a >>>>>>>>>>>>>>>>>>>>> given decider,
which "does the opposite of what the decider
decides".
[If you're not familiar with the proof you >>>>>>>>>>>>>>>>>>>>> won't understand
this bit, but it would take too long to >>>>>>>>>>>>>>>>>>>>> explain here.]
So it makes no difference that his decider >>>>>>>>>>>>>>>>>>>>> can't decide / every/
input - he does not claim to have a Halt >>>>>>>>>>>>>>>>>>>>> Decider, just a
/partial/ halt decider that correctly >>>>>>>>>>>>>>>>>>>>> decides that one input.
To cut a long story short, it turns out that his >>>>>>>>>>>>>>>>>>>>> decider / does/ decide the
one input he needs, but it decides incorrectly, >>>>>>>>>>>>>>>>>>>>> saying that it never halts
when in fact the input is easily seen to halt. [His >>>>>>>>>>>>>>>>>>>>> so- called
"non-termination pattern" matches, even though the >>>>>>>>>>>>>>>>>>>>> computation being
simulated halts. So his decider aborts the >>>>>>>>>>>>>>>>>>>>> simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a >>>>>>>>>>>>>>>>>>>> final missing piece. PO
has been quite clear that 0 is the correct return >>>>>>>>>>>>>>>>>>>> value. When asked he
said:
"Yes that is the correct answer even though >>>>>>>>>>>>>>>>>>>> P(P) halts."
Right - it's been clear that PO really does believe >>>>>>>>>>>>>>>>>>> that for quite a while now! All his current >>>>>>>>>>>>>>>>>>> posting amounts to PO trying to justify /why/ the >>>>>>>>>>>>>>>>>>> obviously wrong answer is /really/ correct. >>>>>>>>>>>>>>>>>>> It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump >>>>>>>>>>>>>>>>>> into the nonsense (POO simulation)?
Its an easily verified fact that DD correctly >>>>>>>>>>>>>>>>> simulated by HHH would never stop running unless >>>>>>>>>>>>>>>>> aborted. People here have been consistently lying >>>>>>>>>>>>>>>>> about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. >>>>>>>>>>>>>>>> But, now if I change the
idea, sentence to:
"..you cannot square a circle except a genine proof >>>>>>>>>>>>>>>> proves otherwise."
This pattern of argument applies to every existing theorem. >>>>>>>>>>>>>>>> Therefore, your idea is meaningless from the beginning. >>>>>>>>>>>>>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really / >>>>>>>>>>>>>>>>> has/ an H
> (it's trivial to do for this one case) that >>>>>>>>>>>>>>>>> correctly determines
> that P(P) *would* never stop running *unless* aborted. >>>>>>>>>>>>>>>>>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist. >>>>>>>>>>>>>
In other words, you're not smart enough to understand what >>>>>>>>>>>> is written below hence why you dishonestly trimmed it. >>>>>>>>>>>>
All you're doing is proving you don't understand proof by >>>>>>>>>>>> contradiction over 50 years after it was taught to you. >>>>>>>>>>>>
No input exists because a total halt decider does not >>>>>>>>>>>>>> exist. The assumption that a total halt decider exists is >>>>>>>>>>>>>> what allows the creation of a Turing machine, and >>>>>>>>>>>>>> therefore a finite string description of that machine, >>>>>>>>>>>>>> that does the opposite.
All of your arguments boil down to "it's impossible >>>>>>>>>>>>>> because Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
No, you have it backwards. Starting with the assumption that a >>>>>>>> total halt decider exists, it can be shown through a series of >>>>>>>> truth preserving operations that the "impossible input" can be >>>>>>>> created.
Yes and it has been 89 years and no one besides me
ever noticed that this *input* was never an actual
*input*.
For 89 years everyone conflated a directly executed
Turing machine as EXACTLY the same thing as a finite
string machine description.
In other words, you don't understand representations.
Do you understand that you cannot eat the word: "food"?
In other words, you don't think Turing machines can do arithmetic.
Every mere representation of a thing leaves out
most of the details.
False. By definition, the representation contains all necessary
details about the object being represented.
Turing machine descriptions by
What exactly is it about the word "human"
that tells you the details of brain surgery methods?
The DD that is calling HHH(DD) is not its input.
No C function or Turing machine can have its actual
self as its input.
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
What I just said is true that you are no bright enough
to understand that it is true is no error on my part.
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
All of your arguments boil down to "it's impossible because
Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
Dishonestly saying that HHH emulates zero
instructions of DD proves that you don't tell
the truth.
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
On 21/08/2025 01:53, olcott wrote:Cite your sources.
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
<snip>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
Not true.
The conventional proof does not require the existence of the input you describe,
On 8/20/2025 9:48 PM, Richard Heathfield wrote:
On 21/08/2025 00:40, olcott wrote:
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted.
It's an easily verified fact that HHH is part of DD.
int DD()
{
int Halt_Status = HHH(DD);
Verified.
It's an easily verified fact that HHH(DD) stops the DD
simulation, at least according to the author of HHH:
"The execution trace is not needed to correctly determine that
DD correctly simulated by HHH is non-halting. All five LLM
systems figured that out on the basis of static analysis of the
C text
that HHH(DD)==0 is correct." P Olcott, 20/8/2025 in Usenet
message <1085e5p$idn8$1@dont-email.me>.
THEREFORE, HHH (which is a part of DD - see above) terminates
DD, and THEREFORE DD is self-terminating, which means in turn
that HHH is incorrect to claim that DD is non-halting; the
seeds for DD's halting are baked right into its fabric.
HHH must return 1, because DD must halt (as the simulation
proves when it *forces* DD to halt).
When I prove some instructions are correctly
simulated by HHH and you continue to say that
zero instructions are simulation by HHH you
prove yourself to be a liar.
On 8/20/2025 9:52 PM, Richard Heathfield wrote:
On 21/08/2025 00:56, olcott wrote:
<snip>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
On the contrary, what everyone except you has noticed is that
it's impossible for the decider (of the halting status of any
arbitrary program with any arbitrary input) to exist, and
therefore - lacking existence - it is obviously not in a
position to report anything.
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
They pay attention to the proof, which clearly you don't.
I sum up my view more precisely here: [The Peter Linz HP proof]
On 8/20/2025 9:53 PM, dbush wrote:
On 8/20/2025 10:47 PM, olcott wrote:
Every mere representation of a thing leaves out
most of the details.
False. By definition, the representation contains all
necessary details about the object being represented.
Turing machine descriptions by
What exactly is it about the word "human"
that tells you the details of brain surgery methods?
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
Cite your sources.
The conventional proof does not require the existence of the
input you describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
On 8/20/2025 1:42 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 13:20:28 -0500, olcott wrote:
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:
When we are careful to make sure to keep this in mind:
Turing machine deciders only compute the mapping from their inputs...
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
Nobody is suggesting that HHH(DD) can see its caller however we are
passing a *description* of DD to HHH and HHH needs to return a decision
to its caller, DD.
It does do that. HHH reports that its DD DOES NOT HALT because its
simulated DD DOES CALL HHH IN RECURSIVE SIMULATION that would never stop running unless aborted.
Am Wed, 20 Aug 2025 14:50:50 -0500 schrieb olcott:
On 8/20/2025 1:42 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 13:20:28 -0500, olcott wrote:
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:
When we are careful to make sure to keep this in mind:
Turing machine deciders only compute the mapping from their inputs...
Nothing prevents a TM from mapping a description to its direct execution.
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
Nobody is suggesting that HHH(DD) can see its caller however we are
passing a *description* of DD to HHH and HHH needs to return a decision
to its caller, DD.
It does do that. HHH reports that its DD DOES NOT HALT because its
simulated DD DOES CALL HHH IN RECURSIVE SIMULATION that would never stop
running unless aborted.
It is my opinion that a halt decider should decide itself as halting.
On 8/20/2025 4:39 AM, joes wrote:
Am Tue, 19 Aug 2025 21:09:14 -0500 schrieb olcott:
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:You should just go ahead and do it. It would show the behaviour better.
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 5:58 PM, André G. Isaak wrote:
On 2025-08-19 11:42, olcott wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
But if (**execution_trace == 0x90909090) creates the exact sameI have known that for years.
problem as using a static variable. You're creating a global state >>>>>> which your HHH accesses and thus HHH is not a pure function.
After I got people here to quit lying about the behavior of DD correct >>>>> simulated by HHH I had intended to fix that issue.
I can assure you everybody will be completely honest about that.The correct simulation doesn't matter.I know that yet if I corrected that everyone here besides you would lie
The static flag (whether using a "static" variable, or de-facto static >>>> data stored in the code segment) throws a monkey wrench into the claim >>>> you are making based on a correct simulation.
about my having eliminated all static data as they lie about nearly
everything else.
The input isn’t even doing anything, it’s just data. The simulator isThe if statement testing the value of *execution_trace, together withThe fact that the counter-example input cannot even reach its own "do
another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
The fact that HHH (top level) can correctly decide something that HH
(recursive) doesn't decide is not interesting and doesn't speak to the >>>> Halting Theorem.
the opposite" code and remains stuck in recursive simulation does apply
to the halting problem proofs.
doing all the futile work. *That* is the one that can’t reach past
itself, when it quite clearly does halt. HHH(HHH) thinks itself doesn’t
halt, and yet it does.
The proof shows that the assumption is wrong. D halts, and H does notContrary to your repeatedly stated belief, The Halting Theorem doesn't >>>> say that there exist test cases whose halting is indeterminate suchThe halting problem proofs depend on the assumption that there is an H/D >>> pair such that D is undecidable by H. When I show how D is correctly
that they cannot be decided by /any/ decider.
decided by H these proofs fail.
return that.
I am not just using execution_trace as a flag.You are *also* using it as a flag.
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement final
halt state thus the *INPUT* specifies non-halting
behavior to HHH.
Turing machine deciders only compute the mapping
from their inputs...
HHH need not compute the mapping from its caller
because its caller *IS NOT ITS INPUT*
On 8/20/2025 2:33 PM, Chris M. Thomasson wrote:
On 8/20/2025 12:44 AM, Richard Heathfield wrote:
On 20/08/2025 08:37, Chris M. Thomasson wrote:
On 8/19/2025 6:20 PM, Richard Heathfield wrote:
On 20/08/2025 02:00, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
<snip>
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have >>>>>> that return value.
If HHH(DD) doens't have that value, it's just wrong.
Exercise for the discerning student: come up with a return value
for HHH(DD) that /isn't/ "just wrong".
Flip a coin and say mostly wrong?
Is that your best crack at "discerning"?
Try and reason it out.
Humm... Perhaps examine the source code passed into the decider as an
input. We look at said code and use a LLM or something to see if it
can detect any run away recursions, or infinite loops from that state
alone.
*Been there done that*
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21- eedd0f09e141
Then it can compile the code and run it many times, the original as a
control, and other "versions" (cheating by altering the source code)
to try to understand aspects about the source code passed into the
decider and how it runs. It might say it calls into some sort of known
TRNG API, so we cannot know if it halts or not. 50% halt, 50% non-
halt. We have not studied the source code good enough (at this time)
to determine if the TRNG results are being used in some sort of
"probability" in the target program or not...
On 8/20/2025 2:37 AM, Chris M. Thomasson wrote:
On 8/19/2025 6:20 PM, Richard Heathfield wrote:
On 20/08/2025 02:00, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
<snip>
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
If HHH(DD) doens't have that value, it's just wrong.
Exercise for the discerning student: come up with a return value for
HHH(DD) that /isn't/ "just wrong".
Flip a coin and say mostly wrong?
It is a matter of self evident truth
(stronger than verified fact) that DD
correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state. This self evident truth
proves that HHH(DD)==0 is correct.
Nearly everyone here has been telling lies
about this for three years, the ones that
were not lying were mistaken.
On 8/20/2025 4:33 AM, Fred. Zwarts wrote:
Op 20.aug.2025 om 03:39 schreef olcott:
On 8/19/2025 8:00 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by(1) The static flag is dead and not used.
the HHH
embedded into it, a /different/ HHH (using the same procedure name >>>>>> and
body, distinguished from DD's HHH by a hidden static flag) can decide >>>>>
if (**execution_trace == 0x90909090) is used instead.
It's the same thing. "static data" doesn't mean that "static" keyword
must be used.
Yes I know that yet I wanted you to understand
my actual code, not a misconception of it.
String literals like char *s = "abc" are understood to be static data
in C. Yet, no static keyworcd is used. Moreover, it's common for
compilers to place them into the text segment, right where the code
is---much like your *execution_trace word!
External variables without the "static" keyword are also in static
storage. At file scope "static" doesn't control the kind of storage,
but the linkage of the identifier: it give sinternal versus external
linkage.
In this debate when I say "static flag" I mean that it's something in
a persistent memory outside of the function (not allocated and
initialized on entry into the function, but externally accessed
and shared by all activations of the function).
It is not so much a flag as it is a location
to store the required execution trace.
I don't mean that the static keyword is used, which is a distracting,
irrelevant issue.
On this topic, also ...
You should go back to the static variable because it's a much more
portable way to obtain a piece of static storage associated with
a function than modifying its code. static variables are defined
by the C language, whereas self-modifying code is undefined behavior.
It clutters your code with weird gotos around inline assembly.
I envisioned my way of doing it as analogous to a UTM
setting aside a portion of its own tape for its slave
UTMs to use as their own tape.
I envision HHH as a UTM with extra features.
Moreover, you're assuming that the EAX register is free for you
to clobber. That is false; there are calling conventions for X86
where EAX is the first parameter; if you do some LEA EAX, WHATEVER,
you will obliterate the argument. Maybe that's not happening with
your toolchain but it's a threat.
I could easily see all the generated x86 code verifying
that this is in fact not an issue in this case.
that DD does not halt. Bravo! You also know that when you remove the >>>>>> static flag, of course the whole show doesn't halt: you get runaway >>>>>> simulation. You know that this is because the outside and inside
HHH are
then exactly the same (except that the inner one is emulated
wheras the
outside one is native).
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
Deducing what its return value should be on the basis
of the actual behavior of DD correctly simulated by
HHH is proven to be correctly 0.
If HHH(DD) doens't have that value, it's just wrong.
Not exactly. The static analysis of the C code does
prove that HHH(DD) returning 0 would be correct.
As usual incorrect claims without evidence.
No, it proves the failure of HHH to reach the final halt state
specified in the input.
If you edit HHH tro try to give it a different value, you
change DD, because DD is built on HHH. That new DD contradicts
the new HHH.
When 0 to ∞ instructions of DD are correctly
simulated by HHH the DD simulated by its HHH never
reaches its own simulated "return" statement final
halt state thus the difference between HHH/DD pairs
is of no relevant consequence.
It makes a difference, because it proves that for each HHH another DD
can be constructed for which this HHH fails.
Each input specifies a final halt state, as can be proven by other
simulators using exactly the same input.
But for each HHH there is an input for which it fails to predict the
correct halting behaviour.
Counter-factual.
The input designed to thwart HHH fails to thwart HHH.
This is inline with the halting theorem.
It shows that simulation is not the correct tool to analyse halting
behaviour, because, no matter how many steps are simulated, it is
always possible to construct an input that needs more steps.
Your ownly way out is to split HHH into two (top level and recursive)
while pretending it's the same decider, but that is utterly bogus.
DD simulated by HHH that includes HHH simulating
and instance of itself simulating another instance
of DD is all a pure function of the input to HHH(DD).
Not, if the simulated HHH behaves differently because of the cheat
with the Root variable.
Not if HHH does not analyse the conditional branch instructions when
simulating its own code.
Olcott's major malfunction as far as the Halting Problem is concerned is
his inability to recognise the difference between (and/or his conflation
of) *execution* with *computation*.
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is concerned is
his inability to recognise the difference between (and/or his conflation
of) *execution* with *computation*.
Pete needs a doctor.
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
It isn't "the halting problem input/decider pair" because no
such pair exists. We know this because the decider doesn't exist. And we know /that/ because if a decider did exist we'd be able to construct a
case it can't decide, invalidating its claim to decidership.
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is concerned is >>> his inability to recognise the difference between (and/or his conflation >>> of) *execution* with *computation*.
Pete needs a doctor.
I consider that statement defamation of character.
It is an easily verified fact that
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
DD[0] is invoked and calls HHH[0]
that creates a
separate DD[1] process context with its own set of
16 virtual registers and virtual stack.
When HHH[0] encounters the call from DD[1] to HHH[1](DD)
Am Wed, 20 Aug 2025 14:50:50 -0500 schrieb olcott:
On 8/20/2025 1:42 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 13:20:28 -0500, olcott wrote:
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:
When we are careful to make sure to keep this in mind:
Turing machine deciders only compute the mapping from their inputs...
Nothing prevents a TM from mapping a description to its direct execution.
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
Nobody is suggesting that HHH(DD) can see its caller however we are
passing a *description* of DD to HHH and HHH needs to return a decision
to its caller, DD.
It does do that. HHH reports that its DD DOES NOT HALT because its
simulated DD DOES CALL HHH IN RECURSIVE SIMULATION that would never stop
running unless aborted.
It is my opinion that a halt decider should decide itself as halting.
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is
concerned is
his inability to recognise the difference between (and/or his
conflation
of) *execution* with *computation*.
Pete needs a doctor.
I consider that statement defamation of character.
On 21/08/2025 07:51, joes wrote:
Am Wed, 20 Aug 2025 14:50:50 -0500 schrieb olcott:
On 8/20/2025 1:42 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 13:20:28 -0500, olcott wrote:
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:
When we are careful to make sure to keep this in mind:
Turing machine deciders only compute the mapping from their inputs...
Nothing prevents a TM from mapping a description to its direct execution.
Agreed.
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus >>>>> has no idea if its caller is DD or main.
Nobody is suggesting that HHH(DD) can see its caller however we are
passing a *description* of DD to HHH and HHH needs to return a decision >>>> to its caller, DD.
It does do that. HHH reports that its DD DOES NOT HALT because its
simulated DD DOES CALL HHH IN RECURSIVE SIMULATION that would never stop >>> running unless aborted.
It is my opinion that a halt decider should decide itself as halting.
Well, a decider should certainly halt, but its decision should be based
on what the facts are, not on what the facts ought to be. If a halt
decider fails to halt, it should say so.
Furthermore, it has no business terminating its invoker. To be a
decider, it must report. If HHH terminates (as we have been told it /
does/ terminate) DD, it can't report to it, so HHH fails to be a decider.
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
On 8/21/2025 1:51 AM, joes wrote:
Am Wed, 20 Aug 2025 14:50:50 -0500 schrieb olcott:
On 8/20/2025 1:42 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 13:20:28 -0500, olcott wrote:
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:
When we are careful to make sure to keep this in mind:
Turing machine deciders only compute the mapping from their inputs...
Nothing prevents a TM from mapping a description to its direct execution.
There are apparently cases where the mapping fails.
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
On 21/08/2025 05:01, olcott wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
<snip>
Cite your sources.
The conventional proof does not require the existence of the input
you describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
It's high time you took a closer look at Turing's proof, which requires
no such "input" to exist. Indeed, the whole point of his proof is to
show that there can be nowhere into which to put such an "input", and therefore such an "input" *cannot* exist.
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
No, it's not a lie. Your claim to a parallel to the form of Linz's
argument has nothing to do with anything either way, and your claim that
"DD correctly simulated by HHH *is* the halting problem input/decider
pair" is absurd. As I said before, it isn't "the halting problem input/ decider pair" because no such pair exists. We know this because the
decider doesn't exist. And we know /that/ because if a decider did exist we'd be able to construct a case it can't decide, invalidating its claim
to decidership.
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
On 8/19/2025 4:42 PM, dbush wrote:
His argument is that the decision that X(Y) is making is not "does
algorithm Y halt", but basically "does there exist an implementation
of function X that can simulate function call Y() to completion?"
Yes.
This happens to coincide with the halting function in cases where
Yes
function Y does not call function X at some point, but not in cases
where it does.
On 8/21/2025 12:18 PM, olcott wrote:
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
But you admitted that you're not working on the halting problem (see
below):
On 8/21/2025 11:21 AM, dbush wrote:
On 8/21/2025 12:18 PM, olcott wrote:
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
But you admitted that you're not working on the halting problem (see
below):
I am working on the Halting Problem
in the same way that ZFC worked on
Russell's Paradox.
*I insist that this axiom must be obeyed and not ignored*
Turing machine deciders only compute the mapping
from their inputs...
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:I consider that statement defamation of character.
Olcott's major malfunction as far as the Halting Problem is concerned
is his inability to recognise the difference between (and/or his
conflation of) *execution* with *computation*.
Pete needs a doctor.
It is an easily verified fact that
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH uses cooperative multi-tasking to switch between itself and its
simulated DD instance.
DD[0] is invoked and calls HHH[0] that creates a separate DD[1] process context with its own set of 16 virtual registers and virtual stack.
When HHH[0] encounters the call from DD[1] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same DD[1] process
context.
When HHH[1] begins simulating its own DD[2] it must create a separate
DD[2] process context with its own set of 16 virtual registers and
virtual stack...
on and on until OOM error (proving non-halting) when we eliminate the
u32* execution_trace data.
On 21/08/2025 16:06, olcott wrote:
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is
concerned is
his inability to recognise the difference between (and/or his
conflation
of) *execution* with *computation*.
Pete needs a doctor.
I consider that statement defamation of character.
People who /don't/ need a doctor take that kind of thing as a little
light leg-pulling and don't see the need to drag in legal-sounding
terms. Perhaps you'd like to reconsider your answer?
On 8/21/2025 10:11 AM, Richard Heathfield wrote:
On 21/08/2025 16:06, olcott wrote:I will call out every instance of libel.
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:I consider that statement defamation of character.
Olcott's major malfunction as far as the Halting Problem is
concerned is his inability to recognise the difference between
(and/or his conflation of) *execution* with *computation*.
Pete needs a doctor.
People who /don't/ need a doctor take that kind of thing as a little
light leg-pulling and don't see the need to drag in legal-sounding
terms. Perhaps you'd like to reconsider your answer?
On 8/20/2025 11:45 PM, Richard Heathfield wrote:
On 21/08/2025 05:01, olcott wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
<snip>
Cite your sources.
The conventional proof does not require the existence of the
input you describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
It's high time you took a closer look at Turing's proof, which
requires no such "input" to exist. Indeed, the whole point of
his proof is to show that there can be nowhere into which to
put such an "input", and therefore such an "input" *cannot* exist.
It wasn't even called the Halting problem
until after he died.
If you want to anchor
the HP in text then use please use Linz.
On 8/21/2025 12:28 PM, olcott wrote:
On 8/21/2025 11:21 AM, dbush wrote:
On 8/21/2025 12:18 PM, olcott wrote:
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
But you admitted that you're not working on the halting problem (see
below):
I am working on the Halting Problem
in the same way that ZFC worked on
Russell's Paradox.
No you're not, as you haven't defined a new system from axiom and proved what the system is capable of.
*I insist that this axiom must be obeyed and not ignored*
Turing machine deciders only compute the mapping
from their inputs...
Which means they can only map computable functions, and the halting
function (see below) is not a computable function as Linz and others
have proved and as you have *explicitly* agreed is correct.
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
On Thu, 21 Aug 2025 10:06:25 -0500, olcott wrote:
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:I consider that statement defamation of character.
Olcott's major malfunction as far as the Halting Problem is concerned
is his inability to recognise the difference between (and/or his
conflation of) *execution* with *computation*.
Pete needs a doctor.
It is an easily verified fact that
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH uses cooperative multi-tasking to switch between itself and its
simulated DD instance.
DD[0] is invoked and calls HHH[0] that creates a separate DD[1] process
context with its own set of 16 virtual registers and virtual stack.
When HHH[0] encounters the call from DD[1] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same DD[1] process
context.
When HHH[1] begins simulating its own DD[2] it must create a separate
DD[2] process context with its own set of 16 virtual registers and
virtual stack...
on and on until OOM error (proving non-halting) when we eliminate the
u32* execution_trace data.
At which point it needs to report that "proven" non-halting decision to
its caller, DD(), which will then halt confirming the extant Halting
Problem proofs are correct.
/Flibble
On 8/21/2025 11:41 AM, Mr Flibble wrote:
On Thu, 21 Aug 2025 10:06:25 -0500, olcott wrote:
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:I consider that statement defamation of character.
Olcott's major malfunction as far as the Halting Problem is
concerned is his inability to recognise the difference between
(and/or his conflation of) *execution* with *computation*.
Pete needs a doctor.
It is an easily verified fact that
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH uses cooperative multi-tasking to switch between itself and its
simulated DD instance.
DD[0] is invoked and calls HHH[0] that creates a separate DD[1]
process context with its own set of 16 virtual registers and virtual
stack.
When HHH[0] encounters the call from DD[1] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same DD[1] process
context.
When HHH[1] begins simulating its own DD[2] it must create a separate
DD[2] process context with its own set of 16 virtual registers and
virtual stack...
on and on until OOM error (proving non-halting) when we eliminate the
u32* execution_trace data.
At which point it needs to report that "proven" non-halting decision to
its caller, DD(), which will then halt confirming the extant Halting
Problem proofs are correct.
/Flibble
*Only when one stupidly ignores this axiom* Turing machine deciders only compute the mapping from their inputs...
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
When I apply a simulating halt decider in both
cases we get the same result.
When you try to hack HHH/DD so that DD reaches
its unreachable instructions THIS IS CHEATING.
No, it's not a lie. Your claim to a parallel to the form of
Linz's argument has nothing to do with anything either way, and
your claim that "DD correctly simulated by HHH *is* the halting
problem input/decider pair" is absurd. As I said before, it
isn't "the halting problem input/ decider pair" because no such
pair exists. We know this because the decider doesn't exist.
And we know /that/ because if a decider did exist we'd be able
to construct a case it can't decide, invalidating its claim to
decidership.
*I insist that this axiom must be obeyed and not ignored*
On 21/08/2025 16:48, olcott wrote:
On 8/20/2025 11:45 PM, Richard Heathfield wrote:
On 21/08/2025 05:01, olcott wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
<snip>
Cite your sources.
The conventional proof does not require the existence of the input
you describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
It's high time you took a closer look at Turing's proof, which
requires no such "input" to exist. Indeed, the whole point of his
proof is to show that there can be nowhere into which to put such an
"input", and therefore such an "input" *cannot* exist.
It wasn't even called the Halting problem
until after he died.
Indeed it wasn't. Nevertheless, his 1936 paper lays out the proof in
Section 8.
If you want to anchor
the HP in text then use please use Linz.
Why? Does his argument differ in any important way? I doubt it.
Your UTF-8 salad is unreadable. Try English.
On 8/21/2025 10:11 AM, Richard Heathfield wrote:
On 21/08/2025 16:06, olcott wrote:
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is
concerned is
his inability to recognise the difference between (and/or
his conflation
of) *execution* with *computation*.
Pete needs a doctor.
I consider that statement defamation of character.
People who /don't/ need a doctor take that kind of thing as a
little light leg-pulling and don't see the need to drag in
legal-sounding terms. Perhaps you'd like to reconsider your
answer?
I will call out every instance of libel.
On 21/08/2025 17:18, olcott wrote:
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
When I apply a simulating halt decider in both
cases we get the same result.
Is it then your claim that you have a universal halt decider? Because
you don't.
When you try to hack HHH/DD so that DD reaches
its unreachable instructions THIS IS CHEATING.
I don't touch HHH. All I do is optimise it out by doing what you say it
does --- i.e. returns 0.
On 8/21/2025 11:32 AM, dbush wrote:
On 8/21/2025 12:28 PM, olcott wrote:
On 8/21/2025 11:21 AM, dbush wrote:
On 8/21/2025 12:18 PM, olcott wrote:
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
But you admitted that you're not working on the halting problem (see
below):
I am working on the Halting Problem
in the same way that ZFC worked on
Russell's Paradox.
No you're not, as you haven't defined a new system from axiom and
proved what the system is capable of.
*I insist that this axiom must be obeyed and not ignored*
Turing machine deciders only compute the mapping
from their inputs...
Which means they can only map computable functions, and the halting
function (see below) is not a computable function as Linz and others
have proved and as you have *explicitly* agreed is correct.
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
*That keeps ignoring*
Turing machine deciders only compute the mapping
from their inputs...
Thus proving the the above requirements ARE WRONG.
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
On 8/21/2025 10:17 AM, Richard Heathfield wrote:
On 21/08/2025 16:08, olcott wrote:
On 8/20/2025 10:57 PM, Richard Heathfield wrote:
On 21/08/2025 03:13, olcott wrote:
On 8/20/2025 8:57 PM, Richard Heathfield wrote:
On 20/08/2025 21:17, olcott wrote:*It has the same form as the Linz proof*
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
No, it isn't.
Irrelevant.
That you say it is irrelevant is a damned lie.
You don't actually know what a lie is, do you?
The Linz proof is a halting problem proof.
When my proof matches the structure of the Linz
proof then my proof is a halting problem proof.
When I apply a simulating halt decider in both
cases we get the same result.
Is it then your claim that you have a universal halt decider? Because
you don't.
I never claimed and always disavowed that I
have a universal decider
and that I am rebutting
the halting problem.
On 8/19/2025 4:42 PM, dbush wrote:
His argument is that the decision that X(Y) is making is not "does
algorithm Y halt", but basically "does there exist an implementation
of function X that can simulate function call Y() to completion?"
Yes.
This happens to coincide with the halting function in cases where
Yes
function Y does not call function X at some point, but not in cases
where it does.
On 21/08/2025 17:28, olcott wrote:
<snip>
*I insist that this axiom must be obeyed and not ignored*
You can insist on any axiom you like for your own reasoning, but you
can't inject axioms into the Halting Problem or proofs of the
undecidability thereof. You don't get to pick other people's axioms for them; that's not how axioms work.
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
When I apply a simulating halt decider in both
cases we get the same result.
Is it then your claim that you have a universal halt decider?
Because you don't.
I never claimed and always disavowed that I
have a universal decider and that I am rebutting
the halting problem.
At most I have a partial halt decider that refutes
the conventional proof of the halting problem
yest does not refute the halting problem itself.
When you try to hack HHH/DD so that DD reaches
its unreachable instructions THIS IS CHEATING.
I don't touch HHH. All I do is optimise it out by doing what
you say it does --- i.e. returns 0.
It also returns 1 so your "optimization" f-cks it up.
On 21/08/2025 17:45, olcott wrote:
On 8/21/2025 10:11 AM, Richard Heathfield wrote:
On 21/08/2025 16:06, olcott wrote:
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is
concerned is
his inability to recognise the difference between (and/or his
conflation
of) *execution* with *computation*.
Pete needs a doctor.
I consider that statement defamation of character.
People who /don't/ need a doctor take that kind of thing as a little
light leg-pulling and don't see the need to drag in legal-sounding
terms. Perhaps you'd like to reconsider your answer?
I will call out every instance of libel.
So you're happy to dish it out but not to take it. That won't go down
well in court.
Also, libel is (written) defamation of character, and you're going to
find that /very/ hard to prove... and in the USA the burden of proof is
on the plaintiff.
On 21/08/2025 18:20, olcott wrote:
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
<snip>
When I apply a simulating halt decider in both
cases we get the same result.
Is it then your claim that you have a universal halt decider? Because
you don't.
I never claimed and always disavowed that I
have a universal decider and that I am rebutting
the halting problem.
That's what I thought. Glad to have it confirmed.
So when you claim to have a halt decider, you mean it only works
sometimes, like this one does:
int usuallyrighthaltdecider(const char **src, size_t nlines)
{
return 1;
}
At most I have a partial halt decider that refutes
the conventional proof of the halting problem
No, it doesn't. The conventional proof of the halting problem reasons
about a hypothetical /universal/ halt decider (which it proves cannot exist).
On 8/21/2025 12:36 PM, Richard Heathfield wrote:
On 21/08/2025 18:20, olcott wrote:Because most people get confused by the term "partial halt decider" yet understand the gist of the idea of a halt decider (determines halt
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
<snip>
I never claimed and always disavowed that I have a universal deciderWhen I apply a simulating halt decider in both cases we get the same >>>>> result.
Is it then your claim that you have a universal halt decider? Because
you don't.
and that I am rebutting the halting problem.
That's what I thought. Glad to have it confirmed.
So when you claim to have a halt decider, you mean it only works
sometimes, like this one does:
status)
I use the less precisely accurate term.
int usuallyrighthaltdecider(const char **src, size_t nlines)I prove that the proofs do not prove their point.
{
return 1;
}
At most I have a partial halt decider that refutes the conventional
proof of the halting problem
No, it doesn't. The conventional proof of the halting problem reasons
about a hypothetical /universal/ halt decider (which it proves cannot
exist).
On 8/21/2025 12:11 PM, Richard Heathfield wrote:
On 21/08/2025 17:28, olcott wrote:
<snip>
*I insist that this axiom must be obeyed and not ignored*
You can insist on any axiom you like for your own reasoning,
but you can't inject axioms into the Halting Problem or proofs
of the
It is common knowledge that this is an axiom
of the theory of computation.
On Thu, 21 Aug 2025 12:45:19 -0500, olcott wrote:
On 8/21/2025 12:36 PM, Richard Heathfield wrote:
On 21/08/2025 18:20, olcott wrote:Because most people get confused by the term "partial halt decider" yet
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
<snip>
I never claimed and always disavowed that I have a universal deciderWhen I apply a simulating halt decider in both cases we get the same >>>>>> result.
Is it then your claim that you have a universal halt decider? Because >>>>> you don't.
and that I am rebutting the halting problem.
That's what I thought. Glad to have it confirmed.
So when you claim to have a halt decider, you mean it only works
sometimes, like this one does:
understand the gist of the idea of a halt decider (determines halt
status)
I use the less precisely accurate term.
int usuallyrighthaltdecider(const char **src, size_t nlines)I prove that the proofs do not prove their point.
{
return 1;
}
At most I have a partial halt decider that refutes the conventional
proof of the halting problem
No, it doesn't. The conventional proof of the halting problem reasons
about a hypothetical /universal/ halt decider (which it proves cannot
exist).
You haven't proved shit in 22 years.
/Flibble
On 21/08/2025 18:36, olcott wrote:
On 8/21/2025 12:11 PM, Richard Heathfield wrote:
On 21/08/2025 17:28, olcott wrote:
<snip>
*I insist that this axiom must be obeyed and not ignored*
You can insist on any axiom you like for your own reasoning, but you
can't inject axioms into the Halting Problem or proofs of the
It is common knowledge that this is an axiom
of the theory of computation.
Then you'll be able to produce a citation.
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
On 8/21/2025 12:48 PM, Richard Heathfield wrote:
On 21/08/2025 18:36, olcott wrote:
On 8/21/2025 12:11 PM, Richard Heathfield wrote:
On 21/08/2025 17:28, olcott wrote:
<snip>
*I insist that this axiom must be obeyed and not ignored*
You can insist on any axiom you like for your own reasoning, but you
can't inject axioms into the Halting Problem or proofs of the
It is common knowledge that this is an axiom
of the theory of computation.
Then you'll be able to produce a citation.
Turing machine deciders only compute the mapping
from their inputs...
a function is computable if there is an algorithm
that computes the value of the function for every
value of its argument.
https://en.wikipedia.org/wiki/Computable_function
For Turing machines this argument must be a finite
string on its tape. It cannot be any actual Turing
machine such as Ĥ applied to ⟨Ĥ⟩.
On 8/21/2025 12:19 PM, Richard Heathfield wrote:
On 21/08/2025 17:45, olcott wrote:
I will call out every instance of libel.
So you're happy to dish it out but not to take it. That won't
go down well in court.
Also, libel is (written) defamation of character, and you're
going to find that /very/ hard to prove... and in the USA the
burden of proof is on the plaintiff.
None-the-less I will continue point point out
libel, unintentional counter-factual claims
and flat out lies about my work.
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input >>>>>> youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
On 8/15/2025 10:24 AM, olcott wrote:return 1.
On 8/15/2025 7:58 AM, dbush wrote:
On 8/15/2025 8:48 AM, olcott wrote:
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
--- Synchronet 3.21a-Linux NewsLink 1.2
And HHH fails to do so as the pattern it detects exists in the
halting program DD and is therefore not a non-halting behavior pattern.
Failing to explain why this is wrong in your next reply or within one
hour of your next post in this newsgroup will be taken as your
official on-the-record admission that the pattern HHH detects is NOT
a non- halting behavior pattern
Let the record show that Peter Olcott made no attempt to explain why the above is wrong. Therefore:
Let The Record Show:
That Peter Olcott
Has *officially* admitted
That the pattern detected by HHH is in fact NOT a non-halting behavior pattern because it exists in the halting computation DD, and furthermore than HHH fails to meet the specification that he gave.
On 8/21/2025 12:36 PM, Richard Heathfield wrote:
On 21/08/2025 18:20, olcott wrote:
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
<snip>
When I apply a simulating halt decider in both
cases we get the same result.
Is it then your claim that you have a universal halt decider?
Because you don't.
I never claimed and always disavowed that I
have a universal decider and that I am rebutting
the halting problem.
That's what I thought. Glad to have it confirmed.
So when you claim to have a halt decider, you mean it only
works sometimes, like this one does:
Because most people get confused by the term
"partial halt decider" yet understand the gist
of the idea of a halt decider (determines halt status)
I use the less precisely accurate term.
int usuallyrighthaltdecider(const char **src, size_t nlines)
{
return 1;
}
At most I have a partial halt decider that refutes
the conventional proof of the halting problem
No, it doesn't. The conventional proof of the halting problem
reasons about a hypothetical /universal/ halt decider (which it
proves cannot exist).
I prove that the proofs do not prove their point.
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>>>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate. HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does /not/ return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
Since HHH_embedded(DD) does not terminate and return 0, whereas HHH_toplevel(DD) does so, they are different algorithms.
The whole contraption is confirming that HHH_embedded(DD) is not
correctly deciding the halting of DD.
HHH_toplevel is correct, but irrelevant.
Above you've admitted that you've not found a way to show that
HHH_toplevel is correct without the static data; i.e. a way to show it
in any situation in which HHH_toplevel and HHH_embedded are exactly the
same function, not changing their behavior to split into two.
Yet, until you find that way, your claim that you have disproved
the Halting Theorem has not been confirmed.
The Theorem says that what you are looking for is impossible,
and has unassailable logic.
You cannot make those two deciders the same. It is impossible
for HHH_embedded(DD) not to be wrong, and so if the same
expression is tested outside of the test case, it must yield
the same wrong result.
If the same expression HHH(DD) is yielding different behaviors
and results in different contexts, your apparatus is broken.
A non-broken version of the apparatus cannot exist in such a way that it refutes Halting.
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:DD correctly simulated by HHH cannot possibly ever stop running (not
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:None-the-less correct analysis of this text does prove that HHH(DD)==0
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:I know that. You taught me that.
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of theCite your sources.
input you describe,
I have been studying this for 22 years and never saw a proof that >>>>>>> did not require an input to do or say the opposite of what its
decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>> certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable state
with another running implementation of the decider".)
I don't currently know how to change my code so that HHH can see the >>>>> recursive simulation execution traces of DD without the use of
static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate.
HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does
/not/
return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
counting OOM error) unless aborted.
You must understand a little of my x86utm operating system architecture
to even understand that HHH can simulate an instance of itself
simulating an instance of DD when its own instance of DD calls HHH(DD).
Since HHH_embedded(DD) does not terminate and return 0, whereas
HHH_toplevel(DD) does so, they are different algorithms.
The whole contraption is confirming that HHH_embedded(DD) is not
correctly deciding the halting of DD.
HHH_toplevel is correct, but irrelevant.
Above you've admitted that you've not found a way to show that
HHH_toplevel is correct without the static data; i.e. a way to show it
in any situation in which HHH_toplevel and HHH_embedded are exactly the
same function, not changing their behavior to split into two.
Yet, until you find that way, your claim that you have disproved the
Halting Theorem has not been confirmed.
The Theorem says that what you are looking for is impossible,
and has unassailable logic.
You cannot make those two deciders the same. It is impossible for
HHH_embedded(DD) not to be wrong, and so if the same expression is
tested outside of the test case, it must yield the same wrong result.
If the same expression HHH(DD) is yielding different behaviors and
results in different contexts, your apparatus is broken.
A non-broken version of the apparatus cannot exist in such a way that
it refutes Halting.
All Five LLM systems figured out on their own that HHH(DD)==0 would be correct because DD correctly simulated by HHH cannot possibly halt.
If you don't understand that DD correctly simulated by HHH cannot
possibly halt, then you don't understand my code well enough.
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:Changes the input.
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of theCite your sources.
input you
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>> certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate.
HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does /not/
return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
DD correctly simulated by HHH
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>>>>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>> certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate.
HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does /not/
return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
DD correctly simulated by HHH cannot possibly
ever stop running (not counting OOM error) unless
aborted.
You must understand a little of my x86utm operating
system architecture to even understand that HHH
can simulate an instance of itself simulating an
instance of DD when its own instance of DD calls
HHH(DD).
Your code is bullshit, people don't want to invest too much time in understanding bullshit.
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>>> certain decider. Which decider it contains does not vary with the >>>>>>> decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have >>>>>>> elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km >>>>> footrace in under 37 minutes without cutting the course, so for now, >>>>> until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate.
HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does /not/ >>> return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
DD correctly simulated by HHH cannot possibly
ever stop running (not counting OOM error) unless
aborted.
You must understand a little of my x86utm operating
system architecture to even understand that HHH
can simulate an instance of itself simulating an
instance of DD when its own instance of DD calls
HHH(DD).
Yes it /can/. Your architecture supports it. Only problem is that when
you do it cleanly, you run into nontermination,
and so you diddled HHH
with static data that changes. Yet you're still equivocating on it, describing with language that reveals a belief that there is only
one HHH. That's what your "instance of itself" phrase in your
above paragraph is doing.
When you have the mutating static data whose value alters the
control flow in HHH, there is no "itself" any more.
The top level HHH is
not simulating "and instance of itself" when it simulates DDD, because
the HHH called by DDD is no longer equivalent to itself.
Without the static variable cheating, your UTM system is just an elaborate monument to the Halting Theorem.
With the static variable cheating, it is inescapably such a monument;
only you're falsly claiming that it isn't.
On 2025-08-21, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:Counter-factual.
Your code is bullshit, people don't want to invest too much time in
understanding bullshit.
But we already have a decent understanding of it. It's not rocket
science.
The code does what Peter says it does. HHH(DD) simulates DD and
finds non-termination.
Unfortunately, he claims that by doing so it is simulating
"an instance of itself" which is false; the HHH(DD) call inside
DD is a different HHH
which does not correctly simulate DD.
Peter does not say that it does; he admits that it is running
away with recursion and not terminating.
The crazy part is believing that there is only one HHH such that it can
be simultaneously true that HHH(DD) stops and returns 0, yet exactly the
same expression HHH(DD) does not stop.
He knows that a mutable static variable is responsible for the
discrepancy which makes this actually happen in his implementation, and
that he's failed to find a way to get rid of it.
Yet, no problem; pay no attention to that little problem, weee, HHH
correctly simulates an /instance of /itself// and aborts, yadda yadda.
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
On 2025-08-21, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
Your code is bullshit, people don't want to invest too much time in
understanding bullshit.
But we already have a decent understanding of it. It's not rocket
science.
The code does what Peter says it does. HHH(DD) simulates DD and
finds non-termination.
Unfortunately, he claims that by doing so it is simulating
"an instance of itself" which is false; the HHH(DD) call inside
DD is a different HHH
which does not correctly simulate DD.Counter-factual.
Peter does not say that it does; he admits that it is running
away with recursion and not terminating.
The crazy part is believing that there is only one HHH such that it can
be simultaneously true that HHH(DD) stops and returns 0, yet exactly the
same expression HHH(DD) does not stop.
That would be crazy until you understand that it has
always only been the behavior of the input that counts.
Turing machine deciders only compute the mapping
from their inputs...
DD simulated by HHH is BEFORE any DD has had its
simulation aborted.
Directly executed DD() is AFTER DD has had its
simulation aborted.
HHH(DD) maps its input to DD correctly simulated
by HHH and reports the same result regardless of
its execution context.
DD that need not be a computable function has different
behavior depending on its process context.
He knows that a mutable static variable is responsible for the
discrepancy which makes this actually happen in his implementation, and
that he's failed to find a way to get rid of it.
The behavior of DD correctly simulated by HHH remains
the same non-halting behavior. Without the static data
the current HHH cannot see this behavior.
On 2025-08-21 15:26, olcott wrote:
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
On 2025-08-21, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:Counter-factual.
Your code is bullshit, people don't want to invest too much time in
understanding bullshit.
But we already have a decent understanding of it. It's not rocket
science.
The code does what Peter says it does. HHH(DD) simulates DD and
finds non-termination.
Unfortunately, he claims that by doing so it is simulating
"an instance of itself" which is false; the HHH(DD) call inside
DD is a different HHH
which does not correctly simulate DD.
Peter does not say that it does; he admits that it is running
away with recursion and not terminating.
The crazy part is believing that there is only one HHH such that it can
be simultaneously true that HHH(DD) stops and returns 0, yet exactly the >>> same expression HHH(DD) does not stop.
That would be crazy until you understand that it has
always only been the behavior of the input that counts.
Turing machine deciders only compute the mapping
from their inputs...
DD simulated by HHH is BEFORE any DD has had its
simulation aborted.
Directly executed DD() is AFTER DD has had its
simulation aborted.
HHH(DD) maps its input to DD correctly simulated
by HHH and reports the same result regardless of
its execution context.
DD that need not be a computable function has different
behavior depending on its process context.
He knows that a mutable static variable is responsible for the
discrepancy which makes this actually happen in his implementation, and
that he's failed to find a way to get rid of it.
The behavior of DD correctly simulated by HHH remains
the same non-halting behavior. Without the static data
the current HHH cannot see this behavior.
But that means you haven't accomplished what you claim to have
accomplished -- created a decider which correctly decides the Linz counterecxample. Until you come up with an HHH that can see this
behaviour without relying on static data, then you're not demonstrating anything.
André
On 8/21/2025 5:16 PM, André G. Isaak wrote:
On 2025-08-21 15:26, olcott wrote:
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
On 2025-08-21, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:Counter-factual.
Your code is bullshit, people don't want to invest too much time in
understanding bullshit.
But we already have a decent understanding of it. It's not rocket
science.
The code does what Peter says it does. HHH(DD) simulates DD and
finds non-termination.
Unfortunately, he claims that by doing so it is simulating
"an instance of itself" which is false; the HHH(DD) call inside
DD is a different HHH
which does not correctly simulate DD.
Peter does not say that it does; he admits that it is running
away with recursion and not terminating.
The crazy part is believing that there is only one HHH such that it can >>>> be simultaneously true that HHH(DD) stops and returns 0, yet exactly
the
same expression HHH(DD) does not stop.
That would be crazy until you understand that it has
always only been the behavior of the input that counts.
Turing machine deciders only compute the mapping
from their inputs...
DD simulated by HHH is BEFORE any DD has had its
simulation aborted.
Directly executed DD() is AFTER DD has had its
simulation aborted.
HHH(DD) maps its input to DD correctly simulated
by HHH and reports the same result regardless of
its execution context.
DD that need not be a computable function has different
behavior depending on its process context.
He knows that a mutable static variable is responsible for the
discrepancy which makes this actually happen in his implementation, and >>>> that he's failed to find a way to get rid of it.
The behavior of DD correctly simulated by HHH remains
the same non-halting behavior. Without the static data
the current HHH cannot see this behavior.
But that means you haven't accomplished what you claim to have
accomplished -- created a decider which correctly decides the Linz
counterecxample. Until you come up with an HHH that can see this
behaviour without relying on static data, then you're not
demonstrating anything.
André
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
On 2025-08-21 16:25, olcott wrote:
On 8/21/2025 5:16 PM, André G. Isaak wrote:
On 2025-08-21 15:26, olcott wrote:
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
On 2025-08-21, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:Counter-factual.
Your code is bullshit, people don't want to invest too much time in >>>>>> understanding bullshit.
But we already have a decent understanding of it. It's not rocket
science.
The code does what Peter says it does. HHH(DD) simulates DD and
finds non-termination.
Unfortunately, he claims that by doing so it is simulating
"an instance of itself" which is false; the HHH(DD) call inside
DD is a different HHH
which does not correctly simulate DD.
Peter does not say that it does; he admits that it is running
away with recursion and not terminating.
The crazy part is believing that there is only one HHH such that it >>>>> can
be simultaneously true that HHH(DD) stops and returns 0, yet
exactly the
same expression HHH(DD) does not stop.
That would be crazy until you understand that it has
always only been the behavior of the input that counts.
Turing machine deciders only compute the mapping
from their inputs...
DD simulated by HHH is BEFORE any DD has had its
simulation aborted.
Directly executed DD() is AFTER DD has had its
simulation aborted.
HHH(DD) maps its input to DD correctly simulated
by HHH and reports the same result regardless of
its execution context.
DD that need not be a computable function has different
behavior depending on its process context.
He knows that a mutable static variable is responsible for the
discrepancy which makes this actually happen in his implementation, >>>>> and
that he's failed to find a way to get rid of it.
The behavior of DD correctly simulated by HHH remains
the same non-halting behavior. Without the static data
the current HHH cannot see this behavior.
But that means you haven't accomplished what you claim to have
accomplished -- created a decider which correctly decides the Linz
counterecxample. Until you come up with an HHH that can see this
behaviour without relying on static data, then you're not
demonstrating anything.
André
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this result without relying on static data then it doesn't achieve what you have
claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but that
this is not the answer which the putative halt decider gives when given
the unsolvable input constructed from that decider.
André
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this result
without relying on static data then it doesn't achieve what you have
claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but
that this is not the answer which the putative halt decider gives when
given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn). That's a contradiction. You need to specify the conditions under which
each transition occurs. You've been corrected on this many times in the
past and yet you continue to make the same error.
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this
result without relying on static data then it doesn't achieve what
you have claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but
that this is not the answer which the putative halt decider gives
when given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
It only gives one boolean value if it gives an answer at all. The only
way for it to give the opposite boolean value is for you to redesign the
TM in which case you are no longer dealing with the same H/D pair.
André
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn). That's a contradiction. You need to specify the conditions under which each transition occurs. You've been corrected on this many times in the past and yet you continue to make the same error.
That is all in the Linz proof https://www.liarparadox.org/Peter_Linz_HP_317-320.pdfAre you capable of writing a TM that computes the length of its input?
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this
result without relying on static data then it doesn't achieve what
you have claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but that this is not the answer which the putative halt decider gives
when given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
It only gives one boolean value if it gives an answer at all. The only
way for it to give the opposite boolean value is for you to redesign the TM in which case you are no longer dealing with the same H/D pair.
André
If I ask you a question and you answer yes--- Synchronet 3.21a-Linux NewsLink 1.2
or you answer no you are not two distinctly
separate human beings.
On Thu, 2025-08-21 at 18:17 -0500, olcott wrote:
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn). That's a contradiction. You need to specify the conditions under which each transition occurs. You've been corrected on this many times in the past and yet you continue to make the same error.
Are you capable of writing a TM that computes 1+2?That is all in the Linz proof https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
Are you capable of writing a TM that computes the length of its input?
I don't think so.
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this result without relying on static data then it doesn't achieve what you have claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but that this is not the answer which the putative halt decider gives when given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
It only gives one boolean value if it gives an answer at all. The only way for it to give the opposite boolean value is for you to redesign the TM in which case you are no longer dealing with the same H/D pair.
André
--- Synchronet 3.21a-Linux NewsLink 1.2If I ask you a question and you answer yes
or you answer no you are not two distinctly
separate human beings.
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn).
That's a contradiction. You need to specify the conditions under which
each transition occurs. You've been corrected on this many times in
the past and yet you continue to make the same error.
That is all in the Linz proof https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this
result without relying on static data then it doesn't achieve what
you have claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but
that this is not the answer which the putative halt decider gives
when given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
It only gives one boolean value if it gives an answer at all. The only
way for it to give the opposite boolean value is for you to redesign
the TM in which case you are no longer dealing with the same H/D pair.
André
If I ask you a question and you answer yes
or you answer no you are not two distinctly
separate human beings.
On 2025-08-21 17:17, olcott wrote:
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn). >>> That's a contradiction. You need to specify the conditions under
which each transition occurs. You've been corrected on this many
times in the past and yet you continue to make the same error.
That is all in the Linz proof
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
So include the relevant conditions in your notation or you're not saying anything meaningful. The conditions are an integral part of the notation.
What is the point of using a notation if you're not going to use it correctly?
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this
result without relying on static data then it doesn't achieve what
you have claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but
that this is not the answer which the putative halt decider gives
when given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
It only gives one boolean value if it gives an answer at all. The
only way for it to give the opposite boolean value is for you to
redesign the TM in which case you are no longer dealing with the same
H/D pair.
André
If I ask you a question and you answer yes
or you answer no you are not two distinctly
separate human beings.
People aren't turing machines. And I can only give one answer on a given occasion.
André
On 8/21/2025 7:22 PM, André G. Isaak wrote:
On 2025-08-21 17:17, olcott wrote:
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn).
That's a contradiction. You need to specify the conditions under
which each transition occurs. You've been corrected on this many
times in the past and yet you continue to make the same error.
That is all in the Linz proof https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
So include the relevant conditions in your notation or you're not saying anything meaningful. The conditions are an integral part of the notation.
What is the point of using a notation if you're not going to use it correctly?
I am using it correctly.Are you capable or writing a TM that computes 1+2?
The proof isn't using it incorrectly.
On Thu, 2025-08-21 at 19:40 -0500, olcott wrote:
On 8/21/2025 7:22 PM, André G. Isaak wrote:
On 2025-08-21 17:17, olcott wrote:
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn). >>>>> That's a contradiction. You need to specify the conditions under
which each transition occurs. You've been corrected on this many
times in the past and yet you continue to make the same error.
That is all in the Linz proof
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
So include the relevant conditions in your notation or you're not saying >>> anything meaningful. The conditions are an integral part of the notation. >>>
What is the point of using a notation if you're not going to use it
correctly?
I am using it correctly.
The proof isn't using it incorrectly.
Are you capable or writing a TM that computes 1+2?
I don't think you can!
On 8/21/2025 7:54 PM, wij wrote:
On Thu, 2025-08-21 at 19:40 -0500, olcott wrote:
On 8/21/2025 7:22 PM, André G. Isaak wrote:
On 2025-08-21 17:17, olcott wrote:
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn).
That's a contradiction. You need to specify the conditions under which each transition occurs. You've been corrected on this many times in the past and yet you continue to make the same error.
That is all in the Linz proof https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
So include the relevant conditions in your notation or you're not saying
anything meaningful. The conditions are an integral part of the notation.
What is the point of using a notation if you're not going to use it correctly?
I am using it correctly.
The proof isn't using it incorrectly.
Are you capable or writing a TM that computes 1+2?
I don't think you can!
https://www.lns.mit.edu/~dsw/turing/turing.htmlThat words is said from experts' mouth, not you.
It is easy to reimplement his design extending
it to much more memory.
He already had code written for adders. https://www.lns.mit.edu/~dsw/turing/examples/examples.htmlOK, Let's change it to:
On Thu, 2025-08-21 at 20:03 -0500, olcott wrote:
On 8/21/2025 7:54 PM, wij wrote:
On Thu, 2025-08-21 at 19:40 -0500, olcott wrote:
On 8/21/2025 7:22 PM, André G. Isaak wrote:
On 2025-08-21 17:17, olcott wrote:
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn). >>>>>>> That's a contradiction. You need to specify the conditions under >>>>>>> which each transition occurs. You've been corrected on this many >>>>>>> times in the past and yet you continue to make the same error.
That is all in the Linz proof
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
So include the relevant conditions in your notation or you're not saying >>>>> anything meaningful. The conditions are an integral part of the notation. >>>>>
What is the point of using a notation if you're not going to use it
correctly?
I am using it correctly.
The proof isn't using it incorrectly.
Are you capable or writing a TM that computes 1+2?
I don't think you can!
https://www.lns.mit.edu/~dsw/turing/turing.html
It is easy to reimplement his design extending
it to much more memory.
That words is said from experts' mouth, not you.
And we know you don't know how to use it. You just copy words.
He already had code written for adders.
https://www.lns.mit.edu/~dsw/turing/examples/examples.html
OK, Let's change it to:
Q: Write a TM that computes the length of its input in 3-ary number notation?
I don't think you can?
On 8/21/2025 12:46 PM, Mr Flibble wrote:
On Thu, 21 Aug 2025 12:45:19 -0500, olcott wrote:
On 8/21/2025 12:36 PM, Richard Heathfield wrote:
On 21/08/2025 18:20, olcott wrote:Because most people get confused by the term "partial halt decider" yet
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
<snip>
I never claimed and always disavowed that I have a universal decider >>>>> and that I am rebutting the halting problem.When I apply a simulating halt decider in both cases we get the same >>>>>>> result.
Is it then your claim that you have a universal halt decider? Because >>>>>> you don't.
That's what I thought. Glad to have it confirmed.
So when you claim to have a halt decider, you mean it only works
sometimes, like this one does:
understand the gist of the idea of a halt decider (determines halt
status)
I use the less precisely accurate term.
int usuallyrighthaltdecider(const char **src, size_t nlines)I prove that the proofs do not prove their point.
{
return 1;
}
At most I have a partial halt decider that refutes the conventional
proof of the halting problem
No, it doesn't. The conventional proof of the halting problem reasons
about a hypothetical /universal/ halt decider (which it proves cannot
exist).
You haven't proved shit in 22 years.
/Flibble
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Repeats until aborted
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
I proved that Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct
even if Ĥ.embedded_H cannot detect the repeating state.
That people continue to believe that Ĥ applied to ⟨Ĥ⟩
contradicts that merely shows how the power of
indoctrination can get people to actually deny
verified facts:
Turing machine deciders only compute the mapping
from their inputs...
On 8/21/2025 3:57 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the >>>>>>>>>> input youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>>>> certain decider. Which decider it contains does not vary with the >>>>>>>> decider being applied to that input.
The embedded decider may be a clean-room implementation of the >>>>>>>> algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have >>>>>>>> elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km >>>>>> footrace in under 37 minutes without cutting the course, so for now, >>>>>> until I find better training methods, I hope you all don't mind me >>>>>> getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate. >>>> HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does /
not/
return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
DD correctly simulated by HHH cannot possibly
ever stop running (not counting OOM error) unless
aborted.
You must understand a little of my x86utm operating
system architecture to even understand that HHH
can simulate an instance of itself simulating an
instance of DD when its own instance of DD calls
HHH(DD).
Yes it /can/. Your architecture supports it. Only problem is that when
you do it cleanly, you run into nontermination,
Hence proving that HHH(DD)==0 is correct.
and so you diddled HHH
with static data that changes. Yet you're still equivocating on it,
describing with language that reveals a belief that there is only
one HHH. That's what your "instance of itself" phrase in your
above paragraph is doing.
There is only one HHH, the rest are data manipulated
by this one HHH.
When you have the mutating static data whose value alters the
control flow in HHH, there is no "itself" any more.
*It does not alter the control flow during the simulation*
It merely recognizes that DD correctly simulated
by HHH cannot possibly stop running without being
aborted and then aborts DD preventing an OOM error.
The top level HHH is
not simulating "and instance of itself" when it simulates DDD, because
the HHH called by DDD is no longer equivalent to itself.
When we abandon the static data that fact that DD()
never halts proves that HHH(DD)==0 is correct.
Without the static variable cheating, your UTM system is just an
elaborate
monument to the Halting Theorem.
No one else ever figured out any way that HHH(DD)==0 is
correct. Now all that I need to do is find a way for HHH
to detect the repeating state of its input that everyone
else can see.
It is great talking to you about these things because
I know that you are competent and not playing Trollish
head games like most of the reviewers on this forum.
With the static variable cheating, it is inescapably such a monument;
only you're falsly claiming that it isn't.
On 8/21/2025 5:40 PM, André G. Isaak wrote:That’s still a tautology: „HHH simulates DD the way it does it”. The
On 2025-08-21 16:25, olcott wrote:
On 8/21/2025 5:16 PM, André G. Isaak wrote:
On 2025-08-21 15:26, olcott wrote:
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
HHH(DD) maps its input to DD correctly simulated by HHH and reports
the same result regardless of its execution context.
As a C function DD is most certainly computable. You should make theDD that need not be a computable function has different behavior
depending on its process context.
That is indication of a bug.He knows that a mutable static variable is responsible for theThe behavior of DD correctly simulated by HHH remains the same
discrepancy which makes this actually happen in his implementation, >>>>>> and that he's failed to find a way to get rid of it.
non-halting behavior. Without the static data the current HHH cannot >>>>> see this behavior.
That you do not understand the notation does not entail that it is meaningless.Explain it.
No, DD definitely halts, and HHH could just return that.No. The proofs all claim that there is a single correct answer but thatAKA both Boolean values that it gives are the wrong answer. Every yes/no having no correct yes/no answer (within the full context of the question
this is not the answer which the putative halt decider gives when given
the unsolvable input constructed from that decider.
that includes who is being asked) is an incorrect question.
No, DD definitely halts, and HHH could just return that.
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is concerned is >>> his inability to recognise the difference between (and/or his conflation >>> of) *execution* with *computation*.
Pete needs a doctor.
I consider that statement defamation of character.
Am 21.08.2025 um 17:06 schrieb olcott:
On 8/21/2025 8:37 AM, Bonita Montero wrote:
Am 08.08.2025 um 00:01 schrieb Mr Flibble:
Olcott's major malfunction as far as the Halting Problem is
concerned is
his inability to recognise the difference between (and/or his
conflation
of) *execution* with *computation*.
Pete needs a doctor.
I consider that statement defamation of character.
What you keep saying here is delusional.
You need a doctor to get out of that.
Others shouldn't respond to you in your sense at all.
That you cannot even find a mistake in what I say
Am Thu, 21 Aug 2025 17:53:41 -0500 schrieb olcott:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
On 8/21/2025 5:16 PM, André G. Isaak wrote:
On 2025-08-21 15:26, olcott wrote:
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
That’s still a tautology: „HHH simulates DD the way it does it”. The same applies to the null simulator we showed you.HHH(DD) maps its input to DD correctly simulated by HHH and reports >>>>>> the same result regardless of its execution context.
DD that need not be a computable function has different behavior
depending on its process context.
As a C function DD is most certainly computable. You should make the
context explicit.
He knows that a mutable static variable is responsible for theThe behavior of DD correctly simulated by HHH remains the same
discrepancy which makes this actually happen in his implementation, >>>>>>> and that he's failed to find a way to get rid of it.
non-halting behavior. Without the static data the current HHH cannot >>>>>> see this behavior.
That is indication of a bug.
That you do not understand the notation does not entail that it is
meaningless.
Explain it.
No. The proofs all claim that there is a single correct answer but thatAKA both Boolean values that it gives are the wrong answer. Every yes/no
this is not the answer which the putative halt decider gives when given
the unsolvable input constructed from that decider.
having no correct yes/no answer (within the full context of the question
that includes who is being asked) is an incorrect question.
No, DD definitely halts, and HHH could just return that.
On 8/22/2025 3:15 AM, joes wrote:
On 2025-08-21 15:26, olcott wrote:
The behavior of DD correctly simulated by HHH remains the
same
non-halting behavior. Without the static data the current
HHH cannot
see this behavior.
That is indication of a bug.
It is not a bug. It is perfectly legitimate in
and does its job in C.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // input halts state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // does not halt state
On 22/08/2025 09:15, joes wrote:
<snip>
No, DD definitely halts, and HHH could just return that.
Because HH returns 0 DD, the C function (to distinguish it from its pale simulated shadow), unquestioningly and indubitably halts. HHH ought to report this by returning 1, but if it does so, DD, the C function, no
longer halts. HHH has an impossible task; whatever it decides is wrong.
Olcott's position appears to be that whatever the simulation does is the right answer /by definition/, and that the actual code of DD (which it largely ignores) is neither here not there because, being invisible to
HHH, it is never simulated.
I am not able rightly to apprehend the kind of confusion of ideas that
could provoke such a position.
On 2025-08-22 08:29, olcott wrote:
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // input halts state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // does not halt state
OK. Now you're at least adding something to suggest when Ĥ.q0
transitions to Ĥ.∞ and when it transitions to Ĥ.qn, but you're adding your conditions as comments. These are not comments, they are a required part of the notation. You always need to include the conditions.
On its own, a line like
On 8/22/2025 3:35 AM, Richard Heathfield wrote:
On 22/08/2025 09:15, joes wrote:
<snip>
No, DD definitely halts, and HHH could just return that.
Because HH returns 0 DD, the C function (to distinguish it from
its pale simulated shadow), unquestioningly and indubitably
halts. HHH ought to report this by returning 1, but if it does
so, DD, the C function, no longer halts. HHH has an impossible
task; whatever it decides is wrong.
Olcott's position appears to be that whatever the simulation
does is the right answer /by definition/, and that the actual
code of DD (which it largely ignores) is neither here not there
because, being invisible to HHH, it is never simulated.
I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a position.
Turing machine deciders only compute the mapping
from their inputs...
It was always a confused mistake to assume the Dennis Bush
position that a halt decider must report on the behavior
of the non-input direct execution of M applied to ⟨M⟩.
HHH and HHH1 have identical source-code according to diff.
HHH(DD)==0 and HHH1(DD)==1 are both correct and the difference
is accounted for in that DD is being simulated in two different
process contexts.
On 8/22/2025 10:29 AM, olcott wrote:
HHH and HHH1 have identical source-code according to diff.
So HHH and HHH1 are using two different static variables for
execution_trace
HHH(DD)==0 and HHH1(DD)==1 are both correct and the difference
is accounted for in that DD is being simulated in two different
process contexts.
In other words, when HHH1 simulates DD it simulates DD calling
HHH(DD,<empty execution trace>) which is correct, but when HHH simulates
DD it simulates DD calling HHH(DD,<non-empty execution trace>) which
changes the input.
1) Changing the input is not allowed
2) That HHH (and HHH1) takes an execution trace as input means it is DISQUALIFIED from being a halt decider / termination analyzer
On 8/22/2025 3:35 AM, Richard Heathfield wrote:
On 22/08/2025 09:15, joes wrote:
<snip>
No, DD definitely halts, and HHH could just return that.
Because HH returns 0 DD, the C function (to distinguish it from its
pale simulated shadow), unquestioningly and indubitably halts. HHH
ought to report this by returning 1, but if it does so, DD, the C
function, no longer halts. HHH has an impossible task; whatever it
decides is wrong.
Olcott's position appears to be that whatever the simulation does is
the right answer /by definition/, and that the actual code of DD
(which it largely ignores) is neither here not there because, being
invisible to HHH, it is never simulated.
I am not able rightly to apprehend the kind of confusion of ideas that
could provoke such a position.
Turing machine deciders only compute the mapping
from their inputs...
It was always a confused mistake to assume the Dennis Bush
position that a halt decider must report on the behavior
of the non-input direct execution of M applied to ⟨M⟩.
On 8/19/2025 4:42 PM, dbush wrote:--- Synchronet 3.21a-Linux NewsLink 1.2
His argument is that the decision that X(Y) is making is not "does
algorithm Y halt", but basically "does there exist an implementation
of function X that can simulate function call Y() to completion?"
Yes.
This happens to coincide with the halting function in cases where
Yes
function Y does not call function X at some point, but not in cases
where it does.
On 8/22/2025 12:14 PM, dbush wrote:
On 8/22/2025 10:29 AM, olcott wrote:
HHH and HHH1 have identical source-code according to diff.
So HHH and HHH1 are using two different static variables for
execution_trace
HHH(DD)==0 and HHH1(DD)==1 are both correct and the difference
is accounted for in that DD is being simulated in two different
process contexts.
In other words, when HHH1 simulates DD it simulates DD calling
HHH(DD,<empty execution trace>) which is correct, but when HHH
simulates DD it simulates DD calling HHH(DD,<non-empty execution
trace>) which changes the input.
1) Changing the input is not allowed
2) That HHH (and HHH1) takes an execution trace as input means it is
DISQUALIFIED from being a halt decider / termination analyzer
When we get rid of the static data HHH1(DD) and HHH(DD)
remains stuck in recursive simulation until OOM error
proving that HHH(DD)==0 is correct.
On 8/21/2025 12:46 PM, Mr Flibble wrote:
On Thu, 21 Aug 2025 12:45:19 -0500, olcott wrote:
On 8/21/2025 12:36 PM, Richard Heathfield wrote:
On 21/08/2025 18:20, olcott wrote:Because most people get confused by the term "partial halt decider" yet
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
<snip>
I never claimed and always disavowed that I have a universal decider >>>>> and that I am rebutting the halting problem.When I apply a simulating halt decider in both cases we get the same >>>>>>> result.
Is it then your claim that you have a universal halt decider? Because >>>>>> you don't.
That's what I thought. Glad to have it confirmed.
So when you claim to have a halt decider, you mean it only works
sometimes, like this one does:
understand the gist of the idea of a halt decider (determines halt
status)
I use the less precisely accurate term.
int usuallyrighthaltdecider(const char **src, size_t nlines)I prove that the proofs do not prove their point.
{
return 1;
}
At most I have a partial halt decider that refutes the conventional
proof of the halting problem
No, it doesn't. The conventional proof of the halting problem reasons
about a hypothetical /universal/ halt decider (which it proves cannot
exist).
You haven't proved shit in 22 years.
/Flibble
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Repeats until aborted
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
I proved that Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct
even if Ĥ.embedded_H cannot detect the repeating state.
That people continue to believe that Ĥ applied to ⟨Ĥ⟩
contradicts that merely shows how the power of
indoctrination can get people to actually deny
verified facts:
Turing machine deciders only compute the mapping
from their inputs...
On 8/22/2025 10:18 AM, André G. Isaak wrote:
On 2025-08-22 08:29, olcott wrote:
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // input halts state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // does not halt state
OK. Now you're at least adding something to suggest when Ĥ.q0
transitions to Ĥ.∞ and when it transitions to Ĥ.qn, but you're adding >> your conditions as comments. These are not comments, they are a
required part of the notation. You always need to include the conditions.
On its own, a line like
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
When ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H
reaches its own simulated final halt state of ⟨Ĥ.qn⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H cannot
possibly reach its own simulated final halt state of ⟨Ĥ.qn⟩.
<snip>
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 146:18:07 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,935 |
| D/L today: |
22 files (1,452K bytes) |
| Messages: | 2,410,869 |