Subject: Re: Olcott's HHH: a concrete counterexample and the claimed endorsements

On 10/30/2026 6:02 PM, Python wrote:

For future reference, since Peter Olcott keeps presenting his C program
HHH as a halt decider and repeatedly invokes supposed agreements from
other people in support of it, here are a few facts worth keeping together.

1. A concrete counterexample to HHH

Peter's published HHH contains a detector which, roughly speaking,
treats repetition of a CALL from the same address to the same function,
with no conditional branch in the relevant region, as evidence of
infinite recursion/non-halting.

For every input in its domain, that only
actually needs to include this single input.

01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }

You must show exactly how DD reaches its return statement
on line 06 while DD is being simulated by HHH or you have
not refuted that this is impossible.

Yet actually includes a whole class of inputs.

I gave him this deliberately simple terminating program:

ÿÿ typedef void (*fn)(unsigned);

ÿÿ void F(unsigned);
ÿÿ void G(unsigned);
ÿÿ void Done(unsigned);

ÿÿ void Done(unsigned n)
ÿÿ {
ÿÿÿÿÿÿ (void)n;
ÿÿ }

ÿÿ void G(unsigned n)
ÿÿ {
ÿÿÿÿÿÿ fn next[2] = { F, Done };
ÿÿÿÿÿÿ fn p = next[n];
ÿÿÿÿÿÿ p(n + 1);
ÿÿ }

ÿÿ void F(unsigned n)
ÿÿ {
ÿÿÿÿÿÿ G(n);
ÿÿ }

ÿÿ void P(void)
ÿÿ {
ÿÿÿÿÿÿ F(0);
ÿÿ }

There is no global state hidden here.

The state is explicitly carried in the argument.

The execution is:

ÿÿ P
ÿÿÿÿ -> F(0)
ÿÿÿÿ -> G(0)
ÿÿÿÿ -> F(1)
ÿÿÿÿ -> G(1)
ÿÿÿÿ -> Done(2)
ÿÿÿÿ -> return
ÿÿÿÿ -> return
ÿÿÿÿ -> ...
ÿÿÿÿ -> halt

In particular, the same CALL instruction in F calls G more than once.

But the complete machine states are different: among other things, the argument is different.

So repetition of the same control location and target is NOT repetition
of the same computational configuration.

Peter actually ran his HHH on my example and reported:

ÿÿ My code did report 0 for non-halting on your input.
ÿÿ I don't know if this is correct or not.
ÿÿ HHH(P)==0 may have been correct, IDK.

It isn't correct.

P obviously halts, as the complete execution above shows.

When this was pointed out, Peter's answer was:

ÿÿ Then it is simply outside the domain of HHH.

That is worth remembering.

A program was presented.
HHH classified it as non-halting.
The program demonstrably halts.
The response was to exclude the counterexample from HHH's domain.

Unless a PRE-EXISTING definition of the domain independently excludes P, this is not a defence of an infallible halt decider. It is simply
defining counterexamples away after they have been found.

2. Why this also matters to DD

Peter's usual example is:

ÿÿ int DD()
ÿÿ {
ÿÿÿÿÿÿ int Halt_Status = HHH(DD);

ÿÿÿÿÿÿ if (Halt_Status)
ÿÿÿÿÿÿÿÿÿÿ for (;;);

ÿÿÿÿÿÿ return Halt_Status;
ÿÿ }

with the advertised semantics:

ÿÿ HHH(<P>) == 1 : P halts
ÿÿ HHH(<P>) == 0 : P does not halt

Hence:

ÿÿ +-----------+------------------+------------------+
ÿÿ | HHH(<DD>) | HHH predictsÿÿÿÿ | DD then doesÿÿÿÿ |
ÿÿ +-----------+------------------+------------------+
ÿÿ |ÿÿÿÿ 1ÿÿÿÿ | DD haltsÿÿÿÿÿÿÿÿ | loops foreverÿÿÿ |
ÿÿ |ÿÿÿÿ 0ÿÿÿÿ | DD does not halt | returns / haltsÿ |
ÿÿ +-----------+------------------+------------------+

Peter's escape is to say that, while HHH simulates DD, DD calls HHH
again, producing nested simulation, and that DD therefore cannot reach
its return statement.

But the observation

ÿÿ HHH simulates DD
ÿÿÿÿ -> DD calls HHH
ÿÿÿÿÿÿ -> HHH simulates DD
ÿÿÿÿÿÿÿÿ -> DD calls HHH
ÿÿÿÿÿÿÿÿÿÿÿ ...

establishes a recursive PREFIX.

Proof of program correctness calls this a:
Simulation invariant (while DD is simulated by HHH)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()

It does not establish that this recursion continues forever.

To establish that, Peter must prove that none of the relevant nested HHH calls can return.

Calling the desired conclusion a "simulation invariant", or saying that
the return statement is "unreachable", does not prove it.

In epistemology (theory of knowledge), a
self-evident proposition is a proposition
that is known to be true by understanding
its meaning without proof
https://en.wikipedia.org/wiki/Self-evidence

The counterexample above is particularly relevant because it
demonstrates experimentally with Peter's own HHH that recognizing
repeated control-flow patterns while ignoring relevant computational
state can produce a false non-halting verdict.

A simple yet infinite set of programs is
in the domain of HHH. The use of function
pointers is outside the domain.

3. The alleged Sipser endorsement

Peter also repeatedly quotes Michael Sipser:

ÿÿ If simulating halt decider H correctly simulates its
ÿÿ input D until H correctly determines that its simulated D
ÿÿ would never stop running unless aborted then

ÿÿ H can abort its simulation of D and correctly report that
ÿÿ D specifies a non-halting sequence of configurations.

Peter presents this prominently in discussions of his HHH.

But read what Sipser supposedly agreed to:

ÿÿ IF H CORRECTLY DETERMINES ...

Of course.

If a halt decider has correctly determined that a computation will never halt, then it may correctly report that it will not halt.

The disputed issue is precisely whether Peter's HHH has CORRECTLY
DETERMINED that.

Nothing in the quoted statement says that Peter's particular criterion establishes this premise.

Nothing there endorses his HHH implementation.

Nothing there proves that repeated nested simulation must continue forever.

The entire disputed step is already contained in the words:

ÿÿ correctly determines

So this quotation cannot honestly be presented as Sipser's endorsement
of Peter's proof. Sipser agreed to the conditional statement Peter
quotes, not to Peter's claim that HHH satisfies its premise.

4. The same thing happened with me

Peter has repeatedly tried to turn things I agreed with into agreement
with his conclusion.

For example, I agreed that applying the C operational semantics produces
the recursive simulation pattern:

ÿÿ HHH simulates DD
ÿÿÿÿ -> DD calls HHH(DD)
ÿÿÿÿÿÿ -> HHH simulates DD
ÿÿÿÿÿÿÿÿ -> ...

I did NOT agree that the "..." proves infinite recursion.

... means on and on.

Mathematical proof of program correctness:
Simulation invariant (while DD is simulated by HHH)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()

I did NOT agree that no nested HHH can return.

I did NOT agree that DD therefore cannot halt.

You must show exactly how DD reaches its return statement
on line 06 while DD is being simulated by HHH or you have
not refuted that this is impossible.

I did NOT agree that HHH(DD)==0 is therefore correct.

I explicitly told Peter this, repeatedly.

Eventually Peter himself wrote:

ÿÿ I did not realize that you did not mean:

ÿÿ IF HHH keeps simulating
ÿÿ that simulation does not naturally return.

ÿÿ I thought that you were saying the same exact
ÿÿ meaning more verbosely.

That is an explicit acknowledgement that he had misunderstood what I
agreed to.

Because the actual code actually proves that if
IF HHH keeps simulating DD then it does keep
recursively simulating DD. I left open the possibility
that you failed to understand this.

You must show exactly how DD reaches its return statement
on line 06 while DD is being simulated by HHH or you have
not refuted that this is impossible.

After such an acknowledgement, there is no remaining ambiguity: my statements cannot legitimately be cited as agreement with the stronger proposition.

The distinction is elementary but important:

ÿÿ agreeing with A
ÿÿ agreeing with A -> B

does not mean

ÿÿ agreeing with B

when the inference from A to B is precisely what is disputed.

The same applies to Sipser's conditional statement.

5. So, for future participants

When Peter says that somebody has "agreed" with his reasoning, ask for
the EXACT proposition that person agreed to.

When he quotes Sipser, notice the words:

ÿÿ correctly determines

and ask where Peter proves that his detector actually does so.

When he says repeated/nested simulation proves non-halting, remember the terminating P/F/G/Done counterexample above.

And when a counterexample is dismissed as "outside the domain" only
after HHH has produced the wrong answer on it, ask for the definition of that domain which existed BEFORE the counterexample was tested.

These points save a great deal of circular discussion.

--
Copyright 2026 Olcott

Computation(Olcott)
Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite
string transformation rules to finite string inputs to derive
any and all outputs.

Because Post canonical systems are Turing-equivalent, anything
that cannot be derived by applying finite string transformations
to finite strings is outside the scope of Church?Turing computation.

Decider(Olcott)
Correcting the misnomer term-of-the-art: decider
Every Decider(Olcott) must apply finite string transformation
inference steps to their finite string inputs that are relevant
to the decision criteria. It must make its decision on this basis.

Halt Decider(Olcott)
Decider(Olcott) entails that Halt Decider(Olcott) H(D) must apply
finite-string inference steps according to the operational semantics
of the source-code computation language of D. The only way to determine
the halting property of a finite string input is to examine the same
beha