XPost: comp.theory, sci.logic

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.

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

XPost: comp.theory, sci.logic

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

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

### 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 be

XPost: comp.theory, sci.logic

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.

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

XPost: comp.theory, sci.logic

On 6/13/25 2:17 PM, olcott wrote:

On 6/13/2025 12:15 PM, Richard Damon wrote:

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.

embedded_H is not allowed to report on the behavior
of the computation that itself is contained within.

Says what?

I guess you are just showing off that you are just a liar.

The input to embedded_H cannot possibly reach its
own SIMULATED final halt state: ⟨Ĥ.qn⟩, thus the
input to embedded_H SPECIFIES a non-halting sequence
of configurations.

Sure it can, just not by the partial simulation that embedded_H does,
but does under the correct and complete simulation of a matching UTM
that accepts the same representation definition.

All you are doing is proving that you don't know the meaning of the
words you are using, and intentially twisting them to try to make your
point.

I(n other words, you are just showing that you "logic system" is based
on LYING.

HHH can not base its answer on the correct simulation BY HHH, if HHH
does not do one, and if it does, then as you have shown, the different
input generated by that DIFFERENT HHH would not halt, and that HHH will
never answer.

SInce your claim, that the HHH that answers is based on the correct
simulation done by that HHH, is based on a false statement, since any
HHH that aborts to return an answer doesn't do a correct simulation, you
are just proven to be a liar.

Sorry, that *IS* what you are showing the world, that your idea of logic
is just based on lies, and thus no better than, and even worse then, the
people you claim to be trying to refute about things like Global Warming.

By destroying your reputation, and then putting yourself into a "good
cause" you taint that cause, and are just a vehicle of evil.

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