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.
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
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.
The halting problem proofs depend on the assumption
that there is an H/D pair such that D is undecidable by H.
On 8/19/2025 8: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".
It is a fact that the input to HHH(DD) does not
halt thus when HHH reports on this fact it is
correct in every possible way.
HHH is deciding on the behavior of:
DD simulated by HHH that calls HHH(DD)
that simulates DD that calls HHH(DD)...
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 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.
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.
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.
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).
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.
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 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.
DD correctly simulated by HHH *is* the halting problem
input/decider pair.
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.
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 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.
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 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 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 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 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 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 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/19/2025 9:14 PM, Richard Heathfield wrote:
On 20/08/2025 03:09, olcott wrote:
The halting problem proofs depend on the assumption
that there is an H/D pair such that D is undecidable by H.
No, they depend on the assumption that D /is/ decidable by H,
for all D. They then show that the assumption must be false.
Until H does correctly decide that D.
I am not refuting the halting problem.The conventional HP proofs assume that a decider exists and then
I am showing the the conventional proofs do prove
their conclusion.
On 8/26/2025 12:52 PM, Richard Heathfield wrote:
On 26/08/2025 18:47, olcott wrote:
<snip>
I am not refuting the halting problem.The conventional HP proofs assume that a decider exists and
I am showing the the conventional proofs do prove
their conclusion.
then demonstrate than a program can be constructed that the
decider cannot decide,
Until this same decider does correctly decide this same input.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 12:24:27 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,061 |
| Messages: | 6,416,717 |