XPost: comp.theory, sci.logic

On 6/14/25 10:30 AM, olcott wrote:

On 6/14/2025 8:27 AM, Richard Damon wrote:

On 6/13/25 11:53 PM, olcott wrote:

On 6/13/2025 9:11 PM, Richard Damon wrote:

On 6/13/25 8:25 PM, olcott wrote:

On 6/13/2025 6:34 PM, Richard Damon wrote:

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.

You already know what and lie about it.

Really? so you can't point it out.

See,

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.

*See that you cheat again. You ALWAYS cheat*
*See that you cheat again. You ALWAYS cheat*
*See that you cheat again. You ALWAYS cheat*

What is the "cheat"? I am just quoting the actual definitions of the
terms.

Do you have a real source for something different, or is this just
your normal baseless claim?

embedded_H cannot take its actual self as input,
thus no TM *INPUT* *INPUT* *INPUT* *INPUT* *INPUT*
can actually do the opposite of whatever the TM
partial halt decider decides.

But it can take its representation. SOmething you don't seem to
understand.

I understand it far better than you.
The input would encode a sequence of moves (changes in configuration).
that specifies the behavior of DD simulated by HHH.

No, the input encodes the ALGORITHM of the program. If the program
takes an input, then it can not encode the steps it will take, as
those are different for each input.

 From the representation, we can compute the sequence of
configurations the program will go through, but the input does not
some how list them.

After all, how does your x86 assembly code encode the "moves"/
cofiguration of the program, it only shows the instructions that build
the algorithm of the program.

The term "move" is from Linz and means one single state change
and one single tape action. At the x86 level it means one single
state change, AKA the execution or simulation of one single x86
instruction.

Right, and the input doesn't encode the "moves" but the algorithm that
creates those moves.

To "encode the sequence of moves" would be to encode the OUTPUT of a
simulator, not provide the INPUT to the simulator.

To be the proper input for a halt decider, it needs to specify what
the program will actually do when run, and allow the recreation of
that behavior.

No this is wrong. No partial halt decider ever has any
psychic ability to see the behavior of its caller.

And you are showing that you mind just doesn't understand the question.

ANY real partial simulator will be able to see the partial behavior of
its caller if given as its input the proper reperesentation of the
caller (which will include the representation of itself).

Why do you think that to be so hard?

Every partial halt decider is only accountable for the
behavior specified by its input and never accountable
for the behavior of its caller.

But since they can be the same, this shows your statement to be self-conttadictory.

That you fail to understand this is entirely your failure.

That you repeat your lies shows your stupidity.

I guess you just don't understand the halting question, because you
don't understand objective truth, and have to convert things into a
subjective truth to fit your world view.

*Key verified facts such that disagreement is inherently incorrect*

(a) HHH(DDD) does not correctly report on the behavior of its caller.

And when that caller is DDD, that shows that HHH is just wrong.

(b) Within the theory of computation HHH is not allowed to report
on the behavior of its caller.

Wrong, it can't be asked about "its caller" as such, as there is no way
to specify that pronoun, but it CAN be asked to reprot about the
behavior of a speccified program that just happens to be its caller.

(c) HHH(DDD) does correctly report on the behavior that its
input specifies.

No it doesn't, as (when we fix DDD to be a program) the behavior
specified by its input, which is the representation of the Program DDD
is actually evaluated by running it, it halts, but HHH(DDD) report
non-halting.

(d) It is also required that one know that in computer science
halting means reaching a final halt state.

Right, OF A PROGRAM. Partial simulation do not demonstatrate a property
of either halting or non-halting.


So, your "Verified Facts", are just shows to be more of your lies, and
any future mention of you use of "verified facts" that hasn't been
previously established by answer by showing an actual error with these refuations, with supporting material from reliable source, will hence
forth just be labeld as actually refering to your verified DELIBERATE LIES.

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