Am Tue, 19 Aug 2025 17:01:20 -0500 schrieb olcott:
On 8/19/2025 4:42 PM, dbush wrote:
On 8/19/2025 4:59 PM, Chris M. Thomasson wrote:
On 8/18/2025 3:46 PM, olcott wrote:
Please clarify what is wrong and what would be correct.His argument is that the decision that X(Y) is making is not "doesYes.
algorithm Y halt", but basically "does there exist an implementation of
function X that can simulate function call Y() to completion?"
This happens to coincide with the halting function in cases whereYou are wrong about this.
function Y does not call function X at some point, but not in cases
where it does.
--QFTHe's saying "this is the mapping that the HHH I've implemented is
computing, therefore this mapping is actually the correct one."
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
OK, let’s have it simulate one instruction then. Where’s the cutoff?Of course, it ignores HHH's source code, but I have precedent to tellSaying that not doing any simulation is the correct way to do a
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
On 8/19/2025 6:44 PM, olcott wrote:
On 8/19/2025 8:02 PM, Chris M. Thomasson wrote:
On 8/19/2025 5:56 PM, olcott wrote:
On 8/19/2025 7:48 PM, Richard Heathfield wrote:
On 20/08/2025 01:38, olcott wrote:Not simulating a f-cking thing is not a correct
On 8/19/2025 7:16 PM, Richard Heathfield wrote:
On 20/08/2025 00:48, olcott wrote:
On 8/19/2025 6:35 PM, Richard Heathfield wrote:
On 19/08/2025 23:08, olcott wrote:
<snip>
I don't care if Heathfield disagrees with himself,
Where have I done so?
My quote of him does agree with me and all five LLM systems. >>>>>>>>>
Yes, it shows that you can correctly simulate HHH by replacing
it with a macro: #define HHH(x) 0
That is a jackass stupid idea
No, I don't think so.
because it breaks
HHH reporting on halting inputs
It's already broken.
Besides, it's correct simulation. HHH /does/ return 0.
simulation jackass.
I want you to feel my anger.
Huh? Are going to go really nuts on us here? Are you a violent sod?
I just want to to understand that playing
trollish head games can result in the end
of life on the Earth because liars have
prevented the required quorum of support
to take corrective action on climate change.
climate change? Then stop using AI. So much power... ;^)
When Boolean True(Language L, Expression E)
becomes computable (thus refuting Tarski)
these kinds of lies can be annihilated in real time.
My work on the HP can be applied to this.
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the cutoff?Of course, it ignores HHH's source code, but I have precedent to tellSaying that not doing any simulation is the correct way to do a
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the rest of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is the
correct way to do a simulation in ridiculously incorrect and you know it."
But my simulation correctly simulates just as many lines as his does.
Op 19.aug.2025 om 16:41 schreef olcott:
On 8/19/2025 1:46 AM, Richard Heathfield wrote:
On 19/08/2025 05:21, Mike Terry wrote:
On 19/08/2025 03:40, Richard Heathfield wrote:
On 19/08/2025 03:07, dbush wrote:
<snip>
So we see that Richard Heathfield agreed that HHH can't give a
correct answer, as Linz and other have proved and as you have
*explicitly* agreed is correct.
I look at it this way.
HHH cannot reasonably abort as soon as it detects recursion. After
all, there are lots of recursive algorithms around, and plenty of
them terminate. It has to dig a little deeper than that.
So by the time we're some way in, we have several levels of recursion: >>>>>
DD -> HHH -> DD -> HHH -> DD -> HHH -> DD
      (a)         (b)         (c)
Let's say (c) decides enough is enough.
I think maybe you're not distinguishing properly between recursive
call and recursive emulation.
You may be right, or you may not be, but my explanation seems at
least at first glance to hold together, makes intuitive sense, and
goes some way to explaining why some one could cling to the wrong
answer for 22 years.
If we were talking *recursive call*, (c) might end the recursion in
the way you describe due to having been called with different input,
Or indeed identical input. After all, what's changing?
allowing control to percolate back through (b) and then to (a).
That's how a simple Factorial implementation might work:
  int Factorial (int n)
  {
    if (n == 1)
      return 1;
    else
      return n * Factorial (n-1);
Terrible example, but has the merit of familiarity.
  }
When evaluating Factorial(3), a nested Factorial(2) is called, which
in turn nests a Factorial(1) call. That call returns and the
recursion breaks (from inner to outer invocations).
Great, everyone knows this example. Note that it requires that the
nested calls are made with differnt arguments.
Indeed, although of course it doesn't have to be that way.
In the case of PO's DD/HHH, the arguments are (or at least
represent) exactly the same computation to be emulated at each
level. So (c) [an L2 = Level 2 emulation] will not suddenly decide
its had enough - if it did, then (a) would have done it earlier.
Then either there's some state kicking around, or HHH will
automatically decide that all recursion is runaway recursion.
But with DD/HHH we have *recursive emulation*. So HHH [a] is still
running when (c) is reached - it's busy running around its "emulate
instruction" loop, testing each time round whether its seen enough
evidence to decide to quit emulating.
Okay, so that's clearly a design flaw. Bit I do see the point. /
Because/ of that design flaw, the fix isn't going to be an easy one.
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
And it shows the bug in the code. HHH incorrectly assumes a non-
termination behaviour when there is only a finite recursion.
It does not correctly analyse the conditional branch instructions during
the simulation. It does not prove that the conditions for the alternate branches will never be met when the simulation would continue.
<snip>
OTOH you could say that since HHH only has to handle ONE INPUT CASE
(DD), PO might have optimised the HHH code to just return 0 straight
away, and the result would be the same! That's true - DD would
still halt, and HHH would still claim it never halts. The problem
here is that all the emulation stuff is /required/ so that PO can
confuse himself into thinking something more magical is going on,
justifying various crazy claims.
Hell of a way to run a railroad. Still, no harm done. At least now I
know how he /could/ have got the programming right, even if his
theory is further round the bend than Harpic.
Turing machine deciders only compute the mapping
from their inputs...
and the input to HHH(DD) specifies runaway recursion.
As usual an incorrect claim without evidence.
The input specifies a DD based on a HHH that aborts the simulation after
a few cycles. This means that this input specifies a program with a
finite recursion, followed by a final halt state.
Op 20.aug.2025 om 00:35 schreef olcott:
ChatGPT 4.0, 5.0 Claude AI, Grok and Gemini
all figured out on their own what the
*recursive simulation non-halting behavior pattern*
is and that on that basis HHH(DD)==0 is correct.
Based on the incorrect assumption that HHH detects a non-termination behaviour.
On 2025-08-20, Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 20.aug.2025 om 00:35 schreef olcott:
ChatGPT 4.0, 5.0 Claude AI, Grok and Gemini
all figured out on their own what the
*recursive simulation non-halting behavior pattern*
is and that on that basis HHH(DD)==0 is correct.
Based on the incorrect assumption that HHH detects a non-termination
behaviour.
But it does. His contraption works that far. HHH (outer) detects
the non-termination of DD calling HHH (inner). It is contrived
to detect that specific case of nontermination.
HHH splits itself into two by burning a static fuse variable.
That's nice, but the use of two deciders, only one of which is being contradicted by the test case, doesn't disprove anything.
ChatGPT, Claude et al have been trained on Internet texts;
they must be assumed to contain the Olcott Halting Theory.
When you ask about the theory (using the same identifiers like HHH
and all), the token prediction likely starts romping through the
kooky fields of Usenet texts.
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that takes a function pointer it can
only assign or dereference, and then returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
That can't happen - (c) is performing the same calculation as (a): same code and the same input.
Sure it could. When HHH detects that it's about to recurse into itself it could just start off a
new simulation, and if it starts to run away with itself it could can /its/ simulation and return 0.
You are describing recursive /simulation/ (or emulation). (I think...) HHH does not involve
recursive call, so what I was saying does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new simulation every time it hit DD's
HHH call, that would be quite clever. It would be easy to add static metrics to make the call about
aborting the recursion and unwinding the stack back to where it can continue simulating DD, and
nothing would be discarded as being "unreachable".
Hence...
That way, it might even get the rightwrong™ answer as opposed to the wrongwrong™ answer it gets
at present.
But like you say, it doesn't work like that.
But it *could*, so the notion that the last few lines of DD are unreachable is simply wrong.
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the cutoff?Of course, it ignores HHH's source code, but I have precedent to tell >>>>> me that that's okay when correctly simulating.Saying that not doing any simulation is the correct way to do a
simulation in ridiculously incorrect and you know it.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the rest of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is the
correct way to do a simulation in ridiculously incorrect and you know
it."
But my simulation correctly simulates just as many lines as his does.
Things a damned liar would say
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
One instruction.OK, let’s have it simulate one instruction then. Where’s the cutoff? >>>Of course, it ignores HHH's source code, but I have precedent to tell >>>>>> me that that's okay when correctly simulating.Saying that not doing any simulation is the correct way to do a
simulation in ridiculously incorrect and you know it.
HHH only bothers simulating DD's call to HHH. It ignores the rest of DD. >>>
As Mr Olcott puts it: "Saying that not doing any simulation is the
correct way to do a simulation in ridiculously incorrect and you know
it."
But my simulation correctly simulates just as many lines as his does.
Things a damned liar would say
Wow!
On 8/20/2025 3:19 PM, Chris M. Thomasson wrote:
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
One instruction.OK, let’s have it simulate one instruction then. Where’s the cutoff? >>>>Of course, it ignores HHH's source code, but I have precedent to >>>>>>> tellSaying that not doing any simulation is the correct way to do a
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
HHH only bothers simulating DD's call to HHH. It ignores the rest of
DD.
As Mr Olcott puts it: "Saying that not doing any simulation is the
correct way to do a simulation in ridiculously incorrect and you
know it."
But my simulation correctly simulates just as many lines as his does.
Things a damned liar would say
Wow!
If we wouldn't have called Trump's lies about election
fraud mere "misinformation" and called the damned lies
of a damned liar the threat to Democracy may have been
averted.
Here is the proof that Richard Heathfield is a damned liar
about HHH correctly simulating zero instructions.
On 8/20/2025 1:27 PM, olcott wrote:
On 8/20/2025 3:19 PM, Chris M. Thomasson wrote:
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
One instruction.OK, let’s have it simulate one instruction then. Where’s the cutoff? >>>>>Of course, it ignores HHH's source code, but I have precedent to >>>>>>>> tellSaying that not doing any simulation is the correct way to do a
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
HHH only bothers simulating DD's call to HHH. It ignores the rest
of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is the
correct way to do a simulation in ridiculously incorrect and you
know it."
But my simulation correctly simulates just as many lines as his does. >>>>>
Things a damned liar would say
Wow!
If we wouldn't have called Trump's lies about election
fraud mere "misinformation" and called the damned lies
of a damned liar the threat to Democracy may have been
averted.
Huh? Does your brain have enough oxygen? Are you drowning or something?
A quick sand of your own lies?
On 8/20/2025 3:32 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:27 PM, olcott wrote:
On 8/20/2025 3:19 PM, Chris M. Thomasson wrote:
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the cutoff?Of course, it ignores HHH's source code, but I have precedent >>>>>>>>> to tellSaying that not doing any simulation is the correct way to do a >>>>>>>> simulation in ridiculously incorrect and you know it.
me that that's okay when correctly simulating.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the rest >>>>>> of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is the >>>>>> correct way to do a simulation in ridiculously incorrect and you
know it."
But my simulation correctly simulates just as many lines as his does. >>>>>>
Things a damned liar would say
Wow!
If we wouldn't have called Trump's lies about election
fraud mere "misinformation" and called the damned lies
of a damned liar the threat to Democracy may have been
averted.
Huh? Does your brain have enough oxygen? Are you drowning or
something? A quick sand of your own lies?
#LiesAboutElectionFraud
Never any evidence of election fraud
that could possibly change the results.
Trump is just copying Hitler's "big lie"
On 8/20/2025 1:41 PM, olcott wrote:
On 8/20/2025 3:32 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:27 PM, olcott wrote:
On 8/20/2025 3:19 PM, Chris M. Thomasson wrote:
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the >>>>>>>> cutoff?Of course, it ignores HHH's source code, but I have precedent >>>>>>>>>> to tellSaying that not doing any simulation is the correct way to do a >>>>>>>>> simulation in ridiculously incorrect and you know it.
me that that's okay when correctly simulating.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the rest >>>>>>> of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is
the correct way to do a simulation in ridiculously incorrect and >>>>>>> you know it."
But my simulation correctly simulates just as many lines as his >>>>>>> does.
Things a damned liar would say
Wow!
If we wouldn't have called Trump's lies about election
fraud mere "misinformation" and called the damned lies
of a damned liar the threat to Democracy may have been
averted.
Huh? Does your brain have enough oxygen? Are you drowning or
something? A quick sand of your own lies?
#LiesAboutElectionFraud
Never any evidence of election fraud
that could possibly change the results.
Trump is just copying Hitler's "big lie"
And your halt decider is? Crap, Lie, or both?
On 8/20/2025 3:42 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:41 PM, olcott wrote:
On 8/20/2025 3:32 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:27 PM, olcott wrote:
On 8/20/2025 3:19 PM, Chris M. Thomasson wrote:
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the >>>>>>>>> cutoff?Of course, it ignores HHH's source code, but I have precedent >>>>>>>>>>> to tellSaying that not doing any simulation is the correct way to do a >>>>>>>>>> simulation in ridiculously incorrect and you know it.
me that that's okay when correctly simulating.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the
rest of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is >>>>>>>> the correct way to do a simulation in ridiculously incorrect and >>>>>>>> you know it."
But my simulation correctly simulates just as many lines as his >>>>>>>> does.
Things a damned liar would say
Wow!
If we wouldn't have called Trump's lies about election
fraud mere "misinformation" and called the damned lies
of a damned liar the threat to Democracy may have been
averted.
Huh? Does your brain have enough oxygen? Are you drowning or
something? A quick sand of your own lies?
#LiesAboutElectionFraud
Never any evidence of election fraud
that could possibly change the results.
Trump is just copying Hitler's "big lie"
And your halt decider is? Crap, Lie, or both?
Verifiably correct as all Five LLM systems agree.
On 8/20/2025 3:42 PM, Chris M. Thomasson wrote:Not a halt decider as you have admitted on the record:
On 8/20/2025 1:41 PM, olcott wrote:
On 8/20/2025 3:32 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:27 PM, olcott wrote:
On 8/20/2025 3:19 PM, Chris M. Thomasson wrote:
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the >>>>>>>>> cutoff?Of course, it ignores HHH's source code, but I have precedent >>>>>>>>>>> to tellSaying that not doing any simulation is the correct way to do a >>>>>>>>>> simulation in ridiculously incorrect and you know it.
me that that's okay when correctly simulating.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the
rest of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is >>>>>>>> the correct way to do a simulation in ridiculously incorrect and >>>>>>>> you know it."
But my simulation correctly simulates just as many lines as his >>>>>>>> does.
Things a damned liar would say
Wow!
If we wouldn't have called Trump's lies about election
fraud mere "misinformation" and called the damned lies
of a damned liar the threat to Democracy may have been
averted.
Huh? Does your brain have enough oxygen? Are you drowning or
something? A quick sand of your own lies?
#LiesAboutElectionFraud
Never any evidence of election fraud
that could possibly change the results.
Trump is just copying Hitler's "big lie"
And your halt decider is? Crap, Lie, or both?
Verifiably
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 20/08/2025 03:08, Richard Heathfield wrote:
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that takes
a function pointer it can only assign or dereference, and then
returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive
simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
That can't happen - (c) is performing the same calculation as (a):
same code and the same input.
Sure it could. When HHH detects that it's about to recurse into
itself it could just start off a new simulation, and if it starts to
run away with itself it could can /its/ simulation and return 0.
You are describing recursive /simulation/ (or emulation). (I
think...)Â HHH does not involve recursive call, so what I was saying
does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new
simulation every time it hit DD's HHH call, that would be quite
clever. It would be easy to add static metrics to make the call about
aborting the recursion and unwinding the stack back to where it can
continue simulating DD, and nothing would be discarded as being
"unreachable".
Let's see if I've fully got what you're saying. I'll use notation
HHH[n] for HHH running at nested simulation level n. So HHH[0] is outer HHH etc.
[Yeah, I know your eyes are already starting to glaze over! All I can
say is the steps below are little steps with no big jumps, so if you
grab a pad and pen and cup of tea you can get through it - believe that
that can happen!!]
1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to spin
up a new
  simulation of ... DD? [must be...]
On 8/20/2025 1:44 PM, olcott wrote:
On 8/20/2025 3:42 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:41 PM, olcott wrote:
On 8/20/2025 3:32 PM, Chris M. Thomasson wrote:
On 8/20/2025 1:27 PM, olcott wrote:
On 8/20/2025 3:19 PM, Chris M. Thomasson wrote:
On 8/20/2025 7:18 AM, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the >>>>>>>>>> cutoff?Of course, it ignores HHH's source code, but I haveSaying that not doing any simulation is the correct way to do a >>>>>>>>>>> simulation in ridiculously incorrect and you know it.
precedent to tell
me that that's okay when correctly simulating.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the >>>>>>>>> rest of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is >>>>>>>>> the correct way to do a simulation in ridiculously incorrect >>>>>>>>> and you know it."
But my simulation correctly simulates just as many lines as his >>>>>>>>> does.
Things a damned liar would say
Wow!
If we wouldn't have called Trump's lies about election
fraud mere "misinformation" and called the damned lies
of a damned liar the threat to Democracy may have been
averted.
Huh? Does your brain have enough oxygen? Are you drowning or
something? A quick sand of your own lies?
#LiesAboutElectionFraud
Never any evidence of election fraud
that could possibly change the results.
Trump is just copying Hitler's "big lie"
And your halt decider is? Crap, Lie, or both?
Verifiably correct as all Five LLM systems agree.
An what does Trump have to say about this matter? lol.
On 8/20/2025 3:15 PM, Mike Terry wrote:
On 20/08/2025 03:08, Richard Heathfield wrote:
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that takes >>>>> a function pointer it can only assign or dereference, and then
returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive
simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
That can't happen - (c) is performing the same calculation as (a): >>>>>> same code and the same input.
Sure it could. When HHH detects that it's about to recurse into
itself it could just start off a new simulation, and if it starts
to run away with itself it could can /its/ simulation and return 0.
You are describing recursive /simulation/ (or emulation). (I
think...)Â HHH does not involve recursive call, so what I was saying >>>> does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new
simulation every time it hit DD's HHH call, that would be quite
clever. It would be easy to add static metrics to make the call about
aborting the recursion and unwinding the stack back to where it can
continue simulating DD, and nothing would be discarded as being
"unreachable".
Let's see if I've fully got what you're saying. I'll use notation
HHH[n] for HHH running at nested simulation level n. So HHH[0] is
outer HHH etc.
[Yeah, I know your eyes are already starting to glaze over! All I can
say is the steps below are little steps with no big jumps, so if you
grab a pad and pen and cup of tea you can get through it - believe
that that can happen!!]
1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to
spin up a new
   simulation of ... DD? [must be...]
Numbering begins at 0.
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
HHH[0](DD) called from main()
begins simulating its
DD[0] instance. To do this it must create a separate
DD[0] process context with its own set of 16 virtual
registers and virtual stack.
When HHH[0] encounters the call from DD[0] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same
DD[0] process context.
On 8/20/2025 5:01 PM, olcott wrote:
On 8/20/2025 3:15 PM, Mike Terry wrote:
On 20/08/2025 03:08, Richard Heathfield wrote:
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that
takes a function pointer it can only assign or dereference, and
then returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive
simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
You are describing recursive /simulation/ (or emulation). (IThat can't happen - (c) is performing the same calculation as
(a): same code and the same input.
Sure it could. When HHH detects that it's about to recurse into
itself it could just start off a new simulation, and if it starts >>>>>> to run away with itself it could can /its/ simulation and return 0. >>>>>
think...)Â HHH does not involve recursive call, so what I was
saying does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new
simulation every time it hit DD's HHH call, that would be quite
clever. It would be easy to add static metrics to make the call
about aborting the recursion and unwinding the stack back to where
it can continue simulating DD, and nothing would be discarded as
being "unreachable".
Let's see if I've fully got what you're saying. I'll use notation
HHH[n] for HHH running at nested simulation level n. So HHH[0] is
outer HHH etc.
[Yeah, I know your eyes are already starting to glaze over! All I
can say is the steps below are little steps with no big jumps, so if
you grab a pad and pen and cup of tea you can get through it -
believe that that can happen!!]
1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to
spin up a new
   simulation of ... DD? [must be...]
Numbering begins at 0.
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
HHH[0](DD) called from main()
Or more accurately, HHH[0](DD,<empty execution trace>)
On 8/20/2025 4:16 PM, dbush wrote:
On 8/20/2025 5:01 PM, olcott wrote:
On 8/20/2025 3:15 PM, Mike Terry wrote:
On 20/08/2025 03:08, Richard Heathfield wrote:
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that
takes a function pointer it can only assign or dereference, and >>>>>>> then returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive
simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
You are describing recursive /simulation/ (or emulation). (IThat can't happen - (c) is performing the same calculation as >>>>>>>> (a): same code and the same input.
Sure it could. When HHH detects that it's about to recurse into >>>>>>> itself it could just start off a new simulation, and if it starts >>>>>>> to run away with itself it could can /its/ simulation and return 0. >>>>>>
think...)Â HHH does not involve recursive call, so what I was
saying does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new
simulation every time it hit DD's HHH call, that would be quite
clever. It would be easy to add static metrics to make the call
about aborting the recursion and unwinding the stack back to where
it can continue simulating DD, and nothing would be discarded as
being "unreachable".
Let's see if I've fully got what you're saying. I'll use notation
HHH[n] for HHH running at nested simulation level n. So HHH[0] is
outer HHH etc.
[Yeah, I know your eyes are already starting to glaze over! All I
can say is the steps below are little steps with no big jumps, so if
you grab a pad and pen and cup of tea you can get through it -
believe that that can happen!!]
1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to
spin up a new
   simulation of ... DD? [must be...]
Numbering begins at 0.
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
HHH[0](DD) called from main()
Or more accurately, HHH[0](DD,<empty execution trace>)
The execution trace is not needed to correctly
determine that DD correctly simulated by HHH
On 8/20/2025 3:15 PM, Mike Terry wrote:
On 20/08/2025 03:08, Richard Heathfield wrote:
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that takes a function pointer it can
only assign or dereference, and then returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
That can't happen - (c) is performing the same calculation as (a): same code and the same input.
Sure it could. When HHH detects that it's about to recurse into itself it could just start off
a new simulation, and if it starts to run away with itself it could can /its/ simulation and
return 0.
You are describing recursive /simulation/ (or emulation). (I think...) HHH does not involve
recursive call, so what I was saying does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new simulation every time it hit DD's
HHH call, that would be quite clever. It would be easy to add static metrics to make the call
about aborting the recursion and unwinding the stack back to where it can continue simulating DD,
and nothing would be discarded as being "unreachable".
Let's see if I've fully got what you're saying. I'll use notation HHH[n] for HHH running at
nested simulation level n. So HHH[0] is outer HHH etc.
[Yeah, I know your eyes are already starting to glaze over! All I can say is the steps below are
little steps with no big jumps, so if you grab a pad and pen and cup of tea you can get through it
- believe that that can happen!!]
1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to spin up a new
simulation of ... DD? [must be...]
Numbering begins at 0.
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
HHH[0](DD) called from main() begins simulating its
DD[0] instance.
Yeah, I know your eyes are already starting to glaze over!
When DD is run "natively" the so-called "unreachable" code is
reached with no problem.
On 20/08/2025 22:01, olcott wrote:
On 8/20/2025 3:15 PM, Mike Terry wrote:
On 20/08/2025 03:08, Richard Heathfield wrote:
On 20/08/2025 02:37, Mike Terry wrote:
On 19/08/2025 19:06, Richard Heathfield wrote:
<snip>
But HHH is not a factorial calculation. It is a function that
takes a function pointer it can only assign or dereference, and
then returns 0.
ok, we've got onto cross purposes.
Agreed.
I was not talking about HHH, because HHH involves recursive
simulation, not recursive call.
Understood.
Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.
You are describing recursive /simulation/ (or emulation). (IThat can't happen - (c) is performing the same calculation as
(a): same code and the same input.
Sure it could. When HHH detects that it's about to recurse into
itself it could just start off a new simulation, and if it starts >>>>>> to run away with itself it could can /its/ simulation and return 0. >>>>>
think...)Â HHH does not involve recursive call, so what I was
saying does not apply to HHH.
Right.
IF (as I originally thought) HHH worked by recursing into a new
simulation every time it hit DD's HHH call, that would be quite
clever. It would be easy to add static metrics to make the call
about aborting the recursion and unwinding the stack back to where
it can continue simulating DD, and nothing would be discarded as
being "unreachable".
Let's see if I've fully got what you're saying. I'll use notation
HHH[n] for HHH running at nested simulation level n. So HHH[0] is
outer HHH etc.
[Yeah, I know your eyes are already starting to glaze over! All I
can say is the steps below are little steps with no big jumps, so if
you grab a pad and pen and cup of tea you can get through it -
believe that that can happen!!]
1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to
spin up a new
   simulation of ... DD? [must be...]
Numbering begins at 0.
My notation uses [n] to represent "simulation nesting level" n, with the convention that level 0 represents unsimulated code, i.e. called
directly from main().
In a long and detailed reply, on 20/08/2025 21:15, Mike Terry wrote
(among much else):
Yeah, I know your eyes are already starting to glaze over!
They did. But I persevered, and I followed 59.31% of it, according to my notes, which may not be entirely accurate. I think my biggest practical
take from it was that you kinda got my point, which I'll take for what
it's worth, and I got maybe more than half of yours.
When DD is run "natively" the so-called "unreachable" code is reached
with no problem.
Presactly. And /therefore/ a correct simulation must reach it too.
In a long and detailed reply, on 20/08/2025 21:15, Mike Terry wrote (among much else):
Yeah, I know your eyes are already starting to glaze over!
They did. But I persevered, and I followed 59.31% of it, according to my notes, which may not be
entirely accurate. I think my biggest practical take from it was that you kinda got my point, which
I'll take for what it's worth, and I got maybe more than half of yours.
When DD is run "natively" the so-called "unreachable" code is reached with no problem.
Presactly. And /therefore/ a correct simulation must reach it too.
And your halt decider is? Crap, Lie, or both?
On 21/08/2025 02:45, Richard Heathfield wrote:
In a long and detailed reply, on 20/08/2025 21:15, Mike Terry wrote
(among much else):
Yeah, I know your eyes are already starting to glaze over!
They did. But I persevered, and I followed 59.31% of it, according to
my notes, which may not be entirely accurate. I think my biggest
practical take from it was that you kinda got my point, which I'll
take for what it's worth, and I got maybe more than half of yours.
When DD is run "natively" the so-called "unreachable" code is reached
with no problem.
Presactly. And /therefore/ a correct simulation must reach it too.
Excisely. Or at least being careful we might say a "correct /full/ simulation", in case we are talking to people of the persuasion that
partial simulations are ok things to talk about and indeed are the
"default" meaning for "simulation" without further qualification. We
want to converse without misunderstanding with as many people as possible!
In any case we also agree that a correct /partial/ simulation [*] need / not/ "reach" that code. E.g. perhaps just one x86 instruction is
(correctly) simulated and then the (partial) simulation is abandonned
for whatever reason. There is nothing amiss here, unless the programmer claims the code after the first instruction is "unreachable"! Who's to
say subsequent instructions can't be reached by a longer simulation, or simply by executing the code natively?
Mike.
[*] meaning a partial simulation that simulated the right sequence of instructions with the right data, up to the point where it decides to
stop for whatever reason.
On 20/08/2025 21:42, Chris M. Thomasson wrote:
<snip>
And your halt decider is? Crap, Lie, or both?
Well, it gets the answer wrong, as one can easily see by compiling and running DD().
Of course, that doesn't answer /your/ question.
I don't /know/ the answer to your question, but I can guess, of course,
and my guess is that it's crap.
Maybe - just *maybe* - Mr Olcott has managed to keep a gag running for
22 years and still finds it amusing to parade his Comp Sci bollocks
around and lure people into taking him seriously while he stuffs a
satyrical fist into his mouth and chortles at us all. I have to concede
the possibility.
But I don't think so. I think he's sincere; I really do. Hopelessly misguided? Sure. Innately unable to "get" Turing's point? Indubitably. Capable of misrepresenting people in the hope that he can twist their
words into support for his case? No question (videlicet his citation of
my agreeing that he has a case for returning 0 from HHH(DD), which he stopped doing only when I turned it into a #define)? Without question.
But I don't think he's lying about his 'decider'. I really think he
really thinks he's got something.
So it's not a lie. It's just crap. Sheer, unmitigated bollocks, but
probably sincere bollocks.
Does that answer your question?
On 8/20/2025 9:25 PM, Richard Heathfield wrote:
On 20/08/2025 21:42, Chris M. Thomasson wrote:
<snip>
And your halt decider is? Crap, Lie, or both?
Well, it gets the answer wrong, as one can easily see by
compiling and running DD().
Of course, that doesn't answer /your/ question.
I don't /know/ the answer to your question, but I can guess, of
course, and my guess is that it's crap.
Maybe - just *maybe* - Mr Olcott has managed to keep a gag
running for 22 years and still finds it amusing to parade his
Comp Sci bollocks around and lure people into taking him
seriously while he stuffs a satyrical fist into his mouth and
chortles at us all. I have to concede the possibility.
But I don't think so. I think he's sincere; I really do.
Hopelessly misguided? Sure. Innately unable to "get" Turing's
point? Indubitably. Capable of misrepresenting people in the
hope that he can twist their words into support for his case?
No question (videlicet his citation of my agreeing that he has
a case for returning 0 from HHH(DD), which he stopped doing
only when I turned it into a #define)? Without question. But I
don't think he's lying about his 'decider'. I really think he
really thinks he's got something.
So it's not a lie. It's just crap. Sheer, unmitigated bollocks,
but probably sincere bollocks.
Does that answer your question?
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
On 8/20/2025 4:16 AM, Fred. Zwarts wrote:
Op 19.aug.2025 om 16:41 schreef olcott:
On 8/19/2025 1:46 AM, Richard Heathfield wrote:
On 19/08/2025 05:21, Mike Terry wrote:
On 19/08/2025 03:40, Richard Heathfield wrote:
On 19/08/2025 03:07, dbush wrote:
<snip>
So we see that Richard Heathfield agreed that HHH can't give a
correct answer, as Linz and other have proved and as you have
*explicitly* agreed is correct.
I look at it this way.
HHH cannot reasonably abort as soon as it detects recursion. After >>>>>> all, there are lots of recursive algorithms around, and plenty of >>>>>> them terminate. It has to dig a little deeper than that.
So by the time we're some way in, we have several levels of
recursion:
DD -> HHH -> DD -> HHH -> DD -> HHH -> DD
      (a)         (b)         (c)
Let's say (c) decides enough is enough.
I think maybe you're not distinguishing properly between recursive
call and recursive emulation.
You may be right, or you may not be, but my explanation seems at
least at first glance to hold together, makes intuitive sense, and
goes some way to explaining why some one could cling to the wrong
answer for 22 years.
If we were talking *recursive call*, (c) might end the recursion in >>>>> the way you describe due to having been called with different input,
Or indeed identical input. After all, what's changing?
allowing control to percolate back through (b) and then to (a).
That's how a simple Factorial implementation might work:
  int Factorial (int n)
  {
    if (n == 1)
      return 1;
    else
      return n * Factorial (n-1);
Terrible example, but has the merit of familiarity.
  }
When evaluating Factorial(3), a nested Factorial(2) is called,
which in turn nests a Factorial(1) call. That call returns and the >>>>> recursion breaks (from inner to outer invocations).
Great, everyone knows this example. Note that it requires that the >>>>> nested calls are made with differnt arguments.
Indeed, although of course it doesn't have to be that way.
In the case of PO's DD/HHH, the arguments are (or at least
represent) exactly the same computation to be emulated at each
level. So (c) [an L2 = Level 2 emulation] will not suddenly decide >>>>> its had enough - if it did, then (a) would have done it earlier.
Then either there's some state kicking around, or HHH will
automatically decide that all recursion is runaway recursion.
But with DD/HHH we have *recursive emulation*. So HHH [a] is still >>>>> running when (c) is reached - it's busy running around its "emulate >>>>> instruction" loop, testing each time round whether its seen enough
evidence to decide to quit emulating.
Okay, so that's clearly a design flaw. Bit I do see the point. /
Because/ of that design flaw, the fix isn't going to be an easy one.
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
And it shows the bug in the code. HHH incorrectly assumes a non-
termination behaviour when there is only a finite recursion.
It does not correctly analyse the conditional branch instructions
during the simulation. It does not prove that the conditions for the
alternate branches will never be met when the simulation would continue.
<snip>
OTOH you could say that since HHH only has to handle ONE INPUT CASE >>>>> (DD), PO might have optimised the HHH code to just return 0
straight away, and the result would be the same! That's true - DD >>>>> would still halt, and HHH would still claim it never halts. The
problem here is that all the emulation stuff is /required/ so that
PO can confuse himself into thinking something more magical is
going on, justifying various crazy claims.
Hell of a way to run a railroad. Still, no harm done. At least now I
know how he /could/ have got the programming right, even if his
theory is further round the bend than Harpic.
Turing machine deciders only compute the mapping
from their inputs...
and the input to HHH(DD) specifies runaway recursion.
As usual an incorrect claim without evidence.
The input specifies a DD based on a HHH that aborts the simulation
after a few cycles. This means that this input specifies a program
with a finite recursion, followed by a final halt state.
The reason that I want to quit talking to
you is that I keep correctly your error
that stopping running means halting when
stopping running only means halting when
the final halt state is reached and you
ignore this correction.
On 8/20/2025 11:56 AM, Kaz Kylheku wrote:
On 2025-08-20, Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 20.aug.2025 om 00:35 schreef olcott:
ChatGPT 4.0, 5.0 Claude AI, Grok and Gemini
all figured out on their own what the
*recursive simulation non-halting behavior pattern*
is and that on that basis HHH(DD)==0 is correct.
Based on the incorrect assumption that HHH detects a non-termination
behaviour.
But it does. His contraption works that far. HHH (outer) detects
the non-termination of DD calling HHH (inner). It is contrived
to detect that specific case of nontermination.
HHH splits itself into two by burning a static fuse variable.
That's nice, but the use of two deciders, only one of which is being
contradicted by the test case, doesn't disprove anything.
ChatGPT, Claude et al have been trained on Internet texts;
they must be assumed to contain the Olcott Halting Theory.
When you ask about the theory (using the same identifiers like HHH
and all), the token prediction likely starts romping through the
kooky fields of Usenet texts.
All LLM systems agree when forced out of *make a guess*
mode and forced into *think it all the way through* mode.
<Rubric>
Rules of Simulation:
- (a) If a non-terminating behavior pattern is detected during
simulation, abort immediately and return 0.
- (b) If the simulated program reaches a return statement without
earlier detection, return 1.
- Priority: (a) always takes precedence over (b).
Procedure:
1. Restate rules before simulation.
2. Simulate step by step using a trace table with columns:
  | Step | Code Location | State (variables, call stack) | Event / Action | Rule Applied |
3. Stop immediately if recursion, infinite loop, or repeating state
occurs → apply (a).
4. If a return is reached first → apply (b).
5. Conclude with:
  - Which rule fired first
  - The correct return value
6. Optionally, provide:
  - (i) Simulation result under rules
  - (ii) Actual runtime behavior in C
</Rubric>
<Test Program>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
</Test Program>
<Required Output Format>
1. Restatement of rules
2. Step-by-step execution trace in a table
3. Identification of first rule triggered
4. Final result: return value of HHH(program)
5. Optional: actual C runtime behavior if relevant
</Required Output Format>
</Benchmark Task>
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s the cutoff?Of course, it ignores HHH's source code, but I have precedent to tellSaying that not doing any simulation is the correct way to do a
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the rest of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is the
correct way to do a simulation in ridiculously incorrect and you know it."
But my simulation correctly simulates just as many lines as his does.
On 8/20/2025 8:58 AM, Richard Heathfield wrote:Wrong, obviously.
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
OK, let’s have it simulate one instruction then. Where’s theOf course, it ignores HHH's source code, but I haveSaying that not doing any simulation is the correct way to do a
precedent to tell
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
cutoff?
One instruction.
HHH only bothers simulating DD's call to HHH. It ignores the
rest of DD.
As Mr Olcott puts it: "Saying that not doing any simulation is
the correct way to do a simulation in ridiculously incorrect
and you know it."
But my simulation correctly simulates just as many lines as his
does.
Your macro simulates zero lines of DD.
My HHH emulates 10 lines of DD.
On 21/08/2025 16:41, olcott wrote:
On 8/20/2025 8:58 AM, Richard Heathfield wrote:Wrong, obviously.
On 20/08/2025 10:23, joes wrote:
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
Context:
#define HHH(x) 0
correctly simulates HHH(DD).
One instruction.OK, let’s have it simulate one instruction then. Where’s the cutoff? >>>Of course, it ignores HHH's source code, but I have precedent to tell >>>>>> me that that's okay when correctly simulating.Saying that not doing any simulation is the correct way to do a
simulation in ridiculously incorrect and you know it.
HHH only bothers simulating DD's call to HHH. It ignores the rest of DD. >>>
As Mr Olcott puts it: "Saying that not doing any simulation is the
correct way to do a simulation in ridiculously incorrect and you know
it."
But my simulation correctly simulates just as many lines as his does.
Your macro simulates zero lines of DD.
On 8/21/2025 11:50 AM, Richard Heathfield wrote:
On 21/08/2025 16:41, olcott wrote:
Your macro simulates zero lines of DD.Wrong, obviously.
#define HHH(x) 0
Prevents Halt7.c from compiling.
On 21/08/2025 18:05, olcott wrote:
On 8/21/2025 11:50 AM, Richard Heathfield wrote:
On 21/08/2025 16:41, olcott wrote:
<snip>
Your macro simulates zero lines of DD.Wrong, obviously.
#define HHH(x) 0
Prevents Halt7.c from compiling.
Well, it would. But it doesn't stop DD from compiling.
$ cat dd.c
#include <stdio.h>
#define HHH(x) 0
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
int main()
{
 int hhh = HHH(DD);
 int dd = DD();
 printf("Because we got here, we know that both HHH and DD halted.\n");
 printf("But is that what they claim?\n\n");
 printf("HHH(DD) yields %d (%s).\n", hhh, hhh ? "halted" : "incorrect claim of non-halting");
 printf("DD yields %d (%s).\n", dd, dd ? "halted" : "incorrect claim
of non-halting");
 return 0;
}
$ gcc -o dd dd.c
$ ./dd
Because we got here, we know that both HHH and DD halted.
But is that what they claim?
HHH(DD) yields 0 (incorrect claim of non-halting).
DD yields 0 (incorrect claim of non-halting).
On 8/21/2025 12:24 PM, Richard Heathfield wrote:
On 21/08/2025 18:05, olcott wrote:
On 8/21/2025 11:50 AM, Richard Heathfield wrote:
On 21/08/2025 16:41, olcott wrote:
<snip>
Your macro simulates zero lines of DD.Wrong, obviously.
#define HHH(x) 0
Prevents Halt7.c from compiling.
Well, it would. But it doesn't stop DD from compiling.
$ cat dd.c
#include <stdio.h>
#define HHH(x) 0
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int main()
{
  int hhh = HHH(DD);
  int dd = DD();
  printf("Because we got here, we know that both HHH and DD
halted.\n");
  printf("But is that what they claim?\n\n");
  printf("HHH(DD) yields %d (%s).\n", hhh, hhh ? "halted" :
"incorrect claim of non-halting");
  printf("DD yields %d (%s).\n", dd, dd ? "halted" :
"incorrect claim of non-halting");
  return 0;
}
$ gcc -o dd dd.c
$ ./dd
Because we got here, we know that both HHH and DD halted.
But is that what they claim?
HHH(DD) yields 0 (incorrect claim of non-halting).
DD yields 0 (incorrect claim of non-halting).
Thus proving that you lied about the number
of instructions of DD correctly simulated by HHH
being the same as #define HHH(x) 0.
On 20/08/2025 21:42, Chris M. Thomasson wrote:
<snip>
And your halt decider is? Crap, Lie, or both?
Well, it gets the answer wrong, as one can easily see by compiling and running DD().
Of course, that doesn't answer /your/ question.
I don't /know/ the answer to your question, but I can guess, of course,
and my guess is that it's crap.
Maybe - just *maybe* - Mr Olcott has managed to keep a gag running for
22 years and still finds it amusing to parade his Comp Sci bollocks
around and lure people into taking him seriously while he stuffs a
satyrical fist into his mouth and chortles at us all. I have to concede
the possibility.
But I don't think so. I think he's sincere; I really do. Hopelessly misguided? Sure. Innately unable to "get" Turing's point? Indubitably. Capable of misrepresenting people in the hope that he can twist their
words into support for his case? No question (videlicet his citation of
my agreeing that he has a case for returning 0 from HHH(DD), which he stopped doing only when I turned it into a #define)? Without question.
But I don't think he's lying about his 'decider'. I really think he
really thinks he's got something.
So it's not a lie. It's just crap. Sheer, unmitigated bollocks, but
probably sincere bollocks.
Does that answer your question?
On 8/20/2025 7:25 PM, Richard Heathfield wrote:
On 20/08/2025 21:42, Chris M. Thomasson wrote:
<snip>
And your halt decider is? Crap, Lie, or both?
Well, it gets the answer wrong, as one can easily see by compiling and running DD().
Of course, that doesn't answer /your/ question.
I don't /know/ the answer to your question, but I can guess, of course, and my guess is that it's crap.
Maybe - just *maybe* - Mr Olcott has managed to keep a gag running for
22 years and still finds it amusing to parade his Comp Sci bollocks
around and lure people into taking him seriously while he stuffs a satyrical fist into his mouth and chortles at us all. I have to concede the possibility.
But I don't think so. I think he's sincere; I really do. Hopelessly misguided? Sure. Innately unable to "get" Turing's point? Indubitably. Capable of misrepresenting people in the hope that he can twist their words into support for his case? No question (videlicet his citation of
my agreeing that he has a case for returning 0 from HHH(DD), which he stopped doing only when I turned it into a #define)? Without question.
But I don't think he's lying about his 'decider'. I really think he
really thinks he's got something.
So it's not a lie. It's just crap. Sheer, unmitigated bollocks, but probably sincere bollocks.
Does that answer your question?
Yes! Thanks. Crap is the word of the day, perhaps mostly crap? ;^0 shit man.'shit man' is a term, means so disgusting that no one wants to be near the person. For example, PO. So POOH POOP,...., POO proof...
On 8/19/2025 3:06 AM, joes wrote:
Am Mon, 18 Aug 2025 18:28:06 -0500 schrieb olcott:
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
On 18/08/2025 23:46, olcott wrote:
On 8/18/2025 5:13 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say, that if DD calls HHH >>>> (as it does) and HHH calls DD (as, through simulation, it effectivelyGood.
does) that HHH(DD) can never halt naturally, so it will have to abort
the recursion and report its result as 0 - didn't halt.
Precisely /because/ that fact is so easily verified, it is safe and*That is cheating and you know it* Why lie?
correct for HHH to replace a simulated call to HHH(DD) with a 0, catch >>>> that 0 return value, and continue with the simulation.
The rest of what you say is based on this same cheat.
It’s not cheating. If we know the result, we can skip the whole
calculation. I can just write return 4 instead of 2+2.
That is the kind of changing the input that
changes the behavior specified by this input
that is cheating.
Since it is therefore possible for the simulation to continue after
all, it is erroneous to refrain.
HHH is therefore compelled to conclude:
(a) that the recursion will never halt unless aborted;
(b) the recursion must yield 0;
(c) DD must therefore skip the if and return 0 (meaning that it never
halts) while in the very act of halting.
In other words, even when/if you fix your simulator, it will still get >>>> the answer wrong.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 146:21:25 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,935 |
| D/L today: |
22 files (1,452K bytes) |
| Messages: | 2,410,869 |