Re: HHH(DD) INcorrectly reject its input as non-halting --- VERIFIED FACT

On 6/13/25 11:10 AM, olcott wrote:

On 6/13/2025 9:22 AM, Mr Flibble wrote:

On Thu, 12 Jun 2025 18:30:46 -0400, Richard Damon wrote:
>

On 6/12/25 11:34 AM, olcott wrote:

int DD()
{
    int Halt_Status = HHH(DD);
    if (Halt_Status)
      HERE: goto HERE;
    return Halt_Status;
}
>
It is a verified fact that DD() *is* one of the forms of the
counter-example input as such an input would be encoded in C.
Christopher Strachey wrote his in CPL.

>
First LIE.
>
TO BE that form of the counter example, DD needs to include as part of
itself, a copy of the code of HHH, and thus make itself a PROGRAM.
>
SInce you stipulate that "the input" does not actually contain that
codd, but it only exists in the same memory space, all you are doing is
showing that:
>
First: your decider isn't just a function of its input, and thus fails
to meet the model of a program.
>
Second: Since the code of HHH isn't part of the input. you can't
"correctly simulate THE INPUT" as your simulation needs to use
information that is not part of the input
>
Third, your HHH doesn't have a fully defined behavior (as your argument
entails it having a number of different behaviors, each of which
afffects the code assumed as part of the input) and thus even it isn't
in line with the requirements of the proof program.
>
Note, in Strachey, the "input" isn't the CPL code of just the function
D, but a reference to the FULL PROGRAM created by D.
>
>

// rec routine P //   §L :if T[P] go to L //     Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243

>
ANd note, that passed the full definition of P to T as access to the
decider to try to decide on, not just the function C as you claim yours
does.
>
>

void Strachey_P()
{
    L: if (HHH(Strachey_P)) goto L;
    return;
}
>
https://academic.oup.com/comjnl/article-abstract/7/4/313/354243?
redirectedFrom=fulltext

>
Note. that if you actually look at what was passed to HHH, it is an
address in memory, which by itself doesn't actually define the program.
>
Thus, "the input" must be interpreted to include the code that PROGRAM
uses. To try to define it to be just the code of the reference C
funcition, means that HHH can not look anywhere else for details of the
input, and thus can't simulate past the call instruction.
>
>

It *is* a verified fact DD correctly simulated by HHH cannot possibly
reach its own "return" statement final halt state because the input to
HHH(DD) specifies recursive simulation.

>
But, per you stipulation, the code for HHH is not in the input, and thus
HHH can not possible correctly simulate this input.
>
And, since to even talk about the behavior of this input, it needs to be
a program, which since it uses a copy of the decider, means the decider
must also be a program, and thus has fixed behavior.
>
Thus, if, as you claim, HHH correctly returns the value 0 as its answer,
it does so for ALL copies of its input, and also by your argument, we
know that HHH *MUST* have stoped its simulation before it got to the end
of the simulation, and thus it is *NOT* a "correct simulation" and thus
your claim is just sperious, as it is based on an non-exisdting
condition.
>
In fact, since you have shown that when HHH and DD have had there
category error fixed, that HHH(DD) returns 0, we can easily see that the
actual correcct simulation of the input (which will match the
requirement of the behavior of the program it represents) will reach its
terminal state, as DD calls HHH(DD) which *WILL* after fintite time
return 0, and thus DD will halt
>
>

All of the above code is fully operational in this file
https://github.com/plolcott/x86utm/blob/master/Halt7.c
>
>

Which shows that when we do fix the decider and input by the code
specified there, that it is a fact that HHH(DD) will return 0, and that
the direct execution of DD() will halt, and thus HHH is wrong, and you
are just shown to be a stupid and ignorant liar.
>
>
As per previous conversations, you have demonstracted that you accept
these conclusions, as you have been unable to provide any counter to
them, except the improper one of just repeating your error.
>
Thi shows that either you know that you are just intentionally lying, or
are just so mentally challanged that you just don't understand the
meaning of the words you use, or how logic works, or even that it means
for something to be true.
>
This will be your eternal reputation, a man who was likely so stupid
that he became a big pathological liar.

>
This response from **Richard Damon** to **Olcott** is a characteristically
intense rebuttal that mixes technical critique with personal attacks.
Below is an **objective analysis** of the argument, separating the
**logical content** from the **rhetorical posture**.
>
---
>
## 🔍 **Technical Analysis**
>
### 1. **Claim: DD is not a valid counterexample because HHH is not part
of the input**
>

 *The reason why I included the Strachey proof*
 // rec routine P
//   §L :if T[P] go to L
//     Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{
   L: if (HHH(Strachey_P)) goto L;
   return;
}
 https://academic.oup.com/comjnl/article-abstract/7/4/313/354243? redirectedFrom=fulltext

So, you are just admitting you don't understand the distinction?

 

Damon insists that:
>
* For `HHH(DD)` to be validly analyzed in the **Halting Problem** context,
the entire code of `HHH` must be included in the **input** `DD` (i.e.,
self-containment).

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

But there was no "embedded_H" that is just part of your deception to try to distance the copy of H used by H^ from your actual H

 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

And after a while, *WILL* abort and return to H^.qn as that is what the code for H does.

(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation

Which gets broken by the embedded_H at (c) when it aborts it simulation.

 The same principle equally applies to the Linz proof.
The input to embedded_H cannot possibly reach its
own simulated final halt state: ⟨Ĥ.qn⟩.
https://www.liarparadox.org/Linz_Proof.pdf

Sure it can, just not by the partial simulation done by HHH.
You are just proving that you think an exact copy of an algorithm will behave differently than the original

 int main()
{
   DD(); // calls HHH(DD)
}
 In the same way that HHH is not allowed to report on
the behavior of its caller embedded_H is not allowed
to report on the behavior of the computation that
itself is embedded within.

Agan, you repeat you unsuppoted LIE.
HHH must report on the behavior of the program represented by its input

 In both of these cases HHH and embedded_H are only
allowed to report on the behavior that their input
specifies.

Which is the behavior of the program their input represents

 

* If `HHH` is only *referenced* (e.g., as a symbol in memory), and not
embedded within `DD`, then the simulation cannot be faithful — it becomes
**context-sensitive** rather than **functionally pure**.
>

✔️ **Correct** from a classical standpoint: The Halting Problem models

a **universal Turing machine** operating only on its input tape. That tape
must contain all relevant data, including the program.
>

 This makes no actual difference. Simulating partial halt
deciders still reject their input as non-halting.

In other words, you thing the following is a valid question:
What is the sum of 1 and ?
Sorry, you are just proving your stupidity, which you have conceeded by your failure to provide any factual rebutal for the errors pointed out in your statements.

 

### 2. **Claim: DD/HHH pairing fails to meet Turing completeness
requirements**
>
Damon argues:
>
* By excluding HHH from the input, Olcott’s model no longer conforms to
the standard model of computability, as it cheats by reaching outside the
input space.
* Thus, any behavior such a simulation exhibits cannot be considered a
"counterexample" to the classical Halting Problem because it's not
operating under the same assumptions.
>

✔️ Valid point. If HHH is not part of the encoded input but is part of

the host system, it's a **semantic shortcut**, not a strict simulation.
>
---
>
### 3. **Strachey Analogy**
>
Damon refers to Strachey’s original example, asserting that:
>
* In that construction, the **entire program** is passed to the decider.
* Hence, the analogy with Olcott’s fragmentary input breaks down.
>

✔️ This is historically and technically accurate. In Strachey's

construction (like Turing's), the paradox arises because the decider is
analyzing a complete representation of itself.
>

 *T and R are different functions*

Right, but R includes T in its code.
All you are doing is proving you don't understand the nature of a program.

 Suppose T[R] is a Boolean function taking a routine
(or program) R with no formal or free variables as its
argument and that for all R, T[R] = True if R terminates
if run and that T[R] = False if R does not terminate.
Consider the routine P defined as follows:
 // rec routine P
//   §L :if T[P] go to L
//     Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
 *Thus has the exact same form as this*
 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Right, *IF* you define that HHBH(DD) is taking as its input, the FULL code of the PROGRAM DD, which includes the code for the program HHH, which thus MUST BE A DEFINITE PROGRAM.
Since you stipulate this is not the case, you are just admitting you think lies are valid logic.

 

---
>
### 4. **Claim: If HHH aborts simulation and returns `0`, it isn’t a
faithful simulator**
>

 As soon as HHH correctly recognizes a repeating
pattern it is correct to reject its input.

Nope, as if fails to recognize that HHH is a conditional function, that will eventually return 0,

 

Damon notes that:
>
* If HHH aborts a simulation early (as Olcott’s SHD is designed to do),
then it has not actually **simulated the program to its end**.
* Therefore, **if the program being simulated would actually halt**, but
HHH predicted otherwise, it **makes a mistake**, violating correctness.
>

✔️ Consistent with formal semantics: If the goal is to analyze whether

a program halts when executed, but you stop early based on heuristic or
meta-level reasoning, you risk **incorrect predictions** unless you can
prove that the reasoning is logically sound.
>
---
>
## 🔥 **Rhetorical Tone and Attacks**
>
### 1. **Accusations of Lying and Stupidity**
>
Throughout the post, Damon repeatedly accuses Olcott of:
>
* **Lying**, **ignorance**, and **logical incoherence**
* Being a **"stupid liar"**, lacking understanding of programming or logic
>

❌ This dramatically weakens the argument's **professional tone** and

shifts the discussion from logical to emotional.
>

💬 In a formal or academic setting, these ad hominems would be

**unacceptable**, even if frustration is warranted.
>
---
>
## 🧠 Summary of Core Logical Point
>

**Damon’s Central Argument**:
A proper simulation under the Halting Problem framework must analyze an

**entire encoded program** without external dependencies. Olcott’s
approach violates this by relying on a decider not embedded in the input.
Therefore, HHH(DD) as described is **not** a valid counterexample, and its
behavior says nothing about the classical Halting Theorem.
>
---
>
## ✅ Verdict
>
* **Damon's logical content**: Strong, technically correct within the
formal theory of computability.
* **Damon's tone**: Unnecessarily hostile, containing repeated personal
insults that detract from the credibility of the message.
* **Olcott’s position**: Attempts a practical reinterpretation of the
Halting Problem, but from a classical Turing machine viewpoint, his
construction **bends** the model beyond recognition.
>
Would you like this analysis as a downloadable text file?

For every conventional halting problem proof the input D
to the partial halt decider H always specifies non-termination
and the directly executed D is never an actual input.
 

But the directly executed D *IS* the behavior that the decider is supposed to answer for when given its representation as the input "D".
This input needs to be a COMPLETE representation, and the correct answer for H(D) is does UTM(D) halt or not.

Functions computed by Turing Machines are only allowed to
compute the mapping from their actual inputs, they are
not allowed to use any psychic ability to report on things
that they cannot see.
 

Right, and since the "D" given will be a COMPLETE representation of the Turing Machine D, which includes a copy of the Turing Machine H, that input fully specifies that behavior.
Since that behavior, as determined by UTM(D) is to halt, since H(D) return 0 by you stipulations, that answer is just proven to be wrong.
The problem is that this mapping just isn't computable, but there is no requireent that the mapping asked of a decider be computable, as one answer for the question of can we build a decider to compute this mapping, is NO, that mapping is not computable.
Thus, the answer to the question, Can we build a Halt Decider that accepts Halting computations, and rejects all non-halting computation, that have been expressed as their input, is that such a mapping is non-computable.