XPost: comp.theory, sci.logic
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.
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.
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.
Sure there is, as what does the OPPOSITE, it the program, and the
input is only a representation of that program.
You don't seem to understand that "inputs" are just representations,
and what has the behavior is the thing they represent.
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 am not the damned liar here, you are. YOU ALWAYS CHEAT !!!
If I was, you could point out the actual error in what I say.
Note, how I always point out the details of your error, describing the
meaning of the words that I am using from the accepted Term-of-art
meanings.
But you never do that, you can only use terms in sloppy context with
twisted meanings, and no source that could back you up.
Sorry, all you are doing is proving my point, and showing the whole
world that you are just the damned liar.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)