On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
I am only referring to these fifteen lines
A straight forward sequence of steps that any
C programmer can easily determine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you have nothing as this is incomplete and cannot be run.
When I posted the git repo several days ago, Olcott immediately
called me dishonest and replied with the above nonsense.
He has been repeating it ever since.
Basically a meltdown, of sorts.
Oh yeah, he's thrashing. He knows he's been beat and doesn't dare look
at your code, lest he has to admit he wasted the last 21 years.
But I explained that the code can help you validate that your cheats are
working. If you want to say that DDD simulated by HHH does not halt, and
not be lying, you can now test that actual claim. If the simulated DDD
halts, and you would like it not to, you have something to iterate
against to get that fixed.
Every engineer would be happy to have an easy, ready-made way to test
the property of their system that they want to believe to be true.
Instead of thank you, we get a childish tantrum.
Unfortunately, it is not that rosy. The problem is that Olcott has not
only been claiming that various D's do not terminate when simulated
by various H's. He's been claiming that the D's do not terminate because
they never reach the "do the opposite" logic at all.
On 10/27/2025 7:37 PM, Kaz Kylheku wrote:
On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
I am only referring to these fifteen lines
A straight forward sequence of steps that any
C programmer can easily determine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you have nothing as this is incomplete and cannot be run.
When I posted the git repo several days ago, Olcott immediately
called me dishonest and replied with the above nonsense.
He has been repeating it ever since.
Basically a meltdown, of sorts.
Oh yeah, he's thrashing. He knows he's been beat and doesn't dare look >>>> at your code, lest he has to admit he wasted the last 21 years.
But I explained that the code can help you validate that your cheats are >>> working. If you want to say that DDD simulated by HHH does not halt, and >>> not be lying, you can now test that actual claim. If the simulated DDD
halts, and you would like it not to, you have something to iterate
against to get that fixed.
Every engineer would be happy to have an easy, ready-made way to test
the property of their system that they want to believe to be true.
Instead of thank you, we get a childish tantrum.
Unfortunately, it is not that rosy. The problem is that Olcott has not
only been claiming that various D's do not terminate when simulated
by various H's. He's been claiming that the D's do not terminate because
they never reach the "do the opposite" logic at all.
Such an easily verified fact that I cannot begin
to imagine how anyone disputing this is not simply
a dammed liar.
*D simulated by H cannot possibly reach past its own first line*
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
On 10/27/2025 7:37 PM, Kaz Kylheku wrote:
On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
I am only referring to these fifteen lines
A straight forward sequence of steps that any
C programmer can easily determine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you have nothing as this is incomplete and cannot be run.
When I posted the git repo several days ago, Olcott immediately
called me dishonest and replied with the above nonsense.
He has been repeating it ever since.
Basically a meltdown, of sorts.
Oh yeah, he's thrashing. He knows he's been beat and doesn't dare look >>>> at your code, lest he has to admit he wasted the last 21 years.
But I explained that the code can help you validate that your cheats are >>> working. If you want to say that DDD simulated by HHH does not halt, and >>> not be lying, you can now test that actual claim. If the simulated DDD
halts, and you would like it not to, you have something to iterate
against to get that fixed.
Every engineer would be happy to have an easy, ready-made way to test
the property of their system that they want to believe to be true.
Instead of thank you, we get a childish tantrum.
Unfortunately, it is not that rosy. The problem is that Olcott has not
only been claiming that various D's do not terminate when simulated
by various H's. He's been claiming that the D's do not terminate because
they never reach the "do the opposite" logic at all.
Such an easily verified fact that I cannot begin
to imagine how anyone disputing this is not simply
a dammed liar.
*D simulated by H cannot possibly reach past its own first line*
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
On 28/10/2025 00:37, Kaz Kylheku wrote:
On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
I am only referring to these fifteen lines
A straight forward sequence of steps that any
C programmer can easily determine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you have nothing as this is incomplete and cannot be run.
When I posted the git repo several days ago, Olcott immediately
called me dishonest and replied with the above nonsense.
He has been repeating it ever since.
Basically a meltdown, of sorts.
Oh yeah, he's thrashing. He knows he's been beat and doesn't dare look >>>> at your code, lest he has to admit he wasted the last 21 years.
But I explained that the code can help you validate that your cheats are >>> working. If you want to say that DDD simulated by HHH does not halt, and >>> not be lying, you can now test that actual claim. If the simulated DDD
halts, and you would like it not to, you have something to iterate
against to get that fixed.
Every engineer would be happy to have an easy, ready-made way to test
the property of their system that they want to believe to be true.
Instead of thank you, we get a childish tantrum.
Unfortunately, it is not that rosy. The problem is that Olcott has not
only been claiming that various D's do not terminate when simulated
by various H's. He's been claiming that the D's do not terminate because
they never reach the "do the opposite" logic at all.
For instance, I ran a test on an old Halt.obj pulled from the git
history, and found that when its simulation of the abandoned DD is
continued, it soon hits an infinite loop.
While, for that .obj file, it confirms the claim that the simulated DD
doesn't terminate, the problem is that the simulated DD in that
situation fails to terminate due to getting into the infinite loop,
which is only possible because the simulated HHH(DD) returned non-zero
to simulated DD.
Thus the simulated HHH says, about the doubly-simulated DD, that the
doubly-simulated DD halts A bug or cheat has been exposed in the
machine; it is contradicting itself.
Right. To be overly charitable to PO, I don't believe PO coded things
this way with any intent at "cheating". Firstly, he just didn't see how
to do it "properly", but if he had he'd have probably done it that way. [Cleaner code without the global data misuse would be fewer lines of
code than what PO ended up with!] Secondly, I think he sees what he did
as a kind of "optimisation" rather than a cheat. He realised that it
would be the outer HHH that always spotted the abort pattern, and that pattern was not affected by whether the inner HHH's actually performed
the checks, so "no harm" if he just misses them out on the inner HHH's!
He just wasn't thinking ahead to your RECK resumption of abandoned emulations!
We've always known that PO's implementation of HHH/DD is broken, through
Olcott knows that continuing the abandoned simulation uncovers
damning evidence against his contraption, regardless of whether it
halts or not.
ne way to continue to defend it is via the following preposterous
argument: all the odd-numbered simulation levels of DD are
non-terminating, whereas the even-numbered levels (including zero,
directly exedcuted) are terminating. And insist that this is correct.
That narrative is possibly too far-fetched even for the prime
minister of far-fetched land himself.
the misuse of global data to communicate across emulation levels and to alter the behaviour of emulations depending on emulation depth. Until
that issue is fixed, anything PO claims is /proved/ by his C code is nonsense. PO can only argue his code /proves/ something, if that code
is actually correct!
Unfortunately, until the global data issue is resolved, anything your
RECK code shows about the behaviour of PO's abandoned emulations is effectively commenting more on the fickle behaviour of PO's global data interactions than anything else. A kind of nonsense-in-nonsense out!
(Not your fault in the slightest.)
I don't think PO is capable of fixing his code, and I won't be helping
him on that front. [I did once start explaining exactly what PO needed
to do, code-wise, but he just ignored that and continued replying as
usual, accusing me of not paying attention and lacking basic competence etc., and that moment has passed!]
Meanwhile, we sometimes kind of pretend that PO has fixed the problem,
and people discuss what his code /WOULD/ do /assuming/ that basic issue
had been resolved. That is being charitable to PO, and is sometimes referred to as "steel-manning".
<https://en.wikipedia.org/wiki/Straw_man#Steelmanning>
Very little of PO's arguments would change : his HHH would still decide neverhalts for DD, and DD() would still halt when run directly, same as happens with the broken code. All the usual objections raised by
posters here also continue to apply, so any such "steel-manned"
arguments are still seen to be just as silly as the non-steel-manned versions. So we may well choose to be charitable on this point!
[The only thing I can think of that changes would be the HHH/HHH1 comparison: if the global data misuse were fixed, both HHH(DD) and
HHH1(DD) would return 0, so PO would lose one of his (silly) arguments
that emulation behaviour depends on who is doing the emulating...]
Your comments on how PO's abandoned emulations should behave if resumed would work fine if PO had fixed the global code issues - each resumed emulation would halt, because in effect each emulation level behaves the same, simply tracking the steps of the "native" computation which
halts. So the point you are trying to convince PO of stands. [But unfortunately will never convince PO...]
Mike.
On 10/27/2025 9:24 PM, Mike Terry wrote:
On 28/10/2025 00:37, Kaz Kylheku wrote:
On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
I am only referring to these fifteen lines
A straight forward sequence of steps that any
C programmer can easily determine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you have nothing as this is incomplete and cannot be run.
When I posted the git repo several days ago, Olcott immediately
called me dishonest and replied with the above nonsense.
He has been repeating it ever since.
Basically a meltdown, of sorts.
Oh yeah, he's thrashing. He knows he's been beat and doesn't dare >>>>> look
at your code, lest he has to admit he wasted the last 21 years.
But I explained that the code can help you validate that your cheats
are
working. If you want to say that DDD simulated by HHH does not halt,
and
not be lying, you can now test that actual claim. If the simulated DDD >>>> halts, and you would like it not to, you have something to iterate
against to get that fixed.
Every engineer would be happy to have an easy, ready-made way to test
the property of their system that they want to believe to be true.
Instead of thank you, we get a childish tantrum.
Unfortunately, it is not that rosy. The problem is that Olcott has not
only been claiming that various D's do not terminate when simulated
by various H's. He's been claiming that the D's do not terminate because >>> they never reach the "do the opposite" logic at all.
For instance, I ran a test on an old Halt.obj pulled from the git
history, and found that when its simulation of the abandoned DD is
continued, it soon hits an infinite loop.
While, for that .obj file, it confirms the claim that the simulated DD
doesn't terminate, the problem is that the simulated DD in that
situation fails to terminate due to getting into the infinite loop,
which is only possible because the simulated HHH(DD) returned non-zero
to simulated DD.
Thus the simulated HHH says, about the doubly-simulated DD, that the
doubly-simulated DD halts A bug or cheat has been exposed in the
machine; it is contradicting itself.
Right. To be overly charitable to PO, I don't believe PO coded things
this way with any intent at "cheating". Firstly, he just didn't see
how to do it "properly", but if he had he'd have probably done it that
way. [Cleaner code without the global data misuse would be fewer lines
of code than what PO ended up with!] Secondly, I think he sees what
he did as a kind of "optimisation" rather than a cheat. He realised
that it would be the outer HHH that always spotted the abort pattern,
and that pattern was not affected by whether the inner HHH's actually
performed the checks, so "no harm" if he just misses them out on the
inner HHH's!
Yes that is correct.
He just wasn't thinking ahead to your RECK resumption of abandoned
emulations!
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
We've always known that PO's implementation of HHH/DD is broken,
Olcott knows that continuing the abandoned simulation uncovers
damning evidence against his contraption, regardless of whether it
halts or not.
ne way to continue to defend it is via the following preposterous
argument: all the odd-numbered simulation levels of DD are
non-terminating, whereas the even-numbered levels (including zero,
directly exedcuted) are terminating. And insist that this is correct.
That narrative is possibly too far-fetched even for the prime
minister of far-fetched land himself.
through the misuse of global data to communicate across emulation
levels and to alter the behaviour of emulations depending on emulation
depth. Until that issue is fixed, anything PO claims is /proved/ by
his C code is nonsense. PO can only argue his code /proves/
something, if that code is actually correct!
I just exhaustively proved my whole proof again
with the above snippet.
Unfortunately, until the global data issue is resolved, anything your
RECK code shows about the behaviour of PO's abandoned emulations is
effectively commenting more on the fickle behaviour of PO's global
data interactions than anything else. A kind of nonsense-in-nonsense
out! (Not your fault in the slightest.)
I don't think PO is capable of fixing his code, and I won't be helping
him on that front. [I did once start explaining exactly what PO
needed to do, code-wise, but he just ignored that and continued
replying as usual, accusing me of not paying attention and lacking
basic competence etc., and that moment has passed!]
Starting over with an embedded C interpreter could work
if it was not made moot by the above code snippet.
Meanwhile, we sometimes kind of pretend that PO has fixed the problem,
and people discuss what his code /WOULD/ do /assuming/ that basic
issue had been resolved. That is being charitable to PO, and is
sometimes referred to as "steel-manning".
<https://en.wikipedia.org/wiki/Straw_man#Steelmanning>
Very little of PO's arguments would change : his HHH would still
decide neverhalts for DD, and DD() would still halt when run directly,
same as happens with the broken code. All the usual objections raised
by posters here also continue to apply, so any such "steel-manned"
arguments are still seen to be just as silly as the non-steel-manned
versions. So we may well choose to be charitable on this point!
We end up at the same place as my above code snippet
already establishes. Thus people would finally see
the first step of my proof so
we could move on to the next step of semantic properties
of finite string inputs.
No decider can compute anything other than a mapping
from its finite string inputs. Everything else is outside
of the scope of Turing machines.
[The only thing I can think of that changes would be the HHH/HHH1
comparison: if the global data misuse were fixed, both HHH(DD) and
HHH1(DD) would return 0, so PO would lose one of his (silly) arguments
that emulation behaviour depends on who is doing the emulating...]
Not if we pay close attention to the little snippet
of code above. An H1 would take the place of HHH1.
Your comments on how PO's abandoned emulations should behave if
resumed would work fine if PO had fixed the global code issues - each
resumed emulation would halt, because in effect each emulation level
behaves the same, simply tracking the steps of the "native"
computation which halts. So the point you are trying to convince PO
of stands. [But unfortunately will never convince PO...]
Mike.
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
Starting over with an embedded C interpreter could work
if it was not made moot by the above code snippet.
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
Then you can't be telling the truth.
On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
Then you can't be telling the truth.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
Then you can't be telling the truth.
LOL!
Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
- You used to post execution traces claiming that they
proved you were right.
- You used to deride others for not following your
execution traces in detail (maybe they are not skilled
engineers)
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
This is just empty claptrap about an ill-defined program
with a missing definition of H, not an execution trace.
Mere Rhetoric Bereft of Reasoning (MRBOR)
Only execution traces are real.
You are a less skilled coding technician than I estimated.
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
Then you can't be telling the truth.
LOL!
Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
- You used to post execution traces claiming that they
proved you were right.
- You used to deride others for not following your
execution traces in detail (maybe they are not skilled
engineers)
On 10/27/2025 11:54 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
Then you can't be telling the truth.
LOL!
Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
- You used to post execution traces claiming that they
proved you were right.
- You used to deride others for not following your
execution traces in detail (maybe they are not skilled
engineers)
I suppose from now on if he ever posts a trace we can remind him that he "can't be telling the truth".
On 28/10/2025 00:37, Kaz Kylheku wrote:
On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
I am only referring to these fifteen lines
A straight forward sequence of steps that any
C programmer can easily determine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you have nothing as this is incomplete and cannot be run.
When I posted the git repo several days ago, Olcott immediately
called me dishonest and replied with the above nonsense.
He has been repeating it ever since.
Basically a meltdown, of sorts.
Oh yeah, he's thrashing. He knows he's been beat and doesn't dare look >>>> at your code, lest he has to admit he wasted the last 21 years.
But I explained that the code can help you validate that your cheats are >>> working. If you want to say that DDD simulated by HHH does not halt, and >>> not be lying, you can now test that actual claim. If the simulated DDD
halts, and you would like it not to, you have something to iterate
against to get that fixed.
Every engineer would be happy to have an easy, ready-made way to test
the property of their system that they want to believe to be true.
Instead of thank you, we get a childish tantrum.
Unfortunately, it is not that rosy. The problem is that Olcott has not
only been claiming that various D's do not terminate when simulated
by various H's. He's been claiming that the D's do not terminate because
they never reach the "do the opposite" logic at all.
For instance, I ran a test on an old Halt.obj pulled from the git
history, and found that when its simulation of the abandoned DD is
continued, it soon hits an infinite loop.
While, for that .obj file, it confirms the claim that the simulated DD
doesn't terminate, the problem is that the simulated DD in that
situation fails to terminate due to getting into the infinite loop,
which is only possible because the simulated HHH(DD) returned non-zero
to simulated DD.
Thus the simulated HHH says, about the doubly-simulated DD, that the
doubly-simulated DD halts A bug or cheat has been exposed in the
machine; it is contradicting itself.
Right. To be overly charitable to PO, I don't believe PO coded things
this way with any intent at "cheating". Firstly, he just didn't see how
to do it "properly", but if he had he'd have probably done it that way. [Cleaner code without the global data misuse would be fewer lines of
code than what PO ended up with!] Secondly, I think he sees what he did
as a kind of "optimisation" rather than a cheat. He realised that it
would be the outer HHH that always spotted the abort pattern, and that pattern was not affected by whether the inner HHH's actually performed
the checks, so "no harm" if he just misses them out on the inner HHH's!
He just wasn't thinking ahead to your RECK resumption of abandoned emulations!
We've always known that PO's implementation of HHH/DD is broken, through
Olcott knows that continuing the abandoned simulation uncovers
damning evidence against his contraption, regardless of whether it
halts or not.
ne way to continue to defend it is via the following preposterous
argument: all the odd-numbered simulation levels of DD are
non-terminating, whereas the even-numbered levels (including zero,
directly exedcuted) are terminating. And insist that this is correct.
That narrative is possibly too far-fetched even for the prime
minister of far-fetched land himself.
the misuse of global data to communicate across emulation levels and to alter the behaviour of emulations depending on emulation depth. Until
that issue is fixed, anything PO claims is /proved/ by his C code is nonsense. PO can only argue his code /proves/ something, if that code
is actually correct!
Unfortunately, until the global data issue is resolved, anything your
RECK code shows about the behaviour of PO's abandoned emulations is effectively commenting more on the fickle behaviour of PO's global data interactions than anything else. A kind of nonsense-in-nonsense out!
(Not your fault in the slightest.)
I don't think PO is capable of fixing his code, and I won't be helping
him on that front. [I did once start explaining exactly what PO needed
to do, code-wise, but he just ignored that and continued replying as
usual, accusing me of not paying attention and lacking basic competence etc., and that moment has passed!]
Meanwhile, we sometimes kind of pretend that PO has fixed the problem,
and people discuss what his code /WOULD/ do /assuming/ that basic issue
had been resolved. That is being charitable to PO, and is sometimes referred to as "steel-manning".
<https://en.wikipedia.org/wiki/Straw_man#Steelmanning>
Very little of PO's arguments would change : his HHH would still decide neverhalts for DD, and DD() would still halt when run directly, same as happens with the broken code. All the usual objections raised by
posters here also continue to apply, so any such "steel-manned"
arguments are still seen to be just as silly as the non-steel-manned versions. So we may well choose to be charitable on this point!
[The only thing I can think of that changes would be the HHH/HHH1 comparison: if the global data misuse were fixed, both HHH(DD) and
HHH1(DD) would return 0, so PO would lose one of his (silly) arguments
that emulation behaviour depends on who is doing the emulating...]
Your comments on how PO's abandoned emulations should behave if resumed would work fine if PO had fixed the global code issues - each resumed emulation would halt, because in effect each emulation level behaves the same, simply tracking the steps of the "native" computation which
halts. So the point you are trying to convince PO of stands. [But unfortunately will never convince PO...]
Mike.
On 10/27/2025 9:24 PM, Mike Terry wrote:
On 28/10/2025 00:37, Kaz Kylheku wrote:
On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
I am only referring to these fifteen lines
A straight forward sequence of steps that any
C programmer can easily determine:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you have nothing as this is incomplete and cannot be run.
When I posted the git repo several days ago, Olcott immediately
called me dishonest and replied with the above nonsense.
He has been repeating it ever since.
Basically a meltdown, of sorts.
Oh yeah, he's thrashing. He knows he's been beat and doesn't dare >>>>> look
at your code, lest he has to admit he wasted the last 21 years.
But I explained that the code can help you validate that your cheats
are
working. If you want to say that DDD simulated by HHH does not halt,
and
not be lying, you can now test that actual claim. If the simulated DDD >>>> halts, and you would like it not to, you have something to iterate
against to get that fixed.
Every engineer would be happy to have an easy, ready-made way to test
the property of their system that they want to believe to be true.
Instead of thank you, we get a childish tantrum.
Unfortunately, it is not that rosy. The problem is that Olcott has not
only been claiming that various D's do not terminate when simulated
by various H's. He's been claiming that the D's do not terminate because >>> they never reach the "do the opposite" logic at all.
For instance, I ran a test on an old Halt.obj pulled from the git
history, and found that when its simulation of the abandoned DD is
continued, it soon hits an infinite loop.
While, for that .obj file, it confirms the claim that the simulated DD
doesn't terminate, the problem is that the simulated DD in that
situation fails to terminate due to getting into the infinite loop,
which is only possible because the simulated HHH(DD) returned non-zero
to simulated DD.
Thus the simulated HHH says, about the doubly-simulated DD, that the
doubly-simulated DD halts A bug or cheat has been exposed in the
machine; it is contradicting itself.
Right. To be overly charitable to PO, I don't believe PO coded things
this way with any intent at "cheating". Firstly, he just didn't see
how to do it "properly", but if he had he'd have probably done it that
way. [Cleaner code without the global data misuse would be fewer lines
of code than what PO ended up with!] Secondly, I think he sees what
he did as a kind of "optimisation" rather than a cheat. He realised
that it would be the outer HHH that always spotted the abort pattern,
and that pattern was not affected by whether the inner HHH's actually
performed the checks, so "no harm" if he just misses them out on the
inner HHH's! He just wasn't thinking ahead to your RECK resumption of
abandoned emulations!
We've always known that PO's implementation of HHH/DD is broken,
Olcott knows that continuing the abandoned simulation uncovers
damning evidence against his contraption, regardless of whether it
halts or not.
ne way to continue to defend it is via the following preposterous
argument: all the odd-numbered simulation levels of DD are
non-terminating, whereas the even-numbered levels (including zero,
directly exedcuted) are terminating. And insist that this is correct.
That narrative is possibly too far-fetched even for the prime
minister of far-fetched land himself.
through the misuse of global data to communicate across emulation
levels and to alter the behaviour of emulations depending on emulation
depth. Until that issue is fixed, anything PO claims is /proved/ by
his C code is nonsense. PO can only argue his code /proves/
something, if that code is actually correct!
Unfortunately, until the global data issue is resolved, anything your
RECK code shows about the behaviour of PO's abandoned emulations is
effectively commenting more on the fickle behaviour of PO's global
data interactions than anything else. A kind of nonsense-in-nonsense
out! (Not your fault in the slightest.)
I don't think PO is capable of fixing his code, and I won't be helping
him on that front. [I did once start explaining exactly what PO
needed to do, code-wise, but he just ignored that and continued
replying as usual, accusing me of not paying attention and lacking
basic competence etc., and that moment has passed!]
Meanwhile, we sometimes kind of pretend that PO has fixed the problem,
and people discuss what his code /WOULD/ do /assuming/ that basic
issue had been resolved. That is being charitable to PO, and is
sometimes referred to as "steel-manning".
<https://en.wikipedia.org/wiki/Straw_man#Steelmanning>
Very little of PO's arguments would change : his HHH would still
decide neverhalts for DD, and DD() would still halt when run directly,
same as happens with the broken code. All the usual objections raised
by posters here also continue to apply, so any such "steel-manned"
arguments are still seen to be just as silly as the non-steel-manned
versions. So we may well choose to be charitable on this point!
[The only thing I can think of that changes would be the HHH/HHH1
comparison: if the global data misuse were fixed, both HHH(DD) and
HHH1(DD) would return 0, so PO would lose one of his (silly) arguments
that emulation behaviour depends on who is doing the emulating...]
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
When H1 simulates D this D does reach its own
simulated "return" statement final halt state
because the H(D) that it calls returns 0.
On 10/27/2025 11:04 PM, dbush wrote:
I suppose from now on if he ever posts a trace we can remind him that he
"can't be telling the truth".
int D()
{
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
On 10/27/2025 11:04 PM, dbush wrote:
I suppose from now on if he ever posts a trace we can remind him that he >>> "can't be telling the truth".
int D()
{
And there we go!
olcott repies to dbush, long before Hallowe'en.
I posted this just hours ago:
On 2025-10-28, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2025-10-27, olcott <polcott333@gmail.com> wrote:
>> On 10/27/2025 6:05 PM, dbush wrote:
>> *plonk*
>
> I predict he will reply to a post by dbush before Hallowe'en.
Even your plonks are lies.
On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
Then you can't be telling the truth.
LOL!
Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
- You used to post execution traces claiming that they
proved you were right.
- You used to deride others for not following your
execution traces in detail (maybe they are not skilled
engineers)
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
This is just empty claptrap about an ill-defined program
with a missing definition of H, not an execution trace.
So you cannot begin to imagine WTF happens when D
is simulated by H?
On 10/27/2025 11:04 PM, dbush wrote:
On 10/27/2025 11:54 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
Once H has correctly determines that its simulated
D cannot possibly reach its own simulated "return"
instruction final halt state it is nutty to do
anything else besides abort and reject the input.
I have traces which prove otherwise.
Then you can't be telling the truth.
LOL!
Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
- You used to post execution traces claiming that they
proved you were right.
- You used to deride others for not following your
execution traces in detail (maybe they are not skilled
engineers)
I suppose from now on if he ever posts a trace we can remind him that
he "can't be telling the truth".
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
Am Sat, 25 Oct 2025 15:30:59 -0500 schrieb olcott:
On 10/25/2025 7:36 AM, Mikko wrote:
On 2025-10-24 14:54:25 +0000, olcott said:
On 10/24/2025 7:04 AM, joes wrote:
Am Fri, 24 Oct 2025 02:47:03 -0500 schrieb olcott:
On 10/24/2025 2:34 AM, joes wrote:
I.e. not stuck.I didn’t expect you to think obvious nonsense. I accept that HHH >>>>>>> does not compute DD according to the same semantics as HHH1, a UTM >>>>>>> or hardware processor. This makes the input ambiguous. HHH’sIt conclusively proves the behavior that the input to HHH(DD)
interpretation doesn’t prove shit about anything,
specifies. It requires the simulated HHH and the simulated DD to
remain stuck in recursive simulation forever until the outermost HHH >>>>>> breaks out of this.
That HHH returns 0 only shows that it does so. This means it does not >>>>> interpret DD according to x86 semantics as HHH1, a UTM and a
processor do. In your view nothing else can compute what HHH does;
everything does its own interpretation. This means that anything
different than directly executing DD is supremely unsuited to
determining anything about it.
HHH(DD) DD calls HHH(DD) in recursive simulation.
There is a finitely recursive simulation in DD
I AM NOT TALKING ABOUT DD I AM TAKING ABOUT DD SIMULATED BY HHH
There is also a finitely recursive simulation in DD. (Yes, HHH
doesn’t simulate it to termination.)
I have said that 10,000 times now and so far no one has got it.
Maybe change your approach?
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,076 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 81:34:15 |
| Calls: | 13,805 |
| Files: | 186,990 |
| D/L today: |
7,331 files (2,461M bytes) |
| Messages: | 2,443,323 |