On 6/21/2025 7:24 AM, Mr Flibble wrote:
On Fri, 20 Jun 2025 19:44:50 -0500, olcott wrote:
On 6/20/2025 7:01 PM, Richard Damon wrote:
On 6/20/25 3:08 PM, olcott wrote:
void Infinite_Recursion()
{
Infinite_Recursion(); return;
}
>
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
>
void DDD()
{
HHH(DDD);
return;
}
>
int Sipser_D()
{
if (HHH(Sipser_D) == 1)
return 0;
return 1;
}
>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
>
My claim is that each of the above functions correctly simulated by
any termination analyzer HHH that can possibly exist will never stop
running unless aborted by HHH.
>
The problem is that NO "Simulating Halt Decider" HHH, can correctly
simulte ANY of those inputs.
>
For the first two, it is possible for a smart enough Simulation Halt
Decider to determine that the correct simulation of the input will not
halt, no matter what HHH actually does, since it doesn't depend on the
decider.
>
For the last 3, it can not prove that they will not halt, as, in fact,
>
the correct simulation of all those inputs *WILL* halt
>
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 [0000219a] e833f4ffff call
000015d2 // call HHH [0000219f] 83c404 add esp,+04 [000021a2]
5d pop ebp [000021a3] c3 ret Size in
bytes:(0018) [000021a3]
>
Exactly how would N instructions of DDD emulated by HHH according to the
semantics of the x86 language reach machine address 000021a3 ?
This exchange between **Peter Olcott** and **Richard Damon** is a clash
over the semantics of simulation, halting behavior, and what it means to
*correctly analyze* a self-referential or looping function using a
theoretical "termination analyzer" (`HHH`).
HHH emulates N x86 machine language instructions of
DDD according to the semantics of the x86 language,
thus necessarily emulates these N instructions correctly.
This also requires HHH to emulate itself emulating DDD
at least once.
The main computer science definition of halting is
reaching a final halt state, anyone disagreeing is
incorrect. An alternative definition that is easier
for programmers to understand is never stop running.
Any disagreement with this is incorrect.
When there are no N instructions of DDD correctly
simulated by HHH that can possibly reach their final
halt state then it is a verified fact that the input to
HHH(DDD) specifies a non-halting sequence of
configurations.
Let’s break this down across three layers: **technical validity**,
**semantic precision**, and **communication clarity**.
---
## 🔍 1. **Olcott's Argument**
Olcott gives a series of functions that are meant to illustrate programs
that either:
* Loop infinitely in a trivially detectable way (`Infinite_Loop`,
`Infinite_Recursion`), or
* Engage in **self-referential calls to the analyzer** (`HHH`) to simulate
undecidable or paradoxical behavior (`DDD`, `Sipser_D`, `DD`).
He claims:
Any HHH that correctly simulates these programs will never stop running
unless it *aborts* the simulation, because these programs themselves never
halt (or have undecidable behavior).
That is incorrect. My actual claim is that these
inputs to HHH specify non halting behavior. The
directly executed DDD() is the caller of HHH(DDD)
thus not its input.
Then he posts **x86 machine code** for `DDD()` and asks:
How could a simulator (HHH) ever emulate this code to the final `ret`
instruction at address `000021a3`, given the semantics?
---
### ✅ Valid Point (in Narrow Scope)
Olcott is **correct** in a narrow sense:
If you define "correct simulation" as **faithfully executing each
instruction step-by-step**, then **simulating an infinite loop** or a
recursive self-reference will indeed run forever.
It is not any narrow sense.
Thus, **any system that halts** to declare "this never halts" *must not be
simulating it fully*, but analyzing it another way.
This point is **semantically sound**, **but trivially true**. And it's
already well-acknowledged in computability theory.
*This is not true*
The input to HHH1(DDD) halts and the input to HHH(DDD)
does not halt because these inputs specify a different
sequence of steps.
Because DDD calls HHH(DDD) this sequence includes HHH
emulating itself emulating DDD.
Because DDD does not call HHH1 then HHH1 never emulates
itself emulating DDD.
*ChatGPT Analyzes Simulating Termination Analyzer*
https://www.researchgate.net/publication/385090708_ChatGPT_Analyzes_Simulating_Termination_Analyzer At the end of this paper is a link to a live ChatGPT
session that understands how and why I am correct about
HHH(DDD). When people try to point out any mistake in
this work ChatGPT explains (in its own words) how and
why they are wrong.
---
## 🔍 2. **Damon’s Response**
Damon replies:
The last three examples (e.g., `DDD`, `Sipser_D`, `DD`) **do halt** in
practice.
Therefore, any simulation that models their behavior *correctly* would
**eventually halt**.
This is a **concrete rebuttal** of Olcott’s claim that they *must* never
halt unless the simulation is aborted.
Damon is pointing out that:
* `DDD()` halts *if* `HHH(DDD)` halts.
*No it is merely a counter-factual statement*
When we use the correct computer science definition of
halting of *reaching a final halt state*, then we know
that the input to HHH(DDD) specifies a non-halting
sequence of configurations because it cannot possibly
reach its own simulated final state. *This is a verified fact*
Most all of the rebuttals of my work are disagreements
with verified facts. Other fake rebuttals try to get
away with changing the words that I said and rebutting
these changed words. I wasted 15 years by Ben Bacarisse
using the change-the-subject fake rebuttal.
* `Sipser_D()` is a **paradox** only if you assume a perfect `HHH()`, but
can still be **evaluated statically** as malformed or contradictory.
* These aren't actual infinite loops *by structure*—only under certain
assumptions.
Alternatively we can say that Sipser_D() returns
the correct value of its own halt status.
int main()
{
Output("Input_Halts = ", Sipser_D());
}
So Damon is **distinguishing** between:
* **Syntactic infinite loops** (clearly analyzable), and
* **Self-referential constructs** (which may or may not halt, depending on
semantics of the decider).
### ✅ Correct Core Argument
Damon is right that **not all of Olcott’s examples are non-halting
programs**. Some only appear to loop if `HHH` is assumed to behave a certain way, but
otherwise *can terminate* if `HHH` does.
Each input to HHH specifies a sequence of configurations
(AKA state changes) that cannot possibly reach their own
final halt state.
Where Damon falls short:
* He doesn’t fully explain **why** these programs halt.
* He assumes familiarity with **meta-level reasoning**, which Olcott
either misapplies or doesn’t accept.
Richard is simply wrong.
---
## 🔍 3. **Olcott’s Follow-up: Machine Code Challenge**
Olcott then pastes x86 disassembly of `DDD()`, ending in a `ret`, and says:
How can HHH ever simulate this code and reach the final `ret`
instruction if the function is recursive?
Not a precisely accurate paraphrase of this:
Exactly how would N instructions of DDD emulated by HHH
according to the semantics of the x86 language reach
machine address 000021a3 ?
> But here's the issue:
* **The code as shown doesn’t actually recurse**—it **calls `HHH(DDD)`**
and returns.
It does *not* call `DDD()` recursively.
* So it *will reach* the `ret` if `HHH(DDD)` halts.
*Counter-factual*
No call to HHH(DDD) from a correctly emulated DDD ever
returns whether or not HHH(DDD) halts.
So this code is **not equivalent** to an infinite recursion or infinite
loop. It depends **entirely** on the behavior of `HHH`.
Thus Olcott's code **undercuts his own claim**.
---
## 🧠 Final Technical Summary
| Point |
Olcott |
Damon | Verdict |
| --------------------------------------- |
----------------------------------------------- |
---------------------------- | ----------------- |
| Simulating an infinite loop never halts | ✅
True | ✅
Agrees | ✅ Both correct |
| Self-referential programs never halt | ❌ Incorrect
generalization | ✅ Correctly challenges it | ✅
Damon |
| `DDD()` and `Sipser_D()` never halt | ❌
Incorrect | ✅ They halt *if* `HHH`
halts | ✅ Damon |
| `HHH` can't simulate `DDD()` to `ret` | ❌ Incorrect (code reaches
`ret` if `HHH` halts) | – | ✅ Damon (implied)
|
| Halting behavior = simulation halting | ❌ Incorrect
conflation | ✅ Distinguishes the two | ✅
Damon |
---
## 🎭 Rhetorical & Communication Notes
* **Olcott** fixates on a surface-level observation (simulations of loops
don’t terminate) and applies it **too broadly**, failing to distinguish
between *actual infinite loops* and *self-referential logic constructs*.
* **Damon**, while technically correct, is terse and fails to unpack the
nuance for Olcott—likely due to fatigue or exasperation.
---
## ✅ Conclusion
* Damon is **technically and semantically correct**: some of Olcott’s
examples do halt under certain conditions, so they do not support the
claim that any correct simulation must loop forever.
* Olcott continues to **conflate simulation with analysis** and **assumes
self-reference equals infinite behavior**, which is not true in general.
* The x86 disassembly example undermines Olcott’s own claim—`DDD()` as
written will reach `ret` unless `HHH(DDD)` loops forever, in which case
simulation stalls not because of `DDD`, but because of the behavior of
`HHH`.
Would you like a formal summary to insert into that thread? Or perhaps a
response that makes this contradiction in Olcott’s x86 example crystal
clear?
I want to know exactly how you feed this to ChatGPT.
I never had ChatGPT analyze a preexisting dialog.
-- Copyright 2025 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
How do simulating termination analyzers work? (V2)
Re: How do simulating termination analyzers work? (V2)