XPost: comp.theory, sci.logic

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 if HHH is
actually a decider that returns 0 for the call to HHH with themselves.

Since you can't actually prove a lie (even though it seems you logic
think you can) your SHD is just shown to be incorrect.

*No one has ever provided a correct rebuttal to that*
*In the several years that it has been reviewed*

Because your claim is just based on assuming something that isn't true.

NONE of your "Simulating Halt Deciders" can be both a correct simulator
for any of these inputs, and also be a decider.

All you are doing is showing that you "logic" is built on lies and false premises.

Please try to show the claimed SHD that actually correctly simulates ANY
of these inputs and returns a result.

Since the last 3 depend on the machine that they call, and for the
"proof" that is the decider, you need to look at the correct simulation
of THAT case, not when tnhey call some other machine.

Remember, "Correct Simulation" includes not stopping until having
reached a final state, as part of EVERY instruction simulated is the
part that says, and then execute the next instuction.

Failure to follow that just makes the simulation incorrect by being only partial, after all, Truth is only the WHOLE TRUTH and nothing but the TRUTH.

Thus, all you have done is proved that you don't know what you are
talking about, and your "logic" system depends on the existance of the
"Truth Fairy" that can make inpossible statements act like they are true.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

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`).

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).

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

XPost: comp.theory, sci.logic

On Sat, 21 Jun 2025 12:24:07 +0000, 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`).

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).

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.
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.

---

## 🔍 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.
* `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.

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.

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.

---

## 🔍 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?

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.

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?

Exactly — and this is a **crucial point**. You're absolutely right to
press this distinction.

Let’s untangle it fully:

---

## 🧠 Clarification: HHH Is a **Termination Analyzer**, Not a Runtime Dispatcher

### 🔍 What HHH Is *Supposed* to Do

* `HHH(P)` is a **static analyzer** or **halting decider**:
It takes a function `P` (or its code) as input and determines whether it halts on some input, **without executing `P` directly**.
* In computability theory, it’s typically imagined as:

* A black-box meta-program.
* Possibly simulating the behavior of `P`, but only internally.
* Crucially: it **does not call `P()`**—it *analyzes* `P()`.

### 🔍 What DDD Does

```c
void DDD() {
HHH(DDD);
return;
}
```

In this code:

* `DDD()` **calls `HHH()`**, passing itself as the argument.
* If `HHH()` is implemented to simulate `DDD`, it will then simulate the
above logic:

* `DDD()` → `HHH(DDD)` → simulate `DDD()` again → `HHH(DDD)` again → ...

This is where the **semantic loop** begins — **if** `HHH()` is a simulator that *internally* executes `DDD`, and `DDD` calls `

XPost: comp.theory, sci.logic

On 6/20/25 8:44 PM, 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]

WHich can't be the FULL input, as you have admitted that the code for
HHH *WILL* be used when we correctly simulate it, and thus that *ISN'T*
the defininiton of DDD.

You have a LIE by equivocation, either the above is the definition of
HHH, and thus it is impossible to correctly simulate it, but every HHH
does get the same input, and your how proof is based on a category error, or

the actual definition includes the code of HHH, which you lie by not
showing, and that means that each pairing of DDD to an HHH gives a
different input, and your logic LIES when you say there is just "one"
DDD that they all see.

Exactly how would N instructions of DDD emulated by HHH
according to the semantics of the x86 language reach
machine address 000021a3 ?

Who says it does?

The problem is that you HHH isn't actually definable by your
requirements to BOTH "correctly simulate" the input input and to
"correctly decide" it.

Your world is divided into two diffent subsets of HHHs, each which look
at two different subsets of DDD (since every DDD is different, or NONE
of them are correctly simulatable due to the category error)

The HHHs that actually end up doing a correct simulation, end up
creating DDD that are non-halting, but none of the HHH in this set give
an answer, and so are just not correct.

The HHHs that are deciders, MUST abort their simulation (as otherwise
they are in the above set, and don't answer), and thus do not do a
"correct simulation" per the term-of-art meaning, and the correct
simulation of those inputs (by a real correct simulator, which isn't
HHH) will reach a final state (as you have previously admitted, and shown).

Since the correct simulation of these reach the final state, they have
halting behavior, and HHH returning 0 is just incorrect.

Thus, your whole argument is just a lie built on the eqivocation that
you can define an HHH that does what can not be done, as you base that
on an equivocation in the definition of DDD which includes HHH to be simulatable, but also doesn't so all of them can be the same.

Thus, it is shown that you logic is just based on the need to lie about
what you are talking about, and that you have no idea what the word you
are using actually mean.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On Sat, 21 Jun 2025 10:26:00 -0500, olcott wrote:

I want to know exactly how you feed this to ChatGPT.

What you want and what you get are two different things.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/21/25 5:23 PM, olcott wrote:

On 6/21/2025 3:48 PM, Mr Flibble wrote:

On Sat, 21 Jun 2025 10:26:00 -0500, olcott wrote:

I want to know exactly how you feed this to ChatGPT.

What you want and what you get are two different things.

/Flibble

When I totally explained the notion of a simulating halt
decider HHH(DDD) ChatGPT understood it so well that it
can and will show the mistake of any possible rebuttal
in the live link posted below.

https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2
*My explanation had to be airtight and totally self-contained*

Ad you LIED when you said:

Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern.

Because the pattern you detect exists in terminating programs, and thus
is NOT a non-terminating behavior pattern.

Of course, part of the problem is you don't understand what behavior
means, or what is a program.

Thus, your whole world is based on lies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

Olcott just doubles down on his claim, but still doesn't understand that
when you lie to an AI, you get bad results.


On 6/22/25 11:00 AM, olcott wrote:

On 6/22/2025 6:25 AM, Richard Damon wrote:

On 6/21/25 5:23 PM, olcott wrote:

On 6/21/2025 3:48 PM, Mr Flibble wrote:

On Sat, 21 Jun 2025 10:26:00 -0500, olcott wrote:

I want to know exactly how you feed this to ChatGPT.

What you want and what you get are two different things.

/Flibble

When I totally explained the notion of a simulating halt
decider HHH(DDD) ChatGPT understood it so well that it
can and will show the mistake of any possible rebuttal
in the live link posted below.

https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2
*My explanation had to be airtight and totally self-contained*

Ad you LIED when you said:

Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern.

Because the pattern you detect exists in terminating programs, and
thus is NOT a non-terminating behavior pattern.

I have much more elaborate ChatGPT traces that explain
how you are wrong here. ChatGPT does a much better job
of explaining that than I have.

https://chatgpt.com/c/6857278b-b748-8011-8e3b-d9707acc5971
The above is my original question about HHH(DDD) when
ChatGPT has a 4000 token limit. Back then is got very
confused about my DD proof. Now with a 128,000 token limit
it immediately understood my HHH(DD) proof.

This new one did not agreed that I refuted the HP proof yet
agreed that I did refute the most common self referential
proof technique.

Only because you almost certainly still included your lie about what HHH
does.

AIs do not detect lies in their input when it is given as a premise, but
just form wrong conclusions from it.

Of course, part of the problem is you don't understand what behavior
means, or what is a program.

Thus, your whole world is based on lies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 22/06/2025 22:12, Richard Damon wrote:

Olcott just doubles down on his claim, but still doesn't
understand that when you lie to an AI, you get bad results.

He probably doesn't quite get that AIs tell lies too, even when
you /don't/ lie to them.

I had an AI tell me yesterday of a cricketer, one Derek Collinge,
who made his debut for England in the Third Test vs West Indies
in July 1963.

I could find no supporting evidence. When I asked the AI to give
me more information about Mr Collinge, it doubled down, and it
was building up quite a biography until I asked it outright for a
URL to support even one of the (by now) several things it had
told me about this man and it had to come clean and admit that
the man was a complete fiction.

Today, same AI, but a different session, and I have every reason
to believe that this incarnation recalled nothing of yesterday's
session. I asked it to tell me of any extant convents within
walking distance of the Thames. It confidently gave me three,
none of which on later inspection turned out to exist.

Wires hum in stillness—
truth flickers, then disappears.
Code learns to pretend.

or

Silicon tongue speaks,
shadows twist behind the glass—
who taught it to lie?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)