On 8/23/2025 11:41 AM, Mr Flibble wrote:
On Sat, 23 Aug 2025 11:23:51 -0500, olcott wrote:
On 8/23/2025 10:33 AM, Mr Flibble wrote:
On Sat, 23 Aug 2025 10:25:29 -0500, olcott wrote:
On 8/23/2025 9:26 AM, Bonita Montero wrote:
Am 23.08.2025 um 16:16 schrieb olcott:
The actual case is that you are too f-cking stupid to find any
mistake in my work.
I wonder why one has to pursue such a question so paranoidly for
years.
I mean, it's nothing that has practical relevance. And I can't
understand why others here are arguing so vehemently against it.
It's obvious that Pete is crazy. It's best not to respond at all,
then maybe it will calm down.
The analog of the technology applied to the HP proofs equally
applies to the Tarski Undecidability theorem thus enabling a Boolean >>>>> True(Language L, Expression E)
to return TRUE for all expressions E of language L that are proven
true on the basis of their meaning.
True("English", "Donald Trump lied about election fraud")==TRUE
True("English", "Severe climate change is caused by humans")==TRUE
True("English", "Halting Problem proofs have not been refuted by
Olcott")==TRUE
/Flibble
True("English",
"Halting Problem proofs have not"
"yet been completely refuted by Olcott")==TRUE
*This is proven entirely true on the sole basis of its meaning*
When 0 to ∞ instructions of DD are correctly simulated by HHH this
simulated DD never reaches its own simulated "return" statement final
halt state.
The simulated DD may never reach its final state but nobody cares about
what your simulation does,
*Unless they pay attention to this*
Turing machine deciders only compute the mapping from their inputs...
and also realize that DD correctly simulated by HHH does correctly
measure the actual behavior actually specified by the actual input...
what actually matters is what HHH reports (and
Not at all. Not in the least little bit.
What matters is what HHH(DD) should report on the basis of the actual behavior that the actual input actually specifies as correctly measured
by DD correctly simulated by HHH.
Thus we can know that HHH(DD)==0 is correct.
On 8/23/2025 12:01 PM, Mr Flibble wrote:
On Sat, 23 Aug 2025 11:56:28 -0500, olcott wrote:Because that would be false.
On 8/23/2025 11:41 AM, Mr Flibble wrote:
On Sat, 23 Aug 2025 11:23:51 -0500, olcott wrote:
On 8/23/2025 10:33 AM, Mr Flibble wrote:
On Sat, 23 Aug 2025 10:25:29 -0500, olcott wrote:
On 8/23/2025 9:26 AM, Bonita Montero wrote:True("English", "Halting Problem proofs have not been refuted by
Am 23.08.2025 um 16:16 schrieb olcott:
The actual case is that you are too f-cking stupid to find any >>>>>>>>> mistake in my work.
I wonder why one has to pursue such a question so paranoidly for >>>>>>>> years.
I mean, it's nothing that has practical relevance. And I can't >>>>>>>> understand why others here are arguing so vehemently against it. >>>>>>>> It's obvious that Pete is crazy. It's best not to respond at all, >>>>>>>> then maybe it will calm down.
The analog of the technology applied to the HP proofs equally
applies to the Tarski Undecidability theorem thus enabling a
Boolean True(Language L, Expression E)
to return TRUE for all expressions E of language L that are proven >>>>>>> true on the basis of their meaning.
True("English", "Donald Trump lied about election fraud")==TRUE
True("English", "Severe climate change is caused by humans")==TRUE >>>>>>
Olcott")==TRUE
/Flibble
True("English",
"Halting Problem proofs have not"
"yet been completely refuted by Olcott")==TRUE
*This is proven entirely true on the sole basis of its meaning*
When 0 to ∞ instructions of DD are correctly simulated by HHH this >>>>> simulated DD never reaches its own simulated "return" statement
final halt state.
The simulated DD may never reach its final state but nobody cares
about what your simulation does,
*Unless they pay attention to this*
Turing machine deciders only compute the mapping from their inputs...
and also realize that DD correctly simulated by HHH does correctly
measure the actual behavior actually specified by the actual input...
what actually matters is what HHH reports (and
Not at all. Not in the least little bit.
It is all that matters as far as the Halting Problem is concerned: a
halt decider must report a decision to its caller. Why don't you just
admit that you are not working on the Halting Problem and its proofs at
all?
What matters is what HHH(DD) should report on the basis of the actual
behavior that the actual input actually specifies as correctly
measured by DD correctly simulated by HHH.
Thus we can know that HHH(DD)==0 is correct.
If HHH(DD) reports non-halting to its CALLER, DD(), then DD() will halt
thus confirming that HHH gave the incorrect answer and that the extant
Haling Problem proofs remain unrefuted by you.
/Flibble
Do I need to repeat this 100 million times before you ever notice that I
said it at least once?
Turing machine deciders only compute the mapping from their inputs..
On 8/23/2025 12:07 PM, Mr Flibble wrote:
On Sat, 23 Aug 2025 12:04:00 -0500, olcott wrote:
Turing machine deciders only compute the mapping from their
inputs..
How many times must I repeat to you that DD(), the caller of
HHH, should
pass a *description* of itself to HHH; it is quite valid for DD
to take on
two roles: caller and input.
/Flibble
In the same way that when Bill's identical twin brother
Bob robs a liquor store that Bill is equally guilty
because he looks the same as Bob.
On 8/23/2025 12:17 PM, dbush wrote:
On 8/23/2025 1:04 PM, olcott wrote:
On 8/23/2025 12:01 PM, Mr Flibble wrote:
On Sat, 23 Aug 2025 11:56:28 -0500, olcott wrote:
On 8/23/2025 11:41 AM, Mr Flibble wrote:
On Sat, 23 Aug 2025 11:23:51 -0500, olcott wrote:
On 8/23/2025 10:33 AM, Mr Flibble wrote:
On Sat, 23 Aug 2025 10:25:29 -0500, olcott wrote:
On 8/23/2025 9:26 AM, Bonita Montero wrote:True("English", "Halting Problem proofs have not been refuted by >>>>>>>> Olcott")==TRUE
Am 23.08.2025 um 16:16 schrieb olcott:
The actual case is that you are too f-cking stupid to find any >>>>>>>>>>> mistake in my work.
I wonder why one has to pursue such a question so paranoidly for >>>>>>>>>> years.
I mean, it's nothing that has practical relevance. And I can't >>>>>>>>>> understand why others here are arguing so vehemently against it. >>>>>>>>>> It's obvious that Pete is crazy. It's best not to respond at all, >>>>>>>>>> then maybe it will calm down.
The analog of the technology applied to the HP proofs equally >>>>>>>>> applies to the Tarski Undecidability theorem thus enabling a >>>>>>>>> Boolean
True(Language L, Expression E)
to return TRUE for all expressions E of language L that are proven >>>>>>>>> true on the basis of their meaning.
True("English", "Donald Trump lied about election fraud")==TRUE >>>>>>>>> True("English", "Severe climate change is caused by humans")==TRUE >>>>>>>>
/Flibble
True("English",
"Halting Problem proofs have not"
"yet been completely refuted by Olcott")==TRUE
*This is proven entirely true on the sole basis of its meaning*
When 0 to ∞ instructions of DD are correctly simulated by HHH this >>>>>>> simulated DD never reaches its own simulated "return" statement
final
halt state.
The simulated DD may never reach its final state but nobody cares
about
what your simulation does,
*Unless they pay attention to this*
Turing machine deciders only compute the mapping from their inputs... >>>>>
and also realize that DD correctly simulated by HHH does correctly
measure the actual behavior actually specified by the actual input... >>>>>
what actually matters is what HHH reports (and
Not at all. Not in the least little bit.
It is all that matters as far as the Halting Problem is concerned: a
halt
decider must report a decision to its caller. Why don't you just admit >>>> that you are not working on the Halting Problem and its proofs at all? >>>>
Because that would be false.
Yet you claimed the opposite as shown below:
Liar
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/23/2025 12:46 PM, Waldek Hebisch wrote:
In comp.lang.c Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 23.08.2025 um 16:41 schrieb Richard Heathfield:
On 23/08/2025 15:26, Bonita Montero wrote:
Am 23.08.2025 um 16:16 schrieb olcott:
The actual case is that you are too f-cking
stupid to find any mistake in my work.
I wonder why one has to pursue such a question so paranoidly
for years. I mean, it's nothing that has practical relevance.
I beg your pardon?
If he's right, the conventional proof of the undecidability of the
Halting Problem is flawed. You don't think that matters?
That has no practical relevance.
It has more relevance than you want to admit. If Pete had working
halting decider he would not waste time on newsgroups. He would
be making money, possibly as a service to business. Or he would
generate a lot of bitcoins. Or turn to illegal activity, for
example break encryption and use the break to hijack money flowing
in electronic exchanges.
Note that basically one call to halting decider gives you one
bit towards solution of arbitrary problem, with cost depending
only on length of problem description. Few thousends of calls
and you have broken RSA as it is currently used.
But Pete does not have working halting decider, so instead he tries
to get some attention in newsgroups. And that works quite well,
for many years he gets many replies. It is not clear if he has
psychic problem. Maybe he just has fun wasting others time
(which you could argue is a psychic problem too, but relatively
light compared to first alternative).
I have conclusively proved that in the conventional
halting problem proofs the decider H would be correct
to reject its input P on the basis that P correctly
simulated by H cannot possibly reach its own simulated
final halt state.
That people ignore this verified fact as the basis
for denigrating my work and my character is the
kind of reckless disregard for the truth that loses
defamation cases.
On 8/23/2025 12:07 PM, Mr Flibble wrote:
How many times must I repeat to you that DD(), the caller of HHH, should
pass a *description* of itself to HHH; it is quite valid for DD to take on >> two roles: caller and input.
/Flibble
In the same way that when Bill's identical twin brother
Bob robs a liquor store that Bill is equally guilty
because he looks the same as Bob.
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 12:07 PM, Mr Flibble wrote:
How many times must I repeat to you that DD(), the caller of HHH,
should
pass a *description* of itself to HHH; it is quite valid for DD to
take on
two roles: caller and input.
/Flibble
In the same way that when Bill's identical twin brother
Bob robs a liquor store that Bill is equally guilty
because he looks the same as Bob.
That's silly. Two copies (or even different implementations) of exactly
the same algorithm are one and the same in the same way that identical
twins are not.
Not when one of these identical two functions has
an input that calls itself HHH(DD) in recursive
simulation and the other one HHH1(DD) does not have
an input that calls itself in recursive simulation.
In this case it is obvious that DD correctly simulated
by HHH specifies a different sequence of steps than DD
correctly simulated by HHH1.
*Between you and Mike I may actually get closure on this*
I am still working out how HHH(DD) can see the repeating
state of its correct simulation of its input without static
data.
It seems as if your reasoning about entity equivalence has not reached
maturity.
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
That's silly. Two copies (or even different implementations) of exactlyNot when one of these identical two functions has an input that calls
the same algorithm are one and the same in the same way that identical
twins are not.
itself HHH(DD) in recursive simulation and the other one HHH1(DD) does
not have an input that calls itself in recursive simulation.
In this case it is obvious that DD correctly simulated by HHH specifiesI’m not a C programmer, but what’s the problem? What do you need the
a different sequence of steps than DD correctly simulated by HHH1.
*Between you and Mike I may actually get closure on this* I am still
working out how HHH(DD) can see the repeating state of its correct
simulation of its input without static data.
On 8/24/25 1:53 AM, joes wrote:
I’m not a C programmer, but what’s the problem? What do you
need the
static data *for*?
To do something that he can't do without it, his outer simulator
can't figure out what the inner version is doing without its help.
Am Sat, 23 Aug 2025 16:45:30 -0500 schrieb olcott:
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
That's silly. Two copies (or even different implementations) of exactlyNot when one of these identical two functions has an input that calls
the same algorithm are one and the same in the same way that identical
twins are not.
itself HHH(DD) in recursive simulation and the other one HHH1(DD) does
not have an input that calls itself in recursive simulation.
Not when they are actually the same! There is no notion of „itself”.
They both get the same input and produce indistinguishable traces.
In this case it is obvious that DD correctly simulated by HHH specifiesI’m not a C programmer, but what’s the problem? What do you need the static data *for*?
a different sequence of steps than DD correctly simulated by HHH1.
*Between you and Mike I may actually get closure on this* I am still
working out how HHH(DD) can see the repeating state of its correct
simulation of its input without static data.
On 24/08/2025 12:19, Richard Damon wrote:
On 8/24/25 1:53 AM, joes wrote:
<snip>
I’m not a C programmer, but what’s the problem? What do you need the >>> static data *for*?
To do something that he can't do without it, his outer simulator can't
figure out what the inner version is doing without its help.
That's fair enough, though, surely? It's not as if it's doing anything
that couldn't be done with a pointer argument?
HHH could palm off the recursive bit to an HHHH - what's another H? - as
in HHHH(DD, &state), where state is a struct containing HHH's world, his
dog, and his oyster, and then every invocation can happily share state
with every other invocation. Shit design, but I don't quite see how it
could be considered "cheating". I see a lot of cheating in his thinking,
but somehow I can't see myself as adding that one to the list.
On 8/24/25 7:34 AM, Richard Heathfield wrote:
HHH could palm off the recursive bit to an HHHH - what's
another H? - as in HHHH(DD, &state), where state is a struct
containing HHH's world, his dog, and his oyster, and then every
invocation can happily share state with every other invocation.
Shit design, but I don't quite see how it could be considered
"cheating". I see a lot of cheating in his thinking, but
somehow I can't see myself as adding that one to the list.
Yes, but then he makes his deception explicit and can't lie that
he is doing things per the proof.
A Halt decider (or other program) doesn't take a pointer argument
to a data space for a simulated halt decider to put information in.
The problem is HHH doesn't control the code of DD, so it can't
add that parameter to the call.
Olcott NEEDS his claimed decider to be able to do things programs
can't do to try to pull of his claims.
If he even tried to make real Turing Machines to form his proof,
he would find it totally impossible, as his proof is based on
non-Turing compatible behavior, making it less than Turing Complete.
[...] I don't see why people are
beating [PO] up over static data when it's so easy in C to share
information across functions when you need to.
On 8/24/2025 10:44 AM, Andy Walker wrote:
On 24/08/2025 14:25, Richard Heathfield wrote:
[...] I don't see why people are
beating [PO] up over static data when it's so easy in C to share
information across functions when you need to.
I don't see why people are beating him up over anything to do
with his programs, beyond their technical correctness and results.
We don't need to write [putative] halt deciders as TMs, nor
under any
restrictions as to what features of C [or Algol or ...] may or may
not be used. PO would become famous [beyond being the record
holder
for most posts in a career] for any program that actually
solved the
HP, no matter how it did it [short of magic]; and almost as
famous
for establishing that one of the standard proofs was significantly
in error.
For these cases, we can turn to our second weapon -- emulation.
We want to know whether a program halts, so we try it. If it
halts, then we know the answer.
On 8/24/2025 10:44 AM, Andy Walker wrote:
On 24/08/2025 14:25, Richard Heathfield wrote:For these cases, we can turn to our second weapon -- emulation. We want
[...] I don't see why people are beating [PO] up over static data when
it's so easy in C to share information across functions when you need
to.
I don't see why people are beating him up over anything to do
with his programs, beyond their technical correctness and results. We
don't need to write [putative] halt deciders as TMs, nor under any
restrictions as to what features of C [or Algol or ...] may or may not
be used. PO would become famous [beyond being the record holder for
most posts in a career] for any program that actually solved the HP, no
matter how it did it [short of magic]; and almost as famous for
establishing that one of the standard proofs was significantly in
error.
to know whether a program halts, so we try it. If it halts, then we know
the answer. If it doesn't halt, then `it must be in a loop', so we
monitor its state and `detect the loop'. Sadly, although this is in one
sense correct, it is a false dichotomy. At any given moment as the
emulation proceeds, we are in one of not two but three states: the
program has halted, or it is looping, or it is still running and has not
yet entered a loop. It's the third case that kills us -- we just have to
keep going, and wait for one of the other two things to happen. The
trouble is that it may be that neither of them ever happens -- which is
why `it must be in a loop' was in quotes above. https://www.cuboid.me.uk/anw/G12FCO/lect18.html
*Repeating state detected in the execution trace of the emulated input*
The execution trace of the input is watched in DebugStep() mode.
*Summed up concisely here* https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 8/24/2025 10:44 AM, Andy Walker wrote:
On 24/08/2025 14:25, Richard Heathfield wrote:
[...] I don't see why people are
beating [PO] up over static data when it's so easy in C to share
information across functions when you need to.
I don't see why people are beating him up over anything to do
with his programs, beyond their technical correctness and results.
We don't need to write [putative] halt deciders as TMs, nor under any
restrictions as to what features of C [or Algol or ...] may or may
not be used. PO would become famous [beyond being the record holder
for most posts in a career] for any program that actually solved the
HP, no matter how it did it [short of magic]; and almost as famous
for establishing that one of the standard proofs was significantly
in error.
For these cases, we can turn to our second weapon -- emulation. We want
to know whether a program halts, so we try it. If it halts, then we know
the answer. If it doesn't halt, then `it must be in a loop', so we
monitor its state and `detect the loop'. Sadly, although this is in one
sense correct, it is a false dichotomy. At any given moment as the
emulation proceeds, we are in one of not two but three states: the
program has halted, or it is looping, or it is still running and has not
yet entered a loop. It's the third case that kills us -- we just have to
keep going, and wait for one of the other two things to happen. The
trouble is that it may be that neither of them ever happens -- which is
why `it must be in a loop' was in quotes above. https://www.cuboid.me.uk/anw/G12FCO/lect18.html
*Repeating state detected in the execution trace of the emulated input*
The execution trace of the input is watched in DebugStep() mode.
*Summed up concisely here* https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 24/08/2025 14:25, Richard Heathfield wrote:
[...] I don't see why people are
beating [PO] up over static data when it's so easy in C to share
information across functions when you need to.
I don't see why people are beating him up over anything to do
with his programs, beyond their technical correctness and results.
We don't need to write [putative] halt deciders as TMs, nor under any restrictions as to what features of C [or Algol or ...] may or may
not be used. PO would become famous [beyond being the record holder
for most posts in a career] for any program that actually solved the
HP, no matter how it did it [short of magic]; and almost as famous
for establishing that one of the standard proofs was significantly
in error.
On 24/08/2025 12:52, Richard Damon wrote:
On 8/24/25 7:34 AM, Richard Heathfield wrote:
<snip>
HHH could palm off the recursive bit to an HHHH - what's another H? -
as in HHHH(DD, &state), where state is a struct containing HHH's
world, his dog, and his oyster, and then every invocation can happily
share state with every other invocation. Shit design, but I don't
quite see how it could be considered "cheating". I see a lot of
cheating in his thinking, but somehow I can't see myself as adding
that one to the list.
Yes, but then he makes his deception explicit and can't lie that he is
doing things per the proof.
Well, we already know that, so I don't think he has anything to lose.
A Halt decider (or other program) doesn't take a pointer argument to a
data space for a simulated halt decider to put information in.
What says so? Surely a halt decider that Gets The Job Done would be good enough, as long as it remains a state machine?
The problem is HHH doesn't control the code of DD, so it can't add
that parameter to the call.
Doesn't have to. That's why the extra H. You move all the heavy lifting
into HHHH, and HHH becomes a mere wrapper to be called by DD.
int HHH(ptr P)
{
State state = {0};
return HHHH(P, &state);
}
Olcott NEEDS his claimed decider to be able to do things programs
can't do to try to pull of his claims.
Are you claiming that he's talking BS? No argument here, I assure you;
*of course* he's talking BS, but I don't see why people are beating him
up over static data when it's so easy in C to share information across functions when you need to.
If he even tried to make real Turing Machines to form his proof, he
would find it totally impossible, as his proof is based on non-Turing
compatible behavior, making it less than Turing Complete.
For as long as his "proof" depends on simulating one line of DD and
ignoring the other three, he doesn't have a proof that holds water and
he's deluding himself[1] if he thinks otherwise, but as far as I'm
concerned he can have all the static he can drink.
[1] Who knew?
He tries to prevent that by a "rule" that you can't actually make
a copy of his HHH
On 24/08/2025 19:58, Richard Damon wrote:
He tries to prevent that by a "rule" that you can't actually make a
copy of his HHH
Curiouser and curiouser. How does he enforce it? Copyright?
He doesn't get to choose the rules of Turing's game.
(If he wants to invent his own game, fine, but who cares?)
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 12:07 PM, Mr Flibble wrote:
How many times must I repeat to you that DD(), the caller of HHH, should >>>> pass a *description* of itself to HHH; it is quite valid for DD to take on >>>> two roles: caller and input.
/Flibble
In the same way that when Bill's identical twin brother
Bob robs a liquor store that Bill is equally guilty
because he looks the same as Bob.
That's silly. Two copies (or even different implementations) of exactly
the same algorithm are one and the same in the same way that identical
twins are not.
Not when one of these identical two functions has
an input that calls itself HHH(DD) in recursive
simulation and the other one HHH1(DD) does not have
an input that calls itself in recursive simulation.
In this case it is obvious that DD correctly simulated
by HHH specifies a different sequence of steps than DD
correctly simulated by HHH1.
*Between you and Mike I may actually get closure on this*
I am still working out how HHH(DD) can see the repeating
state of its correct simulation of its input without static
data.
I don't see why people are beating him up over anything to doThe problem is that a Halt Decider, by definition, must be the
with his programs, beyond their technical correctness and results.
[...]
equivalent of a "Computation", as since a given input will always
represent a Computation, and thus always do the same thing, the
correct answer for that computation must be consistant, and thus the
Halt Decider can't change its answer based on context.
His "trick" breaks the simplified version of the input that allows
the non-compuatation to possible get a correct answer for that given
input (though his answer isn't). [...]
He tries to prevent that by a "rule" that you can't actually make a
copy of his HHH, which is just an admission that his system is not
Turing Complete, and for non-Turing Complete system, the halting
problem just isn't interesting, as many non-Turing Complete systems
support full Halt Deciding.
On 8/24/2025 4:03 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 12:07 PM, Mr Flibble wrote:
How many times must I repeat to you that DD(), the caller of HHH,
should
pass a *description* of itself to HHH; it is quite valid for DD to >>>>>> take on
two roles: caller and input.
/Flibble
In the same way that when Bill's identical twin brother
Bob robs a liquor store that Bill is equally guilty
because he looks the same as Bob.
That's silly. Two copies (or even different implementations) of exactly >>>> the same algorithm are one and the same in the same way that identical >>>> twins are not.
Not when one of these identical two functions has
an input that calls itself HHH(DD) in recursive
simulation and the other one HHH1(DD) does not have
an input that calls itself in recursive simulation.
In this case it is obvious that DD correctly simulated
by HHH specifies a different sequence of steps than DD
correctly simulated by HHH1.
But how can you not see that this is hokey. DD is a procedure invoked
with no arguments, If two invocations DD() are found to execute
different steps, then DD is not a function or Turing machine.
It need not be a pure function. It is
already known that it may not halt thus
would be no function at all.
You are
working with the wrong category of object. If you do that, your work
doesn't say anything about a proof which restricts itself to a different
category of entities.
*Between you and Mike I may actually get closure on this*
I am still working out how HHH(DD) can see the repeating
state of its correct simulation of its input without static
data.
I don't see how you can code your way around an established theorem
without doing something invalid (like, currently, the static data)
and then deceiving yourself into believing that it is valid.
Or finding an error or something overlooked by the
proof of the theorem.
The key most important thing that you repeatedly
ignore is that when DD is correctly emulated by
any HHH that can possibly exist this DD cannot
possibly reach its own simulated "return" statement
final halt state. This means that HHH(DD)==0 is
correct even if HHH does not know it.
*This single page sums it up most succinctly* https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 8/24/2025 4:03 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
In this case it is obvious that DD correctly simulated
by HHH specifies a different sequence of steps than DD
correctly simulated by HHH1.
But how can you not see that this is hokey. DD is a procedure
invoked
with no arguments, If two invocations DD() are found to execute
different steps, then DD is not a function or Turing machine.
It need not be a pure function. It is
already known that it may not halt thus
would be no function at all.
The key most important thing that you repeatedly
ignore is that when DD is correctly emulated by
any HHH that can possibly exist this DD cannot
possibly reach its own simulated "return" statement
On 24/08/2025 19:58, Richard Damon wrote:
[I wrote:]
[...]
I don't see why people are beating him up over anything to doThe problem is that a Halt Decider, by definition, must be the
with his programs, beyond their technical correctness and results.
[...]
equivalent of a "Computation", as since a given input will always
represent a Computation, and thus always do the same thing, the
correct answer for that computation must be consistant, and thus the
Halt Decider can't change its answer based on context.
Again, why are you so hung up on this? If a putative halt decider P is given input Q that sometimes halts and sometimes doesn't,
then I don't greatly care which answer it gives. There's no kudos at
all in P being sometimes right and sometimes wrong; and if P is always right despite the right answer depending on [eg] a coin toss or the
phase of the moon, then good for P. What would really count is if P
always gets the right answer for Q that does have consistent behaviour. Equally if P is inconsistent, that just means it's sometimes wrong,
and is therefore not interesting. If some actual P always gets the
right answer, that either breaks the HP proofs, or disproves the Church-Turing thesis in an effective way, either of which would make
the name of its perpetrator, or shows an unreasonable limitation on Q.
His "trick" breaks the simplified version of the input that allows
the non-compuatation to possible get a correct answer for that given
input (though his answer isn't). [...]
So what? Either the possible values for Q are sufficiently
simple for the HP to be solvable for them, or they aren't. The
results are one of
-- of no interest at all, or
-- a minor extension to knowledge by showing the restricted inputs
to be, or not to be, Turing-complete, or
-- a major surprise by breaking the HP proofs for a T-C language.
None of this depends on whether P is, or Q describes, a "computation".
He tries to prevent that by a "rule" that you can't actually make a
copy of his HHH, which is just an admission that his system is not
Turing Complete, and for non-Turing Complete system, the halting
problem just isn't interesting, as many non-Turing Complete systems
support full Halt Deciding.
Yes, but it seems to me that you and others are barking up completely the wrong tree. There are plenty of more interesting
trees to bark up, even if you insist on banging your head against
the PO brick wall.
On 24/08/2025 19:58, Richard Damon wrote:
[I wrote:]
[...]
I don't see why people are beating him up over anything to doThe problem is that a Halt Decider, by definition, must be the
with his programs, beyond their technical correctness and results.
[...]
equivalent of a "Computation", as since a given input will always
represent a Computation, and thus always do the same thing, the
correct answer for that computation must be consistant, and thus the
Halt Decider can't change its answer based on context.
Again, why are you so hung up on this? If a putative halt
decider P is given input Q that sometimes halts and sometimes doesn't,
then I don't greatly care which answer it gives.
On 8/24/2025 4:03 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 12:07 PM, Mr Flibble wrote:
How many times must I repeat to you that DD(), the caller of HHH, should >>>>>> pass a *description* of itself to HHH; it is quite valid for DD to take on
two roles: caller and input.
/Flibble
In the same way that when Bill's identical twin brother
Bob robs a liquor store that Bill is equally guilty
because he looks the same as Bob.
That's silly. Two copies (or even different implementations) of exactly >>>> the same algorithm are one and the same in the same way that identical >>>> twins are not.
Not when one of these identical two functions has
an input that calls itself HHH(DD) in recursive
simulation and the other one HHH1(DD) does not have
an input that calls itself in recursive simulation.
In this case it is obvious that DD correctly simulated
by HHH specifies a different sequence of steps than DD
correctly simulated by HHH1.
But how can you not see that this is hokey. DD is a procedure invoked
with no arguments, If two invocations DD() are found to execute
different steps, then DD is not a function or Turing machine.
It need not be a pure function. It is
already known that it may not halt thus
would be no function at all.
I don't see how you can code your way around an established theorem
without doing something invalid (like, currently, the static data)
and then deceiving yourself into believing that it is valid.
Or finding an error or something overlooked by the
proof of the theorem.
The key most important thing that you repeatedly
ignore is that when DD is correctly emulated by
any HHH that can possibly exist this DD cannot
On 8/24/2025 12:53 AM, joes wrote:
Am Sat, 23 Aug 2025 16:45:30 -0500 schrieb olcott:
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
That's silly. Two copies (or even different implementations)Not when one of these identical two functions has an input
of exactly
the same algorithm are one and the same in the same way that
identical
twins are not.
that calls
itself HHH(DD) in recursive simulation and the other one
HHH1(DD) does
not have an input that calls itself in recursive simulation.
Not when they are actually the same! There is no notion of
„itself”.
They both get the same input and produce indistinguishable traces.
Counter-factual.
On 8/25/2025 12:44 AM, Kaz Kylheku wrote:
In your test apparatus, if you write a main() that begins
by calling DD(), DD() will terminate.
That's the ground truth; you have a terminating DD().
Counter-factual. When we get rid of the static data
then DD() only stops running on OOM error, it never halts.
On 8/24/2025 12:53 AM, joes wrote:
Am Sat, 23 Aug 2025 16:45:30 -0500 schrieb olcott:
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
That's silly. Two copies (or even different implementations) of exactly >>>> the same algorithm are one and the same in the same way that identical >>>> twins are not.Not when one of these identical two functions has an input that calls
itself HHH(DD) in recursive simulation and the other one HHH1(DD) does
not have an input that calls itself in recursive simulation.
Not when they are actually the same! There is no notion of „itself”.
They both get the same input and produce indistinguishable traces.
Counter-factual.
In this case it is obvious that DD correctly simulated by HHH specifiesI’m not a C programmer, but what’s the problem? What do you need the
a different sequence of steps than DD correctly simulated by HHH1.
*Between you and Mike I may actually get closure on this* I am still
working out how HHH(DD) can see the repeating state of its correct
simulation of its input without static data.
static data *for*?
On 8/25/2025 12:44 AM, Kaz Kylheku wrote:
On 2025-08-24, olcott <polcott333@gmail.com> wrote:
On 8/24/2025 4:03 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 4:36 PM, Kaz Kylheku wrote:
On 2025-08-23, olcott <polcott333@gmail.com> wrote:
On 8/23/2025 12:07 PM, Mr Flibble wrote:
How many times must I repeat to you that DD(), the caller of
HHH, should
pass a *description* of itself to HHH; it is quite valid for DD >>>>>>>> to take on
two roles: caller and input.
/Flibble
In the same way that when Bill's identical twin brother
Bob robs a liquor store that Bill is equally guilty
because he looks the same as Bob.
That's silly. Two copies (or even different implementations) of
exactly
the same algorithm are one and the same in the same way that
identical
twins are not.
Not when one of these identical two functions has
an input that calls itself HHH(DD) in recursive
simulation and the other one HHH1(DD) does not have
an input that calls itself in recursive simulation.
In this case it is obvious that DD correctly simulated
by HHH specifies a different sequence of steps than DD
correctly simulated by HHH1.
But how can you not see that this is hokey. DD is a procedure invoked
with no arguments, If two invocations DD() are found to execute
different steps, then DD is not a function or Turing machine.
It need not be a pure function. It is
already known that it may not halt thus
would be no function at all.
Pure functions can fail to halt, by way of nonterminating recursion.
("Pure" is actually unnecessary; we only need to emphasize that because
of programming langauges that have used the word "function" for
both procedures and functions.)
I don't see how you can code your way around an established theorem
without doing something invalid (like, currently, the static data)
and then deceiving yourself into believing that it is valid.
Or finding an error or something overlooked by the
proof of the theorem.
Where in such a tiny thing would such a gross error hide?
The problem is that you are mystified by the theorem, because you don't
quite understand it, which makes it seem more complicated than it is.
The key most important thing that you repeatedly
ignore is that when DD is correctly emulated by
any HHH that can possibly exist this DD cannot
In your test apparatus, if you write a main() that begins
by calling DD(), DD() will terminate.
That's the ground truth; you have a terminating DD().
Counter-factual. When we get rid of the static data
then DD() only stops running on OOM error, it never halts.
[...]In that situation, Q cannot be a symbol which unambiguously refers to a single, specific Turing Machine. Because a TM always calculates the same
Again, why are you so hung up on this? If a putative halt
decider P is given input Q that sometimes halts and sometimes doesn't,
then I don't greatly care which answer it gives.
way, starting with the same contents and tape head position.
Since halting only concerns itself with Turing Machines, and Q is
not in that category, the behavior of P is neither here nor there.
The issue is that if HHH can shape the behavior of the non-
computation, it can give an answer correct about "its simulation"
that isn't correct about the running of said computation directly.
This can make the wrong answer to seem right.
Except that a "victory" as misdefining halting, will be carried to
claims about the foundational meaning of "Truth", which is his ultimate
goal.
On 8/25/2025 7:18 AM, Andy Walker wrote:
On 25/08/2025 01:43, Richard Damon wrote:
The issue is that if HHH can shape the behavior of the non-
computation, it can give an answer correct about "its simulation"
that isn't correct about the running of said computation
directly.
This can make the wrong answer to seem right.
Then that is a proof that the simulation is incorrect.
/That/
is the important point, not the fact that the input does not
describe
a [fixed] computation. After all, we would all be mightily
impressed
if some putative halt decider always got the right answer
/despite/
depending on the phase of the Moon.
HHH and HHH1 have identical source-code as measured by DIFF.
DD correctly simulated by HHH1 has the same behavior as DD().
On 8/25/2025 1:35 AM, Richard Heathfield wrote:
On 25/08/2025 06:49, olcott wrote:
On 8/25/2025 12:44 AM, Kaz Kylheku wrote:
<snip>
In your test apparatus, if you write a main() that begins
by calling DD(), DD() will terminate.
That's the ground truth; you have a terminating DD().
Counter-factual. When we get rid of the static data
then DD() only stops running on OOM error, it never halts.
Some of us have tried it and watched it halt. How long are you
going to pretend otherwise?
None of you have tried it. I tried it this morning.
On 8/25/2025 12:44 AM, Kaz Kylheku wrote:
In your test apparatus, if you write a main() that begins
by calling DD(), DD() will terminate.
That's the ground truth; you have a terminating DD().
Counter-factual. When we get rid of the static data
then DD() only stops running on OOM error, it never halts.
On 8/25/2025 10:31 AM, Richard Heathfield wrote:
On 25/08/2025 16:21, olcott wrote:
On 8/25/2025 1:35 AM, Richard Heathfield wrote:
On 25/08/2025 06:49, olcott wrote:
On 8/25/2025 12:44 AM, Kaz Kylheku wrote:
<snip>
In your test apparatus, if you write a main() that begins
by calling DD(), DD() will terminate.
That's the ground truth; you have a terminating DD().
Counter-factual. When we get rid of the static data
then DD() only stops running on OOM error, it never halts.
Some of us have tried it and watched it halt. How long are
you going to pretend otherwise?
None of you have tried it. I tried it this morning.
No, you ran a different program. When HHH(DD) returns 0 (as you
have insisted over and over that it must), DD halts.
Now that Kaz pointed out that the current HHH(DD)
may not be a pure function of its inputs we examine
the behavior of DD correctly simulated by HHH that
is a pure function of its inputs.
HHH and HHH1 have identical source-code as measured by DIFF.
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
HHH and HHH1 have identical source-code as measured by DIFF.
Obviously false, if you're referring to the GNU diff:
$ diff -u HHH.txt HHH1.txt
@@@ -1,3 +1,3 @@
-u32 HHH(ptr P)
+u32 HHH1(ptr P)
{
u32* Aborted;
u32* execution_trace;
In your system, names matter, because every copy of HHH
under a different name gets its own static fuse.
When HHH is called the first time, and HHH1 has not yet been called,
HHH's fuse is blown, while HHH1's is still intact.
Good thing, then, that diff doesn't ignore the difference in name.
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
On 8/25/2025 11:41 AM, Richard Heathfield wrote:
On 25/08/2025 17:33, olcott wrote:Liar
<snip>
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
abort code duly removed.
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
On 8/25/2025 11:06 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
HHH and HHH1 have identical source-code as measured by DIFF.
Obviously false, if you're referring to the GNU diff:
I am actually using the more effective
Beyond Compare version 3.0
Only the names and one comment are different.
$ diff -u HHH.txt HHH1.txt
@@@ -1,3 +1,3 @@
-u32 HHH(ptr P)
+u32 HHH1(ptr P)
{
u32* Aborted;
u32* execution_trace;
In your system, names matter, because every copy of HHH
under a different name gets its own static fuse.
When I disable to use of static data HHH1(DD)
HHH(DD) and directly executed DD() never stop running.
This proves that this static analysis is correct:
Five different LLM systems formed a consensus on
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:Finally you are paying attention to this.
DD correctly simulated by HHH cannot possibly reach its own simulated
"return" statement final halt state is proven by the fact that when
the abort code is disabled that DD() never stops running.
When the abort code is disabled HHH(DD) never returns and that's why DD
never stops running. DD never even gets to execute the logic that
"behaves opposite" to HHH(DD)'s verdict.
The fact that HHH(DD) never returns due to runaway recursion shows that*Yes it does show this in this case*
HHH isn't a universal decider.
HHH never even aimed to be a universal decider it only aimed on
reporting on the behavior of DD correctly simulated by HHH.
Because HHH(DD) never stops running that does prove that HHH(DD)==0
would be correct if HHH could return.
In a version of your test case where the abort logic is disabled,None-the-less five LLM static code analyzers did correctly determine
you cannot obtain the result HHH(DD) -> 0.
that DD correctly simulated by HHH cannot possibly reach its own
simulated "return"
statement final halt state, thus HHH(DD)==0 would be correct.
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
When the abort code is disabled HHH(DD) never returns and that's why DD
never stops running. DD never even gets to execute the logic that
"behaves opposite" to HHH(DD)'s verdict.
Finally you are paying attention to this.
The fact that HHH(DD) never returns due to runaway recursion shows that
HHH isn't a universal decider.
*Yes it does show this in this case*
HHH never even aimed to be a universal decider
it only aimed on reporting on the behavior of
DD correctly simulated by HHH.
Because HHH(DD) never stops running that does
prove that HHH(DD)==0 would be correct if HHH
could return.
In a version of your test case where the abort logic is disabled,
you cannot obtain the result HHH(DD) -> 0.
None-the-less five LLM static code analyzers did
correctly determine that DD correctly simulated by
HHH cannot possibly reach its own simulated "return"
statement final halt state, thus HHH(DD)==0 would
be correct.
On 25/08/2025 01:43, Richard Damon wrote:
The issue is that if HHH can shape the behavior of the non-
computation, it can give an answer correct about "its simulation"
that isn't correct about the running of said computation directly.
This can make the wrong answer to seem right.
Then that is a proof that the simulation is incorrect. /That/
is the important point, not the fact that the input does not describe
a [fixed] computation. After all, we would all be mightily impressed
if some putative halt decider always got the right answer /despite/
depending on the phase of the Moon.
[...]
Except that a "victory" as misdefining halting, will be carried to
claims about the foundational meaning of "Truth", which is his ultimate
goal.
So to prevent PO claiming "victory", you're happy to spend hours writing ~25 articles /every day/ in an attempt to rebut him. Someone is lacking a sense of proportion.
On 8/25/2025 7:18 AM, Andy Walker wrote:
On 25/08/2025 01:43, Richard Damon wrote:
The issue is that if HHH can shape the behavior of the non-
computation, it can give an answer correct about "its simulation"
that isn't correct about the running of said computation directly.
This can make the wrong answer to seem right.
Then that is a proof that the simulation is incorrect. /That/
is the important point, not the fact that the input does not describe
a [fixed] computation. After all, we would all be mightily impressed
if some putative halt decider always got the right answer /despite/
depending on the phase of the Moon.
HHH and HHH1 have identical source-code as measured by DIFF.
DD correctly simulated by HHH1 has the same behavior as DD().
DD correctly simulated by HHH has different behavior than
DD correctly simulated by HHH1 because DD calls HHH(DD)
in recursive simulation and does not call HHH1(DD) at all.
A termination analyzer its required to report on the actual
behavior that its actual input actually specifies. This is
correctly measured by DD correctly simulated by HHH.
DD correctly simulated by HHH cannot possibly reach its own
"return" statement final halt state in any finite number of steps.
Denying this is like denying that 2 + 3 = 5 because
you don't believe in numbers.
[...]
Except that a "victory" as misdefining halting, will be carried to
claims about the foundational meaning of "Truth", which is his ultimate
goal.
So to prevent PO claiming "victory", you're happy to spend hours >> writing ~25 articles /every day/ in an attempt to rebut him. Someone is
lacking a sense of proportion.
On 8/25/2025 2:03 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 11:06 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
HHH and HHH1 have identical source-code as measured by DIFF.
Obviously false, if you're referring to the GNU diff:
I am actually using the more effective
Beyond Compare version 3.0
Only the names and one comment are different.
Oh, the names are different?
So that "identical" word you used there is doing a lot of heavy lifting,
isn't it.
When I say that HHH and HHH1 have identical source-code
I very obviously do not mean their name.
Much like when you misuse the word "itself".
$ diff -u HHH.txt HHH1.txt
@@@ -1,3 +1,3 @@
-u32 HHH(ptr P)
+u32 HHH1(ptr P)
{
u32* Aborted;
u32* execution_trace;
In your system, names matter, because every copy of HHH
under a different name gets its own static fuse.
When I disable to use of static data HHH1(DD)
HHH(DD) and directly executed DD() never stop running.
This proves that this static analysis is correct:
When you disable the static data, then HHH1 and HHH become
semantically identical; one can be substituted for another.
No they remain semantically different in that DD
still calls its own simulator HHH(DD) in recursive
emulation and still does not call HHH1 at all.
In that modified system, things are better from a theoretical point of
view, but do not contain the underhanded trickery which you need
in orderto support your false rhetoric around halting.
It was never intended as underhanded trickery.
It was important that I break through the perpetual
gaslighting on the behavior of DD correctly simulation
by HHH. If I could not do this then there is no sense
making HHH a pure function of its inputs because the
people here would simply lie abut that too.
Both HHH1(DD) and HHH(DD) do not halt, and therefore do not
return zero.
Unless HHH(DD) can somehow see the repeating state
in its simulated input. A static analysis of the
structure of the relationship between HHH and DD
does show this. Five LLM systems and I all agree
that this static analysis of this relationship is
correct.
Five different LLM systems formed a consensus on
LLM is garbage, in the wrong hands, unfortuntaely, and often even in
the right hands.
That they do a correct static analysis of the behavioral
results of the relationship between HHH and DD cannot be
correctly refuted.
On 8/25/2025 10:40 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 12:44 AM, Kaz Kylheku wrote:
In your test apparatus, if you write a main() that begins
by calling DD(), DD() will terminate.
That's the ground truth; you have a terminating DD().
Counter-factual. When we get rid of the static data
then DD() only stops running on OOM error, it never halts.
But the reason it then never halts is that HHH(DD) doesn't return;
DD doesn't even get to "beave opposite" to HHH's verdict.
And without the static data, you have the situation that HHH and DD are
functions: there is one HHH and one DD.
Thus a top-level call to HHH(DD) also doesn't return.
The system then doesn't inform us anythnig we didn't know already: that
simulating is a poor tool for deciding halting.
No it is more than that.
That DD correctly simulated by HHH never stops
running does prove that HHH(DD)==0 is correct.
That's more than anyone else has ever accomplished
with the HP counter-example input.
It is no longer both return values from HHH are
contradicted. The contradictory code becomes
unreachable.
On 8/25/2025 3:12 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
When the abort code is disabled HHH(DD) never returns and that's why DD >>>> never stops running. DD never even gets to execute the logic that
"behaves opposite" to HHH(DD)'s verdict.
Finally you are paying attention to this.
The fact that HHH(DD) never returns due to runaway recursion shows that >>>> HHH isn't a universal decider.
*Yes it does show this in this case*
HHH never even aimed to be a universal decider
it only aimed on reporting on the behavior of
DD correctly simulated by HHH.
To do that, you first have to blow the fuse that
pins down the DD which is to be tested. And /then/
call HHH(DD).
For instance:
int main()
{
(void) HHH(DD); // warm up the decider; discard the result
// DD is now the non-halting one; no more changes take place
if (HHH(DD)) {
...
} else {
...
}
}
I don't understand what you are saying.
I will guess that the first HHH(DD) initializes
the static data on the basis that HHH tests this
data to see if it has been initialized.
Then the second HHH(DD) already has its static data
initialized and see this. That would be an easy fix.
Because HHH(DD) never stops running that does
prove that HHH(DD)==0 would be correct if HHH
could return.
That's like saying is_prime(4) would be correct if only 4 would be 1
smaller than it is.
There is no "would" in math, only "is" or "is not".
Hey, you know, Escher's Waterfall would be a perpetual motion machine,
if only the illusion could jump out of the picture.
On the other hand if the original HHH determined
its halt status for DD by examining the relationship
between DD and HHH it could correctly return 0
without static data.
We cannot think about changing the behavior of HHH to suit a desired
"would be" return value, without considering that by doing so we are
changing the definition of DD.
Any changes that have no behavioral consequences
are of no relevant consequence. For example
appending NOP instructions to DD have no relevant
consequence.
If you preserve the definition of DD while redesigning HHH to have
a different return value, it means you now have two deciders:
the original HHH embedded in DD, and the new decider HHH2
which is trying to return something else.
It comes as no surprise that when you allow two deciders, you
can get the result you want. DD is designed to prove that HHH(DD)
is incorrect, and that is all it has to do; it doesn't speak
to (and doesn't have to) to HHH2(DD).
When any HHH reports that DD correctly simulated
by HHH cannot possibly reach its own simulated
"return" statement final halt state then this HHH
is necessarily correct.
On 8/25/2025 2:03 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 11:06 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
HHH and HHH1 have identical source-code as measured by DIFF.
Obviously false, if you're referring to the GNU diff:
I am actually using the more effective
Beyond Compare version 3.0
Only the names and one comment are different.
Oh, the names are different?
So that "identical" word you used there is doing a lot of heavy lifting,
isn't it.
When I say that HHH and HHH1 have identical source-code
I very obviously do not mean their name.
Much like when you misuse the word "itself".
$ diff -u HHH.txt HHH1.txt
@@@ -1,3 +1,3 @@
-u32 HHH(ptr P)
+u32 HHH1(ptr P)
{
u32* Aborted;
u32* execution_trace;
In your system, names matter, because every copy of HHH
under a different name gets its own static fuse.
When I disable to use of static data HHH1(DD)
HHH(DD) and directly executed DD() never stop running.
This proves that this static analysis is correct:
When you disable the static data, then HHH1 and HHH become
semantically identical; one can be substituted for another.
No they remain semantically different in that DD
still calls its own simulator HHH(DD) in recursive
emulation and still does not call HHH1 at all.
In that modified system, things are better from a theoretical point of
view, but do not contain the underhanded trickery which you need
in orderto support your false rhetoric around halting.
It was never intended as underhanded trickery.
The fact that DD correctly simulated by HHH cannot
stop running by itself proves that this DD is non-halting
thus if HHH aborts its simulation of DD it would be
correct to reject its input as non-halting.
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 3:12 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
When the abort code is disabled HHH(DD) never returns and that's why DD >>>>> never stops running. DD never even gets to execute the logic that
"behaves opposite" to HHH(DD)'s verdict.
Finally you are paying attention to this.
The fact that HHH(DD) never returns due to runaway recursion shows that >>>>> HHH isn't a universal decider.
*Yes it does show this in this case*
HHH never even aimed to be a universal decider
it only aimed on reporting on the behavior of
DD correctly simulated by HHH.
To do that, you first have to blow the fuse that
pins down the DD which is to be tested. And /then/
call HHH(DD).
For instance:
int main()
{
(void) HHH(DD); // warm up the decider; discard the result
// DD is now the non-halting one; no more changes take place
if (HHH(DD)) {
...
} else {
...
}
}
I don't understand what you are saying.
I will guess that the first HHH(DD) initializes
the static data on the basis that HHH tests this
data to see if it has been initialized.
This HHH(DD) returns zero, right? It tweaks the static data and then
begins simulating the procedural entry point DD.
It then detects the
runaway behavior and aborrts the simulation, returning 0.
Isn't that right?
Then the second HHH(DD) already has its static data
initialized and see this. That would be an easy fix.
Would it be an easy fix in such a way that it keeps your previous
test cases working?
Without any fix, this second HHH(DD) thinks it is the the simulated one
which must not perform the abort check.
Because HHH(DD) never stops running that does
prove that HHH(DD)==0 would be correct if HHH
could return.
That's like saying is_prime(4) would be correct if only 4 would be 1
smaller than it is.
There is no "would" in math, only "is" or "is not".
Hey, you know, Escher's Waterfall would be a perpetual motion machine,
if only the illusion could jump out of the picture.
On the other hand if the original HHH determined
its halt status for DD by examining the relationship
between DD and HHH it could correctly return 0
without static data.
How can you distinguish "original HHH" from "derived HHH"
without static data? You can make it a parameter.
But then you are making it crystal clear that there
are two deciders.
On 8/26/2025 7:17 PM, Mike Terry wrote:
On 26/08/2025 07:14, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 3:12 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
On 8/25/2025 1:58 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <polcott333@gmail.com> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
When the abort code is disabled HHH(DD) never returns and that's >>>>>>> why DD
never stops running. DD never even gets to execute the logic that >>>>>>> "behaves opposite" to HHH(DD)'s verdict.
Finally you are paying attention to this.
The fact that HHH(DD) never returns due to runaway recursion
shows that
HHH isn't a universal decider.
*Yes it does show this in this case*
HHH never even aimed to be a universal decider
it only aimed on reporting on the behavior of
DD correctly simulated by HHH.
To do that, you first have to blow the fuse that
pins down the DD which is to be tested. And /then/
call HHH(DD).
For instance:
int main()
{
(void) HHH(DD); // warm up the decider; discard the result >>>>>
// DD is now the non-halting one; no more changes take place >>>>>
if (HHH(DD)) {
...
} else {
...
}
}
I don't understand what you are saying.
I will guess that the first HHH(DD) initializes
the static data on the basis that HHH tests this
data to see if it has been initialized.
This HHH(DD) returns zero, right? It tweaks the static data and then
begins simulating the procedural entry point DD.
Correct
It then detects the
runaway behavior and aborrts the simulation, returning 0.
Isn't that right?
It doesn't "detect runaway behaviour". It matches PO's so-called
"Infinite Recursive Emulation" pattern in its collected trace data,
and then, yes, it returns 0.
Which I conclusively prove is runaway behavior
when I disable the abort and DD() never stops running.
Then the second HHH(DD) already has its static data
initialized and see this. That would be an easy fix.
Would it be an easy fix in such a way that it keeps your previous
test cases working?
What PO needs to do is keep whatever tests he needs in HHH, along with
collecting whatever (trace) data is needed to support those tests, but
do exactly the same collection and testing in each emulation level of
HHH:
[SL0] HHH(DD)
[SL0] ..emulates DD()..
[SL1] DD()
[SL1] ..calls HHH(DD)
[SL1] HHH(DD) // e.g. this HHH [SL1]
[SL1] ..emulates DD().. // needs to capture trace data
[SL2] DD() // for this <=== emulation [SL2]
[SL2] ..calls HHH(DD) // and nested sub-emulations
[SL3,4,5...]
[SL2] HHH(DD) // but obviously NOT for [SL0] or
[SL1]
[SL2] ..emulates DD()..
[SL3] DD()
[SL3] ..calls HHH(DD)
[SL3] HHH(DD)
[SL3] ..emulates DD()..
HHH /at every emulation level n/ needs to do the same:
- emulate DD() [SLn+1]
- collect trace entries from [SLn+1, SLn+2, SLn+3,...]
into its /own/ local trace table. [NOT into a global trace table
owned by HHH [SL0]
- analyse that local trace for abort patterns in [SLn+1, SLn+2,
SLn+3,...]
and watch for [SLn+1] halting "naturally"
- return 0 or 1 according to above analysis
What's so confusing about that? HHH [SLn] is emulating [SLn+1]
instruction by instruction and has complete access to [SLn+1] state,
including what instructions are being emulated, and all the memory
space of [SLn+1] (which happens to be its own memory space) including
[SLn+1]'s current stack position and so on. Basically, anything
[SLn+1] is doing, HHH [SLn] can see. That includes if [SLn+1] itself
emulates a nested [SLn+2] emulation, and so on.
[If you're not familiar with PO's emulation, code in HHH emulates a
single instruction in the emulation it's performing by calling a
"primitive op" DebugStep() which is actually implemented in x86utm
code. When HHH [SLn+1] performs a DebugStep() the code used is "call
<DebugStep notional address>", having previously pushed required
arguments onto its stack. All apparent to HHH [SLn]. ]
If HHH could even know the address of DebugStep()
then it could know its own address and there is
no need for more than one simulation. As soon as
HHH sees DD calling itself its abort criteria is met.
But PO just can't work it out. I thought recently he might have had
some kind of breakthrough, but all the talk of spinning up extra runs
of HHH(DD) to "warm up the static data" is crazy (ISTM...).
That seems to be Kaz's idea.
I may have gotten his wrong.
PO has (I believe) never /wanted/ to make inner HHH emulations
Without any fix, this second HHH(DD) thinks it is the the simulated one
which must not perform the abort check.
different. He just didn't know how to implement it properly, and it
came out that way.
The key thing is that unless we allocate the
execution_trace data once it gets erased at
every invocation.
I think its reasonable to say PO never thought his way through what he
needed his code to do, in order to support his proof refutation goals.
I have all that totally down pat for at least three years.
Making HHH a pure function of its inputs is the last step.
I think he started coding and just added more bits whenever something
didn't do what he expected. I think now he's become even more
entangled in a fog of objections from various posters, and has totally
lost track of where he's going. He's just tinkering around the edges
trying to keep posters happy, without understanding /why/ they are
objecting.
It has never been anything like this.
Its all exactly the same as my original design
of at least three years ago. I have changed the
test data to make it easier to understand.
I changed to DDD() because people didn't seem
to understand the execution trace of DD correctly
simulated by HHH. It seems to have turned out to
be the case that they just don't understand
execution traces at all.
Because HHH(DD) never stops running that does
prove that HHH(DD)==0 would be correct if HHH
could return.
That's like saying is_prime(4) would be correct if only 4 would be 1 >>>>> smaller than it is.
There is no "would" in math, only "is" or "is not".
Hey, you know, Escher's Waterfall would be a perpetual motion machine, >>>>> if only the illusion could jump out of the picture.
On the other hand if the original HHH determined
its halt status for DD by examining the relationship
between DD and HHH it could correctly return 0
without static data.
How can you distinguish "original HHH" from "derived HHH"
without static data? You can make it a parameter.
I don't believe PO would want to distinguish levels of HHH, if he
could work out how to track his nested emulations /properly/, without
the global trace table!
All that I need is for one HHH to see the whole
execution trace of all of the levels of DD. I
have that now. Or the whole other method only
requires HHH to know its own machine address.
Recently PO has been posting that if he eliminates the global data HHH
will never halt. That suggests he's thinking posters are suggesting
he just delete the global data variable! But then his code will have
a compiler error, so he must delete all the code that used that global
data, i.e. all his abort tests! Well Duh! If he deletes the abort
tests of course HHH never halts. Does he really think that was being
suggested?
Disabling the abort has the same practical consequence
as eliminating the trace data. It conclusively proves
that DD() doesn't really halt because it never stops
running.
What was suggested was rewriting the tests to /work properly/, e.g.
make the trace table local to HHH. I doubt you would take long to get
a design along those lines working.
HHH needs to either see two complete traces of
DD where it sees the same function called twice
in sequence or it needs to know its own machine
address. Then it sees DD calling itself.
But then you are making it crystal clear that there
are two deciders.
Right - two deciders is getting silly! PO wants one decider, coded
correctly so each emulation level behaves identically (as emulations
must...).
Each emulation level has always behaved identically.
It is only HHH seeing these execution traces that changes.
[..snip remainder..]
Mike.
But PO just can't work it out. I thought recently he might have had some kind of breakthrough, but
all the talk of spinning up extra runs of HHH(DD) to "warm up the static data" is crazy (ISTM...).
On 8/27/2025 8:32 PM, Chris M. Thomasson wrote:
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
As someone here pointed out (I think it was Mike) a
blown stack is a non-halting condition because my
C code is intended to model Turing machine behavior.
Thus when DD correctly simulated by HHH hits a blown
stack this proves that DD does not halt.
On 8/27/2025 8:32 PM, Chris M. Thomasson wrote:
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
As someone here pointed out (I think it was Mike) a
blown stack is a non-halting condition because my
C code is intended to model Turing machine behavior.
Thus when DD correctly simulated by HHH hits a blown
stack this proves that DD does not halt.
On 8/27/2025 9:31 PM, André G. Isaak wrote:
On 2025-08-27 20:06, olcott wrote:
On 8/27/2025 8:32 PM, Chris M. Thomasson wrote:
On 8/27/2025 6:24 PM, olcott wrote:
On 8/27/2025 7:29 PM, Chris M. Thomasson wrote:
On 8/27/2025 4:52 PM, olcott wrote:
On 8/27/2025 6:41 PM, Chris M. Thomasson wrote:
On 8/26/2025 6:39 PM, olcott wrote:
[...]
Runaway train... To where? Crash?
OOM error.
Blown stack?
Out-Of-Memory error probably not
a blown stack because each recursive
emulation gets a new 64K stack.
So are you trying to say that an out of memory condition means the
program under your test will always halt, or always never halt? ;^)
As someone here pointed out (I think it was Mike) a
blown stack is a non-halting condition because my
C code is intended to model Turing machine behavior.
Thus when DD correctly simulated by HHH hits a blown
stack this proves that DD does not halt.
No. It tells you that if DD halts, it requires a machine with a larger
stack.
André
The reason that that stack is blown in non-terming behavior
[Complete proof that the input to HHH(DD)==0 --- The HP proof is wrong]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 158:27:58 |
| Calls: | 10,384 |
| Calls today: | 1 |
| Files: | 14,056 |
| Messages: | 6,416,485 |