On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't understand what
"prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
and you have been known to have a less than
scrupulous regard for the truth. Your notion that you have "proven" some
incorrectness is nothing more than a spurious delusion of grandeur.
Yet every attempt to find any actual mistake has failed.
You cannot point to even one single mistake that I
have made in the gist of what I have been saying.
*The definition of the halting problem is provably incorrect*
Garbage. It is perfectly OK.
I have proven its key mistake.
I only did this very recently.
Below we have one half of this
proof of its mistake.
Despicable lying scumbag bastards snip my proof.
Do you really think that for such a simple
problem, known and understood by millions over nearly a century, any flaw
would not have already been found long ago? You are intellectually not
up to the task; a typical student will understand the halting problem and
its resolution in at most a few hours. You have spent 20 years and still
haven't got it.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from
conflating the behavior of encoded simulations with direct execution,
and from making assumptions about a decider's domain that do not hold
under a rigorous model of computation.
Your problem is you don't understand the meaning of the words you are
using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly
snipping the substance of Richard's post, where he illustrated some of
the words whose meaning PO fails to understand.
Do you really think that for such a simple problem, known and
understood by millions over nearly a century, any flaw would
not have already been found long ago?
Do you really think that for such a simple problem, known and
understood by millions over nearly a century, any flaw would
not have already been found long ago?
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem ProofYour problem is you don't understand the meaning of the words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the >>>>> conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically, >>>>> we show that the contradiction used in the proof arises from conflating >>>>> the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a >>>>> rigorous model of computation.
Your problem is you don't understand the meaning of the words you are
using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly
snipping the substance of Richard's post, where he illustrated some of
the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
On 7/20/2025 11:53 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't understand what
"prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
As I said, you don't understand what "prove" means in mathematics. Some
airy-fairy half-baked "philosophical" nonsense just won't cut it here.
I go by any "sound" deductive inference
all mere proofs go by the lesser "valid"
deductive inference where the premises
could be false.
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>> conclusion that the Halting Problem is undecidable, we argue that the >>>>>>> conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically, >>>>>>> we show that the contradiction used in the proof arises from conflating >>>>>>> the behavior of encoded simulations with direct execution, and from >>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>> rigorous model of computation.
Your problem is you don't understand the meaning of the words you are >>>>>> using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly
snipping the substance of Richard's post, where he illustrated some of >>>> the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't understand what
"prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
and you have been known to have a less than
scrupulous regard for the truth. Your notion that you have "proven" some
incorrectness is nothing more than a spurious delusion of grandeur.
Yet every attempt to find any actual mistake has failed.
You cannot point to even one single mistake that I
have made in the gist of what I have been saying.
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
Your problem is you don't understand the meaning of the words you are
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
[ .... ]
Your problem is you don't understand the meaning of the words you are >>>>>> using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
What you call "verified facts" are generally nothing of the kind. They
are merely things, often false, you would like to be true.
*One key example of a denied verified fact is when Joes said*
On 7/18/2025 3:49 AM, joes wrote:
very obvious that HHH cannot simulate
DDD past the call to HHH.
HHH(DDD) does emulate itself emulating DDD
After I have conclusively proven:
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
You frequently deny verified facts. You "deny" established definitions.
It has been established on this newsgroup that you have lied on it.
That statement is libelous.
No one can even point to a false statement that I made, thus cannot
point to an intentionally false statement that I made.
Feel free to cut-and-paste a time/date stamped quote
of anything that I said that you have construed as false.
Several times it has become apparent that your technical programming
competence leaves a lot to be desired.
I did make one key mistake when referring to
lines-of-code versus statements in C.
Consistent honesty and truthfulness is what I have hoped for from you for
a long time, now. With it, we could have a productive exchange of views.
I doubt we will ever see this, though.
I would love to have this with you. I have initially
assessed that you may be very competent.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
[ .... ]
Your problem is you don't understand the meaning of the words >>>>>>>>> you are using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it
should.
It is also honest and truthful that people that deny verified facts >>>>>> are either liars or lack sufficient technical competence.
What you call "verified facts" are generally nothing of the kind.
They are merely things, often false, you would like to be true.
*One key example of a denied verified fact is when Joes said*
On 7/18/2025 3:49 AM, joes wrote:
very obvious that HHH cannot simulate DDD past the call to HHH.
Joes is quite right, here, as has been said to you many times over by
several people.
HHH(DDD) does emulate itself emulating DDD
You will have a get out clause from the vagueness of your language,
which could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code of DDD pointed to by
P. That is does this according to the semantics of the x86 language
conclusively proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever
HHH might do is far short of sufficient "conclusively to prove" that the emulation is correct. To prove that is likely impossible in principle, that's even assuming you could define "correct" coherently.
This continual hyperbole of yours is one of the things which establishes
your reputation as a liar.
When this emulated DDD calls an emulated HHH(DDD)
all of the code of this emulated DDD is in the same global memory space
of Halt7.obj.
Thus HHH(DDD) does begin emulating itself emulating DDD. It emulates
itself emulating DDD until the emulated emulated DDD calls HHH(DDD)
again.
*This is all proven right here*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because x86UTM is a multi-tasking operating system it enables the
context switch between the emulator and the emulated.
The x86utm operating system function DebugStep()
on line 1638 enables this with its helper functions
SaveState(emu, master_state); // Saves master process state
LoadState(emu, (u32)slave_state); // Changes to slave process state
https://github.com/plolcott/x86utm/blob/master/x86utm.cpp
But it is a lie to say that "HHH(DDD) ... emulating DDD" is a verified
fact. If I am mistaken there, just say who has done the verification,
how, and when.
*The code has always proved this for several years*
Like I said, your saying "verified fact" is a lie. By it, you just mean
that you've written the code, therefore (in your opinion) it must be
correct.
Words mean things, and if you use a common phrase to mean something
different from its usual meaning with intention to deceive, you are
lying. That is what you are doing, here.
After I have conclusively proven:
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
You frequently deny verified facts. You "deny" established
definitions. It has been established on this newsgroup that you have >>>>> lied on it.
That statement is libelous.
It might be libellous if it were false.
That you won't even try to prove that it is true by finding a single
time/date stamped quote of mine with any error in the essence of any of
may claims provides a weight of evidence that I made no mistakes.
I have shown you to be a liar a few paragraphs above, where you have mendaciously used "verified fact". Feel free to look up the time stamp
of this message if you really want it.
No one can even point to a false statement that I made, thus cannot
point to an intentionally false statement that I made.
I just pointed one out where you mendaciously state "One key example
of a ... verified fact is ...", and then citing something which wasn't
a verified fact.
The code has proven it is a verified fact for several years.
Who has verified it, how much were they paid, and who by?
More seriously, you told Ben Bacarisse on this newsgroup that you had
fully worked out turing machines which broke a proof of the Halting
Theorem. It transpired you were lying. When the topic came up again
for discussion, you failed to deny writing the original lie.
That is the closest thing to a lie that I ever said.
When I said this I was actually meaning that I had fully operational C
code that is equivalent to a Turing Machine.
I think it was a full blown lie intended to deceive. Did you ever
apologise to Ben for leading him up the garden path like that?
You have not and never have had "fully operational C code" that breaks a proof of the Halting Theorem. To say you had this, when you clearly
didn't, was a lie.
Feel free to cut-and-paste a time/date stamped quote of anything that
I said that you have construed as false.
I've got better things to do with my time.
If you call me a liar and cannot even point to a mistake that is
libelous.
I've pointed out your whopper to Ben, and your falsely writing about
alleged verified facts.
That's enough justifiably to call you a liar.
Several times it has become apparent that your technical programming >>>>> competence leaves a lot to be desired.
I did make one key mistake when referring to lines-of-code versus
statements in C.
At one time you repeatedly posted the source code of a C function with
a syntax error in it, despite being repeatedly advised of this, and
even what the error was.
Yes I did make these kind of mistakes that do not pertain to the
essence of my claim:
They point to a certain lack of competence, a certain lack of attention
to detail which is essential to all computer programming.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
The input to HHH(DD) specifies that DD simulated by HHH (according to
the semantics of the C programming language) specifies a non-halting
sequence of configurations.
All rebuttals to this (including Ben's) have been the strawman error of
referring to the behavior of the directly executed DD().
And your lack of care for the truth will not acknowledge that, by
definition, a simulation of a program has the same behaviour as the
original program. Everybody but you appears to know this.
It is common knowledge that directly executed Turing machines are
outside of the domain of Turing machine deciders. This means that no
Turing machine decider can ever directly report on the behavior or any
directly executed Turing machine.
That's vague waffle. A universal turing machine does indeed report on
the behaviour of its input program if so designed. If that input
program is the same as the "directly executed turing machine" (whatever
you might mean by that), the UTM will report on the behaviour of the
latter.
The best that they can do is use a machine description as a proxy for
the behavior of the direct execution.
Your lack of power of abstraction is leading you astray, here.
When HHH(DD) computes the mapping *from its input* to the behavior that
this input specifies it correctly determines that the recursive
simulation that this input specifies is non-halting behavior.
This has been comprehensively dealt with by other posters on this group.
Consistent honesty and truthfulness is what I have hoped for from
you for a long time, now. With it, we could have a productive
exchange of views.
I doubt we will ever see this, though.
I would love to have this with you. I have initially assessed that
you may be very competent.
You may take it that I fully competent in C programming, amongst other
things.
Do you have at least a decade of full time experience at this?
I have nearer 40 years experience than a decade.
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem ProofYour problem is you don't understand the meaning of the words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the >>>>> conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically, >>>>> we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a >>>>> rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
On 7/21/2025 4:19 AM, Mikko wrote:
On 2025-07-20 19:17:59 +0000, olcott said:
On 7/20/2025 11:53 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't understand what >>>>>> "prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
As I said, you don't understand what "prove" means in mathematics. Some >>>> airy-fairy half-baked "philosophical" nonsense just won't cut it here.
I go by any "sound" deductive inference
all mere proofs go by the lesser "valid"
deductive inference where the premises
could be false.
If your "proof" does not satisfy the definition of proof you must
prove that it is valid.
A valid proof is syntactically entailed by its
possibly false premises.
A sound proof is semantically entailed by its
provably true premises.
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem ProofYour problem is you don't understand the meaning of the words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the >>>>> conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically, >>>>> we show that the contradiction used in the proof arises from conflating >>>>> the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a >>>>> rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>> conclusion that the Halting Problem is undecidable, we argue that the >>>>>>> conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically, >>>>>>> we show that the contradiction used in the proof arises from conflating >>>>>>> the behavior of encoded simulations with direct execution, and from >>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>> rigorous model of computation.
Your problem is you don't understand the meaning of the words you are >>>>>> using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly
snipping the substance of Richard's post, where he illustrated some of >>>> the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
That you think a definition is incorrect does not change the defined
meaning. If you don't accept the definition the best you can do is
that you don't use the term.
That I prove that a definition is derived from provably
false assumptions proves that this definition is incorrect.
No one here is capable of paying enough attention to my
proof that the halting problem definition is incorrect
because my proof requires two steps and no one here can
even pay attention to one step.
On 7/21/2025 9:20 PM, Richard Damon wrote:
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>Your problem is you don't understand the meaning of the words you are >>>>>> using.
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>> conclusion that the Halting Problem is undecidable, we argue that >>>>>>> the
conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from >>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>> rigorous model of computation.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)
returns 0.
When I say that DDD simulated by HHH does not
halt you dishonestly change the subject.
On 20/07/2025 17:13, Alan Mackenzie wrote:
Do you really think that for such a simple problem, known and
understood by millions over nearly a century, any flaw would
not have already been found long ago?
You're right, of course, but the above argument is not as robust
as we might hope.
"The number of human chromosomes was published by Painter in
1923. By inspection through a microscope, he counted 24 pairs of
chromosomes, giving 48 in total. His error was copied by others,
and it was not until 1956 that the true number (46) was
determined by Indonesian-born cytogeneticist Joe Hin Tjio."
And oscillating reactions were known to be impossible for quite a
while even after crank Belousov came up with one.
And of course there's another problem:
Do you really think that for such a simple problem, known and
understood by millions over nearly a century, any flaw would
not have already been found long ago?
Yes. That's /precisely/ what he really thinks. And he always
will, no matter what we tell him.
--
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
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
[ .... ]
Your problem is you don't understand the meaning of the words you are >>>>>>>>> using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
What you call "verified facts" are generally nothing of the kind. They >>>>> are merely things, often false, you would like to be true.
*One key example of a denied verified fact is when Joes said*
On 7/18/2025 3:49 AM, joes wrote:
very obvious that HHH cannot simulate
DDD past the call to HHH.
Joes is quite right, here, as has been said to you many times over by
several people.
HHH(DDD) does emulate itself emulating DDD
You will have a get out clause from the vagueness of your language, which >>> could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH might do is far short of sufficient "conclusively to prove" that the emulation is correct. To prove that is likely impossible in principle, that's even assuming you could define "correct" coherently.
On 7/22/2025 5:28 AM, Mikko wrote:
A proof is not sound if it is not valid.
Yes and the conclusion has not been shown to be
true unless it is valid and its premises are true.
Premises of a sound proof need not be provably true. It is sufficient
that they are true.
How do we know that the premises are true?
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
*One key example of a denied verified fact is when Joes said*
On 7/18/2025 3:49 AM, joes wrote:
very obvious that HHH cannot simulate DDD past the call to HHH.
HHH(DDD) does emulate itself emulating DDD After I have conclusively
proven:
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH
might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
[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]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Exactly how is it that you could have construed this
as impossible in principle?
--
Copyright 2024 Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient
technical compoetence unless a judge accepts your proof of your claims.
With defamation of character cases when one person
lies about another person as much as all of their
personal property can be taken away. Defamation of
character is not a crime it is a tort.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
Whatever HHH
might do is far short of sufficient "conclusively to prove" that the emulation is correct.
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
You will have a get out clause from the vagueness of your language, which >>>> could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH
might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
[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]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Exactly how is it that you could have construed this
as impossible in principle?
--
Copyright 2024 Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott <NoOne@nowhere.com> wrote:language, which
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
[ .... ]
You will have a get out clause from the vagueness of your
Whatever HHHcould be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie.
might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
That conclusively proves that it works in this particular case.[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]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Which appears to be beside the point.
Exactly how is it that you could have construed this
as impossible in principle?
You seem to be "proving" the correctness of your emulation by giving one example of its execution and saying "because it works for this particular case,
it works in general".We can always correctly determine that this run
It is as though you are testing a multiplication program and give it the inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly. Actually, what you were testing turned out to be an addition program.
You can never prove a program is correct just by getting correct results from a single run of it,
or even correct results from several or manyI never claimed that we are proving that HHH is an
runs. This is impossible in principle.
And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.
Which appears to be beside the point.
olcott <NoOne@nowhere.com> wrote:
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
[ .... ]
You will have a get out clause from the vagueness of your language, which >>>>> could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH >>> might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
[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]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Which appears to be beside the point.
Exactly how is it that you could have construed this
as impossible in principle?
You seem to be "proving" the correctness of your emulation by giving one example of its execution and saying "because it works for this particular case, it works in general".
It is as though you are testing a multiplication program and give it the inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly. Actually, what you were testing turned out to be an addition program.
You can never prove a program is correct just by getting correct results
from a single run of it, or even correct results from several or many
runs. This is impossible in principle. And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.
--
Copyright 2024 Olcott
2024???
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott <NoOne@nowhere.com> wrote:
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH >>> might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
[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]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Which appears to be beside the point.
Exactly how is it that you could have construed this
as impossible in principle?
You seem to be "proving" the correctness of your emulation by giving one example of its execution and saying "because it works for this particular case, it works in general".
It is as though you are testing a multiplication program and give it the inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly. Actually, what you were testing turned out to be an addition program.
You can never prove a program is correct just by getting correct results
from a single run of it,
or even correct results from several or many
runs. This is impossible in principle.
And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.
Which appears to be beside the point.
--
Copyright 2024 Olcott
2024???
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>Your problem is you don't understand the meaning of the words you are >>>>>> using.
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>> conclusion that the Halting Problem is undecidable, we argue that the >>>>>>> conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically, >>>>>>> we show that the contradiction used in the proof arises from conflating >>>>>>> the behavior of encoded simulations with direct execution, and from >>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>> rigorous model of computation.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient
technical compoetence unless a judge accepts your proof of your claims.
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
On 7/22/2025 5:28 AM, Mikko wrote:
On 2025-07-21 14:01:43 +0000, olcott said:
On 7/21/2025 4:19 AM, Mikko wrote:
On 2025-07-20 19:17:59 +0000, olcott said:
On 7/20/2025 11:53 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:I go by any "sound" deductive inference
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't understand what >>>>>>>> "prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
As I said, you don't understand what "prove" means in mathematics. Some >>>>>> airy-fairy half-baked "philosophical" nonsense just won't cut it here. >>>>>
all mere proofs go by the lesser "valid"
deductive inference where the premises
could be false.
If your "proof" does not satisfy the definition of proof you must
prove that it is valid.
A valid proof is syntactically entailed by its
possibly false premises.
A sound proof is semantically entailed by its
provably true premises.
A proof is not sound if it is not valid.
Yes and the conclusion has not been shown to be
true unless it is valid and its premises are true.
Premises of a sound proof need not be provably true. It is sufficient
that they are true.
How do we know that the premises are true?
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>> conclusion that the Halting Problem is undecidable, we argue that the >>>>>>>>> conventional proof fails to establish this conclusion due to a >>>>>>>>> fundamental misapplication of Turing machine semantics. Specifically, >>>>>>>>> we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from >>>>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>>>> rigorous model of computation.
Your problem is you don't understand the meaning of the words you are >>>>>>>> using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly
snipping the substance of Richard's post, where he illustrated some of >>>>>> the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
That you think a definition is incorrect does not change the defined
meaning. If you don't accept the definition the best you can do is
that you don't use the term.
That I prove that a definition is derived from provably
false assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are derived
does not matter. It is a category error to say that a defintion is
incorrect.
*Yes this is a strange and rare case*
When the halting problem proof requires reporting on
the behavior of a directly executing machine and no
Turing machine based halt decider can take another
directly executing Turing machine as an input then
this is an error.
On 7/22/2025 9:35 AM, joes wrote:
Am Mon, 21 Jul 2025 08:33:07 -0500 schrieb olcott:
On 7/21/2025 3:09 AM, Richard Heathfield wrote:...past the call to itself. Don't lie.
On 20/07/2025 17:13, Alan Mackenzie wrote:
Do you really think that for such a simple problem, known and
understood by millions over nearly a century, any flaw would not have >>>>> already been found long ago?
Yes. That's /precisely/ what he really thinks. And he always will, no
matter what we tell him.
Joes tries to keep getting away with saying that HHH cannot possibly
simulate itself simulating DDD.
Simulating itself simulating DDD is simulating
past the first call to HHH(DDD) in the original DDD.
That you do not understand the meaning of my words
is not me lying.
On 7/22/2025 9:35 AM, joes wrote:
Am Mon, 21 Jul 2025 08:57:04 -0500 schrieb olcott:
On 7/21/2025 4:10 AM, Mikko wrote:Definitions are, by definition, correct, although maybe not useful.
That you think a definition is incorrect does not change the definedThat I prove that a definition is derived from provably false
meaning. If you don't accept the definition the best you can do is that >>>> you don't use the term.
assumptions proves that this definition is incorrect.
No one here is capable of paying enough attention to my proof that theWhat's the second step?
halting problem definition is incorrect because my proof requires two
steps and no one here can even pay attention to one step.
*This right here is a type mismatch error*Which is computable from the code/description/specification/whatever.
The simplest step is that no Turing machine decider ever takes another
directly executing Turing machine as its input yet the halting problem
requires a halt decider to report on the behavior of the directly
executed machine.
This would not be an issue if the correct simulation of a Turing machine >>> description always had the exact same behavior as the directly executed
machine.
If HHH indeed simulated itself correctly, which is impossible.
That is not impossible when each simulation instance
has its own separate process context that has their
own set of 16 virtual registers and their own private
virtual stack kept in distinct memory locations.
I had to write x86utm as a multi-tasking operating
system to accomplish this. Without operating system
level functions to SaveState() and LoadState() to
enable context switching this would be impossible.
Everyone here sees that the behavior is not the same and rules that theThe direct execution is wrong?
simulation is wrong because it differs from the behavior of the direct
execution.
*That is an incorrect measure of correct simulation*
Turing machine based halt deciders are accountable
for reporting on the behavior that their finite
string input specifies. They never have been accountable
for the behavior of the directly executed machine.
This is a nuance that all of the textbooks get wrong.
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>Your problem is you don't understand the meaning of the words you are >>>>>> using.
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>> conclusion that the Halting Problem is undecidable, we argue that >>>>>>> the
conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from
conflating
the behavior of encoded simulations with direct execution, and from >>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>> rigorous model of computation.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient
technical compoetence unless a judge accepts your proof of your claims.
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
void DDD()
{
HHH(DDD);
return;
}
When anyone says that DDD correctly simulated by
HHH reaches its own "return" statement final halt
state if we just wait long enough this is either
a lie or a lack of sufficient technical competence.
On 7/23/2025 2:54 AM, Mikko wrote:
On 2025-07-22 13:22:59 +0000, olcott said:
On 7/22/2025 5:28 AM, Mikko wrote:
On 2025-07-21 14:01:43 +0000, olcott said:
On 7/21/2025 4:19 AM, Mikko wrote:
On 2025-07-20 19:17:59 +0000, olcott said:
On 7/20/2025 11:53 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't
understand what
"prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
As I said, you don't understand what "prove" means in
mathematics. Some
airy-fairy half-baked "philosophical" nonsense just won't cut it >>>>>>>> here.
I go by any "sound" deductive inference
all mere proofs go by the lesser "valid"
deductive inference where the premises
could be false.
If your "proof" does not satisfy the definition of proof you must
prove that it is valid.
A valid proof is syntactically entailed by its
possibly false premises.
A sound proof is semantically entailed by its
provably true premises.
A proof is not sound if it is not valid.
Yes and the conclusion has not been shown to be
true unless it is valid and its premises are true.
Premises of a sound proof need not be provably true. It is sufficient
that they are true.
How do we know that the premises are true?
If we don't we can't know whether the proof is sound. Maybe it is,
maybe not.
Sometimes we may know the truth from own observation.
The definition of the semantic meaning of words
and the behavior of finite strings of code proves
that they are true.
void Infinite_Recursion()
{
Infinite_Recursion();
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
The above are non-terminating.
Anyone that disagrees is objectively incorrect.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem >>>>>>>>>>> Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>> of the
undecidability of the Halting Problem. While we do not
dispute the
conclusion that the Halting Problem is undecidable, we argue >>>>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>>>> conflating
the behavior of encoded simulations with direct execution, >>>>>>>>>>> and from
making assumptions about a decider's domain that do not hold >>>>>>>>>>> under a
rigorous model of computation.
Your problem is you don't understand the meaning of the words >>>>>>>>>> you are
using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly >>>>>>>> snipping the substance of Richard's post, where he illustrated >>>>>>>> some of
the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
That you think a definition is incorrect does not change the defined >>>>>> meaning. If you don't accept the definition the best you can do is >>>>>> that you don't use the term.
That I prove that a definition is derived from provably
false assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are derived
does not matter. It is a category error to say that a defintion is
incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
That you do not understand this is counter-factual
does not make it factual.
When the halting problem proof requires reporting on
the behavior of a directly executing machine and no
Turing machine based halt decider can take another
directly executing Turing machine as an input then
this is an error.
No, it is not an error. The problem clarly states that the input
is a description of the Turing machine and input asked about. A
description is of the correct category.
Yes that part is correct.
The part that is incorrect is that no Turing Machine
decider reports on the behavior of machine M on input i.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Instead they report on the behavior that finite string ⟨M⟩
specifies. I have simplified my proofs where my program
under test has no parameters. See DD above.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem >>>>>>>>>>> Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>> of the
undecidability of the Halting Problem. While we do not
dispute the
conclusion that the Halting Problem is undecidable, we argue >>>>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>>>> conflating
the behavior of encoded simulations with direct execution, >>>>>>>>>>> and from
making assumptions about a decider's domain that do not hold >>>>>>>>>>> under a
rigorous model of computation.
Your problem is you don't understand the meaning of the words >>>>>>>>>> you are
using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly >>>>>>>> snipping the substance of Richard's post, where he illustrated >>>>>>>> some of
the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
That you think a definition is incorrect does not change the defined >>>>>> meaning. If you don't accept the definition the best you can do is >>>>>> that you don't use the term.
That I prove that a definition is derived from provably
false assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are derived
does not matter. It is a category error to say that a defintion is
incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
That you do not understand this is counter-factual
does not make it factual.
When the halting problem proof requires reporting on
the behavior of a directly executing machine and no
Turing machine based halt decider can take another
directly executing Turing machine as an input then
this is an error.
No, it is not an error. The problem clarly states that the input
is a description of the Turing machine and input asked about. A
description is of the correct category.
Yes that part is correct.
The part that is incorrect is that no Turing Machine
decider reports on the behavior of machine M on input i.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Instead they report on the behavior that finite string ⟨M⟩
specifies. I have simplified my proofs where my program
under test has no parameters. See DD above.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>>>> conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>> fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from >>>>>>>>>>> making assumptions about a decider's domain that do not hold under a
rigorous model of computation.
Your problem is you don't understand the meaning of the words you are
using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly >>>>>>>> snipping the substance of Richard's post, where he illustrated some of >>>>>>>> the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
That you think a definition is incorrect does not change the defined >>>>>> meaning. If you don't accept the definition the best you can do is >>>>>> that you don't use the term.
That I prove that a definition is derived from provably
false assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are derived
does not matter. It is a category error to say that a defintion is
incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
That you do not understand this is counter-factual
does not make it factual.
When the halting problem proof requires reporting on
the behavior of a directly executing machine and no
Turing machine based halt decider can take another
directly executing Turing machine as an input then
this is an error.
No, it is not an error. The problem clarly states that the input
is a description of the Turing machine and input asked about. A
description is of the correct category.
Yes that part is correct.
The part that is incorrect is that no Turing Machine
decider reports on the behavior of machine M on input i.
On 7/23/2025 2:54 AM, Mikko wrote:
On 2025-07-22 13:22:59 +0000, olcott said:
On 7/22/2025 5:28 AM, Mikko wrote:
On 2025-07-21 14:01:43 +0000, olcott said:
On 7/21/2025 4:19 AM, Mikko wrote:
On 2025-07-20 19:17:59 +0000, olcott said:
On 7/20/2025 11:53 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:I go by any "sound" deductive inference
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't understand what
"prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
As I said, you don't understand what "prove" means in mathematics. Some
airy-fairy half-baked "philosophical" nonsense just won't cut it here. >>>>>>>
all mere proofs go by the lesser "valid"
deductive inference where the premises
could be false.
If your "proof" does not satisfy the definition of proof you must
prove that it is valid.
A valid proof is syntactically entailed by its
possibly false premises.
A sound proof is semantically entailed by its
provably true premises.
A proof is not sound if it is not valid.
Yes and the conclusion has not been shown to be
true unless it is valid and its premises are true.
Premises of a sound proof need not be provably true. It is sufficient
that they are true.
How do we know that the premises are true?
If we don't we can't know whether the proof is sound. Maybe it is,
maybe not.
Sometimes we may know the truth from own observation.
The definition of the semantic meaning of words
and the behavior of finite strings of code proves
that they are true.
On 7/23/2025 2:42 AM, Mikko wrote:
On 2025-07-22 13:50:22 +0000, olcott said:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:I have proven that my claims are self-evidently
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:It is also honest and truthful that people
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>>Your problem is you don't understand the meaning of the words you are >>>>>>>> using.
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>> conclusion that the Halting Problem is undecidable, we argue that the >>>>>>>>> conventional proof fails to establish this conclusion due to a >>>>>>>>> fundamental misapplication of Turing machine semantics. Specifically, >>>>>>>>> we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from >>>>>>>>> making assumptions about a decider's domain that do not hold under a >>>>>>>>> rigorous model of computation.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient >>>> technical compoetence unless a judge accepts your proof of your claims. >>>
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
It is not possible to prove that someting is self-evidently true.
No proof can convinceingly show that someting is self-evident to
those who don't already see it as self-evident.
The definitions of the meaning of the words
make these meanings self-evidently true.
Any valid inference on the basis of these
meanings makes the derived conclusion true.
On 7/23/2025 3:49 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 15:50 schreef olcott:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:It is also honest and truthful that people
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>>Your problem is you don't understand the meaning of the words
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>> conclusion that the Halting Problem is undecidable, we argue >>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>> conflating
the behavior of encoded simulations with direct execution, and >>>>>>>>> from
making assumptions about a decider's domain that do not hold >>>>>>>>> under a
rigorous model of computation.
you are
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient >>>> technical compoetence unless a judge accepts your proof of your claims. >>>>
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
As usual incorrect claims without evidence.
void DDD()
{
HHH(DDD);
return;
}
When anyone says that DDD correctly simulated by
HHH reaches its own "return" statement final halt
state if we just wait long enough this is either
a lie or a lack of sufficient technical competence.
Nobody said such a thing. Suggesting that somebody did, without any
evidence, may be considered as a lie.
We all know that HHH fails to reach the final halt state,
Counter-factual.
The directly executed HHH does reach its final halt state.
DDD correctly simulated by HHH cannot possibly reach its
final halt state no matter what HHH does because it remains
stuck in recursive simulation.
where world class simulators have no problem to reach the final halt
state of exactly the same input.
On 7/23/2025 3:43 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 17:31 schreef olcott:
On 7/22/2025 9:35 AM, joes wrote:
Am Mon, 21 Jul 2025 08:57:04 -0500 schrieb olcott:
On 7/21/2025 4:10 AM, Mikko wrote:Definitions are, by definition, correct, although maybe not useful.
That you think a definition is incorrect does not change the defined >>>>>> meaning. If you don't accept the definition the best you can do is >>>>>> thatThat I prove that a definition is derived from provably false
you don't use the term.
assumptions proves that this definition is incorrect.
No one here is capable of paying enough attention to my proof that the >>>>> halting problem definition is incorrect because my proof requires two >>>>> steps and no one here can even pay attention to one step.What's the second step?
*This right here is a type mismatch error*Which is computable from the code/description/specification/whatever.
The simplest step is that no Turing machine decider ever takes another >>>>> directly executing Turing machine as its input yet the halting problem >>>>> requires a halt decider to report on the behavior of the directly
executed machine.
This would not be an issue if the correct simulation of a Turing
machine
description always had the exact same behavior as the directly
executed
machine.
If HHH indeed simulated itself correctly, which is impossible.
That is not impossible when each simulation instance
has its own separate process context that has their
own set of 16 virtual registers and their own private
virtual stack kept in distinct memory locations.
I had to write x86utm as a multi-tasking operating
system to accomplish this. Without operating system
level functions to SaveState() and LoadState() to
enable context switching this would be impossible.
Everyone here sees that the behavior is not the same and rules thatThe direct execution is wrong?
the
simulation is wrong because it differs from the behavior of the direct >>>>> execution.
*That is an incorrect measure of correct simulation*
Turing machine based halt deciders are accountable
for reporting on the behavior that their finite
string input specifies. They never have been accountable
for the behavior of the directly executed machine.
This is a nuance that all of the textbooks get wrong.
As usual incorrect claims without evidence. No textbook requires such
a thing.
*From the bottom of page 319* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
WM is the machine description of machine M
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.
Linz is requiring the decider embedded within
machine Ĥ to report on the behavior of its own
direct execution.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
The decider must decide on its input. In this case the input specifies
a DDD calling an aborting HHH.
The input specifies that DDD calls HHH(DDD)
in recursive simulation that cannot possibly
reach the simulating final state of DDD.
HHH, as you claim, returns with a value 0 after the abort. This makes
that DDD reaches its final halt state. If HHH cannot simulate that
finite recursion, its simulation fails.
On 7/23/2025 6:14 AM, Richard Damon wrote:
On 7/23/25 12:11 AM, olcott wrote:
On 7/22/2025 9:24 PM, Richard Damon wrote:
On 7/22/25 11:39 AM, olcott wrote:
On 7/22/2025 6:29 AM, Richard Damon wrote:
On 7/21/25 11:46 PM, olcott wrote:
On 7/21/2025 5:56 PM, Richard Damon wrote:
On 7/21/25 5:49 PM, olcott wrote:
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
[ .... ]On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>
Your problem is you don't understand the meaning of >>>>>>>>>>>>>>>>>> the words you are
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common >>>>>>>>>>>>>>>> as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
What you call "verified facts" are generally nothing of >>>>>>>>>>>>>> the kind. They
are merely things, often false, you would like to be true. >>>>>>>>>>
*One key example of a denied verified fact is when Joes said* >>>>>>>>>>
On 7/18/2025 3:49 AM, joes wrote:
very obvious that HHH cannot simulate
DDD past the call to HHH.
Joes is quite right, here, as has been said to you many >>>>>>>>>>>> times over by
several people.
HHH(DDD) does emulate itself emulating DDD
You will have a get out clause from the vagueness of your >>>>>>>>>>>> language, which
could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. >>>>>>>>>> Whatever HHH
might do is far short of sufficient "conclusively to prove" >>>>>>>>>> that the
emulation is correct. To prove that is likely impossible in >>>>>>>>>> principle,
that's even assuming you could define "correct" coherently. >>>>>>>>>>
[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 isn't a program, you need to include the code for HHH.
*Yet again your attention deficit disorder*
I have told you countless times that all of
the machine code for every function is in
the same global memory space of halt7.obj.
Doesn't matter what "is in the memory space", what matters is what >>>>>> is considedred part of the program, and thus part of the input.
Neither HHH nor DDD would ever stop running unless
HHH aborts its emulation of DDD.
But your HHH DOES stop running.
HHH would not stop running unless HHH aborts its
simulation this proves that the input specifies
non-halting behavior.
So? since it does, it does, and thus DDD does.
*This is a truism*
Every input that must have its simulation aborted to
prevent its infinite execution is a non-terminating
input.
Alternatively any input D simulated by termination
analyzer H that cannot possibly reach its own final
halt state no matter what H does specifies non-halting
behavior.
On 7/24/2025 5:03 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 17:29 schreef olcott:
The directly executed HHH does reach its final halt state. DDD
correctly simulated by HHH cannot possibly reach its final halt state
no matter what HHH does because it remains stuck in recursive
simulation.
Indeed, but irrelevant. The simulating HHH does not do a correct
simulation, it aborts prematurely.
_DDD()
[00002192] 55 push ebp [00002193] 8bec mov ebp,esp [00002195] 6892210000 push 00002192 // push DDD [0000219a]
e833f4ffff call 000015d2 // call HHH [0000219f] 83c404 add esp,+04 [000021a2] 5d pop ebp [000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Aborting prematurely literally means that after N instructions of DDD
are correctly emulated by HHH that this emulated DDD would reach its own emulated "ret" instruction final halt state.
What value of N are you proposing?
On 7/24/2025 1:23 AM, Mikko wrote:
On 2025-07-23 12:33:56 +0000, olcott said:
On 7/23/2025 2:54 AM, Mikko wrote:
On 2025-07-22 13:22:59 +0000, olcott said:
On 7/22/2025 5:28 AM, Mikko wrote:
On 2025-07-21 14:01:43 +0000, olcott said:
On 7/21/2025 4:19 AM, Mikko wrote:
On 2025-07-20 19:17:59 +0000, olcott said:
On 7/20/2025 11:53 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't >>>>>>>>>>>> understand what
"prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
As I said, you don't understand what "prove" means in
mathematics. Some
airy-fairy half-baked "philosophical" nonsense just won't cut >>>>>>>>>> it here.
I go by any "sound" deductive inference
all mere proofs go by the lesser "valid"
deductive inference where the premises
could be false.
If your "proof" does not satisfy the definition of proof you must >>>>>>>> prove that it is valid.
A valid proof is syntactically entailed by its
possibly false premises.
A sound proof is semantically entailed by its
provably true premises.
A proof is not sound if it is not valid.
Yes and the conclusion has not been shown to be
true unless it is valid and its premises are true.
Premises of a sound proof need not be provably true. It is sufficient >>>>>> that they are true.
How do we know that the premises are true?
If we don't we can't know whether the proof is sound. Maybe it is,
maybe not.
Sometimes we may know the truth from own observation.
The definition of the semantic meaning of words
and the behavior of finite strings of code proves
that they are true.
Strings don't have any behaviour.
*This string does specify its behavior*
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
Definitions and semantic meanings rarely prove anything. In most cases
something other than meanings and definitions need be known in order
to determine truth.
That is never the case within the entire body of
analytic truth. All of math, logic and computer
science is only analytic truth.
All analytic truth flows from the stipulated
definitions of the semantic meanings of finite strings.
2 + 3 = 5 only on the basis of the definition of
the set of natural numbers.
On 7/24/2025 6:23 AM, Richard Damon wrote:
On 7/23/25 1:44 PM, olcott wrote:
On 7/23/2025 3:43 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 17:31 schreef olcott:
On 7/22/2025 9:35 AM, joes wrote:
Am Mon, 21 Jul 2025 08:57:04 -0500 schrieb olcott:
On 7/21/2025 4:10 AM, Mikko wrote:Definitions are, by definition, correct, although maybe not useful. >>>>>>
That you think a definition is incorrect does not change theThat I prove that a definition is derived from provably false
defined
meaning. If you don't accept the definition the best you can do >>>>>>>> is that
you don't use the term.
assumptions proves that this definition is incorrect.
No one here is capable of paying enough attention to my proofWhat's the second step?
that the
halting problem definition is incorrect because my proof requires >>>>>>> two
steps and no one here can even pay attention to one step.
*This right here is a type mismatch error*Which is computable from the code/description/specification/whatever. >>>>>>
The simplest step is that no Turing machine decider ever takes
another
directly executing Turing machine as its input yet the halting
problem
requires a halt decider to report on the behavior of the directly >>>>>>> executed machine.
This would not be an issue if the correct simulation of a Turing >>>>>>> machine
description always had the exact same behavior as the directly
executed
machine.
If HHH indeed simulated itself correctly, which is impossible.
That is not impossible when each simulation instance
has its own separate process context that has their
own set of 16 virtual registers and their own private
virtual stack kept in distinct memory locations.
I had to write x86utm as a multi-tasking operating
system to accomplish this. Without operating system
level functions to SaveState() and LoadState() to
enable context switching this would be impossible.
Everyone here sees that the behavior is not the same and rulesThe direct execution is wrong?
that the
simulation is wrong because it differs from the behavior of the
direct
execution.
*That is an incorrect measure of correct simulation*
Turing machine based halt deciders are accountable
for reporting on the behavior that their finite
string input specifies. They never have been accountable
for the behavior of the directly executed machine.
This is a nuance that all of the textbooks get wrong.
As usual incorrect claims without evidence. No textbook requires
such a thing.
*From the bottom of page 319*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
WM is the machine description of machine M
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.
Linz is requiring the decider embedded within
machine Ĥ to report on the behavior of its own
direct execution.
Right, because that *IS* the problem to solve, and their *IS* an
answer to that question.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Only under the false assumption that when an input
calls its own simulating termination analyzer that
this does not change the behavior specified by this
input from the behavior of the direct execution of
the corresponding same machine.
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>>>> of the
undecidability of the Halting Problem. While we do not >>>>>>>>>>>>> dispute the
conclusion that the Halting Problem is undecidable, we >>>>>>>>>>>>> argue that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. >>>>>>>>>>>>> Specifically,
we show that the contradiction used in the proof arises >>>>>>>>>>>>> from conflating
the behavior of encoded simulations with direct execution, >>>>>>>>>>>>> and from
making assumptions about a decider's domain that do not >>>>>>>>>>>>> hold under a
rigorous model of computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>> words you are
using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly >>>>>>>>>> snipping the substance of Richard's post, where he illustrated >>>>>>>>>> some of
the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
That you think a definition is incorrect does not change the
defined
meaning. If you don't accept the definition the best you can do is >>>>>>>> that you don't use the term.
That I prove that a definition is derived from provably
false assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are derived >>>>>> does not matter. It is a category error to say that a defintion is >>>>>> incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then "counter-factual"
is not that word.
I did not even come up with that word.
ChatGPT, Claude.ai and Flibble came up with that word.
ChatGPT and Claude.ai say that the category error is
that the halting problem proofs conflate the behavior
of a directly executed Turing machine with the behavior
that a finite string machine description specifies to
a halt decider.
Everyone assumes that they must always be the same.
When the input to a halt decider contains its own
machine description such that this input is essentially
calling its own decider then the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩
correctly simulated by Ĥ.embedded_H differs from
the behavior of Ĥ applied to ⟨Ĥ⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
It is at this point that the recursive simulation
repeating pattern can be seen so Ĥ.embedded_H
correctly transitions to Ĥ.qn,
It does this on the basis that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
simulated by Ĥ.embedded_H cannot possibly reach
its own simulated final halt state of ⟨Ĥ.qn⟩.
To anyone that can understand, I just proved
that the input to Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies
non-terminating recursive simulation. Whereas
the behavior of Ĥ applied to ⟨Ĥ⟩ halts.
The error of the proof is that no Turing machine
is ever supposed to report on the behavior of any
directly executing machine. Thus the behavior of
Ĥ applied to ⟨Ĥ⟩ does not contradict Ĥ.embedded_H
applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn, rejecting
its input as non halting.
That you do not understand this is counter-factual
does not make it factual.
It does not matter what I understand. What matters is that readers who
care about truth are not deceived.
Right so we need to achieve mutual understanding
so that no readers are deceived by anyone.
When reviewers baselessly disagree there is no
basis for me to correct their lack of understanding.
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:_DDD()
On 7/24/2025 5:03 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 17:29 schreef olcott:
The directly executed HHH does reach its final halt state. DDD
correctly simulated by HHH cannot possibly reach its final halt state >>>>> no matter what HHH does because it remains stuck in recursive
simulation.
Indeed, but irrelevant. The simulating HHH does not do a correct
simulation, it aborts prematurely.
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
No need to repeat this failure of HHH. We know it. A correct simulation
Aborting prematurely literally means that after N instructions of DDD
are correctly emulated by HHH that this emulated DDD would reach its own >>> emulated "ret" instruction final halt state.
What value of N are you proposing?
Let's see: the call to HHH is #4, [waves hands], then another 4 inside
the next level of simulation, and after another 4 the first simulated
HHH (the one called by the input, not the outermost simulator. We are
now 3 levels in) decides that enough is enough and aborts,
Thus immediate killing its simulated DDD and
everything else that HHH was simulating thus
no simulated DDD or simulated HHH can possibly
ever return no matter how many or how few X86
instructions that the executed HHH correctly emulates.
On 7/24/2025 1:23 AM, Mikko wrote:
On 2025-07-23 12:33:56 +0000, olcott said:
On 7/23/2025 2:54 AM, Mikko wrote:
On 2025-07-22 13:22:59 +0000, olcott said:
On 7/22/2025 5:28 AM, Mikko wrote:
On 2025-07-21 14:01:43 +0000, olcott said:
On 7/21/2025 4:19 AM, Mikko wrote:
On 2025-07-20 19:17:59 +0000, olcott said:
On 7/20/2025 11:53 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/20/2025 11:13 AM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
You do not understand these words. You clearly don't understand what
"prove" means in mathematics,
I do not mean "prove" in that way. I go for the
higher level of abstraction of what-so-ever shows
that an expression of language is necessarily true
thus impossibly false.
As I said, you don't understand what "prove" means in mathematics. Some
airy-fairy half-baked "philosophical" nonsense just won't cut it here.
I go by any "sound" deductive inference
all mere proofs go by the lesser "valid"
deductive inference where the premises
could be false.
If your "proof" does not satisfy the definition of proof you must >>>>>>>> prove that it is valid.
A valid proof is syntactically entailed by its
possibly false premises.
A sound proof is semantically entailed by its
provably true premises.
A proof is not sound if it is not valid.
Yes and the conclusion has not been shown to be
true unless it is valid and its premises are true.
Premises of a sound proof need not be provably true. It is sufficient >>>>>> that they are true.
How do we know that the premises are true?
If we don't we can't know whether the proof is sound. Maybe it is,
maybe not.
Sometimes we may know the truth from own observation.
The definition of the semantic meaning of words
and the behavior of finite strings of code proves
that they are true.
Strings don't have any behaviour.
*This string does specify its behavior*
On 7/24/2025 4:24 PM, joes wrote:You failed to understand I was talking about the first simulated HHH
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
Aborting prematurely literally means that after N instructions of DDD
are correctly emulated by HHH that this emulated DDD would reach its
own emulated "ret" instruction final halt state.
What value of N are you proposing?
Let's see: the call to HHH is #4, [waves hands], then another 4 inside
the next level of simulation, and after another 4 the first simulated
HHH (the one called by the input, not the outermost simulator. We are
now 3 levels in) decides that enough is enough and aborts,
Thus immediate killing its simulated DDD and everything else that HHH
was simulating thus no simulated DDD or simulated HHH can possibly ever return no matter how many or how few X86 instructions that the executed
HHH correctly emulates.
This is the part that you fail to understand or understand that I am
correct and disagree anyway.
--returning to the outermost level which takes 3 more instructions to
halt, whereupon our treasured HHH returns that DDD halts. So,
4+4+4+3=15?
Of course the crux is that changing "HHH" changes the input, so HHH can
never do it.
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a
rigorous model of computation.
Your problem is you don't understand the meaning of the words you are
using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by dishonestly >>>>>>>>>> snipping the substance of Richard's post, where he illustrated some of
the words whose meaning PO fails to understand.
It never has been that I do not understand
the definitions of words it is that I have
proven that some of these definitions are incorrect.
That you think a definition is incorrect does not change the defined >>>>>>>> meaning. If you don't accept the definition the best you can do is >>>>>>>> that you don't use the term.
That I prove that a definition is derived from provably
false assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are derived >>>>>> does not matter. It is a category error to say that a defintion is >>>>>> incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then "counter-factual"
is not that word.
I did not even come up with that word.
On 7/24/2025 1:31 AM, Mikko wrote:
On 2025-07-23 12:25:35 +0000, olcott said:
On 7/23/2025 2:42 AM, Mikko wrote:
On 2025-07-22 13:50:22 +0000, olcott said:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:I have proven that my claims are self-evidently
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:It is also honest and truthful that people
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof >>>>>>>>>>>Your problem is you don't understand the meaning of the words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>>>> conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>> fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from >>>>>>>>>>> making assumptions about a decider's domain that do not hold under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>>>
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient >>>>>> technical compoetence unless a judge accepts your proof of your claims. >>>>>
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
It is not possible to prove that someting is self-evidently true.
No proof can convinceingly show that someting is self-evident to
those who don't already see it as self-evident.
The definitions of the meaning of the words
make these meanings self-evidently true.
Any valid inference on the basis of these
meanings makes the derived conclusion true.
Nice to see that you don't disagree.
"It is not possible to prove that someting is self-evidently true."
*Sure it is*
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof... https://en.wikipedia.org/wiki/Self-evidence
On 7/24/2025 5:03 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 17:29 schreef olcott:*Correctly emulated is defined as*
On 7/23/2025 3:49 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 15:50 schreef olcott:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem >>>>>>>>>>> ProofYour problem is you don't understand the meaning of the words >>>>>>>>>> you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>> of the
undecidability of the Halting Problem. While we do not
dispute the
conclusion that the Halting Problem is undecidable, we argue >>>>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>>>> conflating
the behavior of encoded simulations with direct execution, >>>>>>>>>>> and from
making assumptions about a decider's domain that do not hold >>>>>>>>>>> under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it
should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg
sufficient
technical compoetence unless a judge accepts your proof of your
claims.
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
As usual incorrect claims without evidence.
void DDD()
{
HHH(DDD);
return;
}
When anyone says that DDD correctly simulated by
HHH reaches its own "return" statement final halt
state if we just wait long enough this is either
a lie or a lack of sufficient technical competence.
Nobody said such a thing. Suggesting that somebody did, without any
evidence, may be considered as a lie.
We all know that HHH fails to reach the final halt state,
Counter-factual.
As usual claims without relevant evidence.
The directly executed HHH does reach its final halt state.
DDD correctly simulated by HHH cannot possibly reach its
final halt state no matter what HHH does because it remains
stuck in recursive simulation.
Indeed, but irrelevant. The simulating HHH does not do a correct
simulation, it aborts prematurely.
Emulated according to the rules of the x86 language.
This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Aborting prematurely literally means that after
N instructions of DDD are correctly emulated by
HHH that this emulated DDD would reach its own
emulated "ret" instruction final halt state.
What value of N are you proposing?We see that a correct simulation by world class simulators reach the
On 7/23/2025 3:43 AM, Fred. Zwarts wrote:
Op 22.jul.2025 om 17:31 schreef olcott:
On 7/22/2025 9:35 AM, joes wrote:
Am Mon, 21 Jul 2025 08:57:04 -0500 schrieb olcott:
On 7/21/2025 4:10 AM, Mikko wrote:Definitions are, by definition, correct, although maybe not useful.
That you think a definition is incorrect does not change the defined >>>>>> meaning. If you don't accept the definition the best you can do is >>>>>> thatThat I prove that a definition is derived from provably false
you don't use the term.
assumptions proves that this definition is incorrect.
No one here is capable of paying enough attention to my proof that the >>>>> halting problem definition is incorrect because my proof requires two >>>>> steps and no one here can even pay attention to one step.What's the second step?
*This right here is a type mismatch error*Which is computable from the code/description/specification/whatever.
The simplest step is that no Turing machine decider ever takes another >>>>> directly executing Turing machine as its input yet the halting problem >>>>> requires a halt decider to report on the behavior of the directly
executed machine.
This would not be an issue if the correct simulation of a Turing
machine
description always had the exact same behavior as the directly
executed
machine.
If HHH indeed simulated itself correctly, which is impossible.
That is not impossible when each simulation instance
has its own separate process context that has their
own set of 16 virtual registers and their own private
virtual stack kept in distinct memory locations.
I had to write x86utm as a multi-tasking operating
system to accomplish this. Without operating system
level functions to SaveState() and LoadState() to
enable context switching this would be impossible.
Everyone here sees that the behavior is not the same and rules thatThe direct execution is wrong?
the
simulation is wrong because it differs from the behavior of the direct >>>>> execution.
*That is an incorrect measure of correct simulation*
Turing machine based halt deciders are accountable
for reporting on the behavior that their finite
string input specifies. They never have been accountable
for the behavior of the directly executed machine.
This is a nuance that all of the textbooks get wrong.
As usual incorrect claims without evidence. No textbook requires such
a thing.
*From the bottom of page 319* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
WM is the machine description of machine M
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.
Linz is requiring the decider embedded within
machine Ĥ to report on the behavior of its own
direct execution.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
The decider must decide on its input. In this case the input specifies
a DDD calling an aborting HHH.
The input specifies that DDD calls HHH(DDD)
in recursive simulation that cannot possibly
reach the simulating final state of DDD.
HHH, as you claim, returns with a value 0 after the abort. This makes
that DDD reaches its final halt state. If HHH cannot simulate that
finite recursion, its simulation fails.
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>>>>> of the undecidability of the Halting Problem. While we do >>>>>>>>>>>>>> not dispute the conclusion that the Halting Problem is >>>>>>>>>>>>>> undecidable, we argue that the conventional proof fails to >>>>>>>>>>>>>> establish this conclusion due to a fundamental
misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>> decider's domain that do not hold under a rigorous model of >>>>>>>>>>>>>> computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by
dishonestly snipping the substance of Richard's post, where he >>>>>>>>>>> illustrated some of the words whose meaning PO fails to
understand.
It never has been that I do not understand the definitions of >>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>> defined meaning. If you don't accept the definition the best you >>>>>>>>> can do is that you don't use the term.
That I prove that a definition is derived from provably false
assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are
derived does not matter. It is a category error to say that a
defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your LYING
to them.
On 7/25/2025 2:53 AM, joes wrote:True if the input changes along with the simulator, but not if we
Am Thu, 24 Jul 2025 16:41:26 -0500 schrieb olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
Aborting prematurely literally means that after N instructions of
DDD are correctly emulated by HHH that this emulated DDD would reach >>>>> its own emulated "ret" instruction final halt state.
What value of N are you proposing?
Let's see: the call to HHH is #4, [waves hands], then another 4
inside the next level of simulation, and after another 4 the first
simulated HHH (the one called by the input, not the outermost
simulator. We are now 3 levels in) decides that enough is enough and
aborts,
Thus immediate killing its simulated DDD and everything else that HHH
was simulating thus no simulated DDD or simulated HHH can possibly
ever return no matter how many or how few X86 instructions that the
executed HHH correctly emulates.
This is the part that you fail to understand or understand that I am
correct and disagree anyway.
You failed to understand I was talking about the first simulated HHH
aborting, not the outermost simulator.
*I am trying to get you to understand that is impossible*
The only HHH that can possibly abort is the outermost directly executed
one.
On 7/25/2025 2:51 AM, Mikko wrote:
On 2025-07-24 12:51:52 +0000, olcott said:
On 7/24/2025 1:23 AM, Mikko wrote:
On 2025-07-23 12:33:56 +0000, olcott said:
The definition of the semantic meaning of words
and the behavior of finite strings of code proves
that they are true.
Strings don't have any behaviour.
*This string does specify its behavior*
No, it does not. The string does not behave according to the behaviour
it specifies.
*Correctly emulated is defined as*
Emulated according to the rules of the x86 language.
This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
HHH emulates
push ebp
mov ebp,esp
push 00002192
call 000015d2
Then HHH begins emulating itself emulating DDD
that emulates the above three of the above four
instructions again.
Right before HHH would emulate itself emulating
itself emulating itself HHH sees this recursive
emulation non-halting behavior pattern.
On 7/25/2025 3:01 AM, Mikko wrote:
On 2025-07-24 13:40:52 +0000, olcott said:
On 7/24/2025 1:31 AM, Mikko wrote:
On 2025-07-23 12:25:35 +0000, olcott said:
On 7/23/2025 2:42 AM, Mikko wrote:
On 2025-07-22 13:50:22 +0000, olcott said:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>> Problem ProofYour problem is you don't understand the meaning of the >>>>>>>>>>>> words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>>>> of the
undecidability of the Halting Problem. While we do not >>>>>>>>>>>>> dispute the
conclusion that the Halting Problem is undecidable, we >>>>>>>>>>>>> argue that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. >>>>>>>>>>>>> Specifically,
we show that the contradiction used in the proof arises >>>>>>>>>>>>> from conflating
the behavior of encoded simulations with direct execution, >>>>>>>>>>>>> and from
making assumptions about a decider's domain that do not >>>>>>>>>>>>> hold under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it >>>>>>>>>> should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg
sufficient
technical compoetence unless a judge accepts your proof of your >>>>>>>> claims.
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
It is not possible to prove that someting is self-evidently true.
No proof can convinceingly show that someting is self-evident to
those who don't already see it as self-evident.
The definitions of the meaning of the words
make these meanings self-evidently true.
Any valid inference on the basis of these
meanings makes the derived conclusion true.
Nice to see that you don't disagree.
"It is not possible to prove that someting is self-evidently true."
*Sure it is*
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
Nice to see that you found a confirmation of my point.
Likewise that the execution trace of DDD correctly
simulated by HHH conclusively proves that the input
to HHH(DDD) specifies the recursive emulation non
terminating behavior pattern.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Every time that I ask for a correct execution trace
that does not have recursive emulation all that I
ever get as a reply is weasel word double talk not
any sequence of machine addresses.
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>>>>>> of the undecidability of the Halting Problem. While we do >>>>>>>>>>>>>>> not dispute the conclusion that the Halting Problem is >>>>>>>>>>>>>>> undecidable, we argue that the conventional proof fails to >>>>>>>>>>>>>>> establish this conclusion due to a fundamental
misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>>> decider's domain that do not hold under a rigorous model of >>>>>>>>>>>>>>> computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by
dishonestly snipping the substance of Richard's post, where he >>>>>>>>>>>> illustrated some of the words whose meaning PO fails to >>>>>>>>>>>> understand.
It never has been that I do not understand the definitions of >>>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>> defined meaning. If you don't accept the definition the best you >>>>>>>>>> can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are
derived does not matter. It is a category error to say that a
defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your LYING
to them.
I identified the category error in the halting problem definition in this very forum several years ago independently of Olcott so stop lying, Damon.
/Flibble
On 7/25/2025 8:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>>>>>>> of the undecidability of the Halting Problem. While we do >>>>>>>>>>>>>>>> not dispute the conclusion that the Halting Problem is >>>>>>>>>>>>>>>> undecidable, we argue that the conventional proof fails to >>>>>>>>>>>>>>>> establish this conclusion due to a fundamental >>>>>>>>>>>>>>>> misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>>>> decider's domain that do not hold under a rigorous model of >>>>>>>>>>>>>>>> computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, where he >>>>>>>>>>>>> illustrated some of the words whose meaning PO fails to >>>>>>>>>>>>> understand.
It never has been that I do not understand the definitions of >>>>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>> defined meaning. If you don't accept the definition the best you >>>>>>>>>>> can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are >>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>> defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your LYING
to them.
I identified the category error in the halting problem definition in this
very forum several years ago independently of Olcott so stop lying,
Damon.
/Flibble
*This is professor Hehner's paper on the category error issue*
WST Workshop on Termination, Oxford, 2018
Objective and Subjective Specifications
Eric C.R. Hehner
Department of Computer Science, University of Toronto
Can Carol correctly answer “no” to this question? https://www.cs.toronto.edu/~hehner/OSS.pdf
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. While >>>>>>>>>>>>>>>> we do not dispute the conclusion that the Halting Problem >>>>>>>>>>>>>>>> is undecidable, we argue that the conventional proof >>>>>>>>>>>>>>>> fails to establish this conclusion due to a fundamental >>>>>>>>>>>>>>>> misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>>>> decider's domain that do not hold under a rigorous model >>>>>>>>>>>>>>>> of computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, where >>>>>>>>>>>>> he illustrated some of the words whose meaning PO fails to >>>>>>>>>>>>> understand.
It never has been that I do not understand the definitions of >>>>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>> defined meaning. If you don't accept the definition the best >>>>>>>>>>> you can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are >>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>> defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your
LYING to them.
I identified the category error in the halting problem definition in
this very forum several years ago independently of Olcott so stop
lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
It actuality, DDD doesn't call out to an HHH that is "outside" of itself (even if in the same memory space), but uses its internal copy (that
might be in the same memory space).
The problem of the decider needing the input to be in the same memory
space is that it can't then take all inputs, unless you define an input
in a way that is relocatable, and the decider needs to be able to handle
the input that actually uses a seperate copy of itself.
You may not have copied much of his arguement, but your method was
poluted by his logic.
And, your categories were NEVER actually defined in a usable method, as either there is no way to decide if the program to be decided is valid,
or you can make a valid pathological program by just an appropriate
altered copy of the decider.
On 7/25/2025 1:50 AM, Fred. Zwarts wrote:
Op 24.jul.2025 om 23:41 schreef olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:_DDD()
On 7/24/2025 5:03 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 17:29 schreef olcott:
The directly executed HHH does reach its final halt state. DDD
correctly simulated by HHH cannot possibly reach its final halt
state
no matter what HHH does because it remains stuck in recursive
simulation.
Indeed, but irrelevant. The simulating HHH does not do a correct
simulation, it aborts prematurely.
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We told you numerous times that these 18 bytes are irrelevant for the
problem. The whole DDD is irrelevant. Without DDD HHH has the same
problem:
int main() {
return HHH(main);
}
Here there is no DDD. HHH halts and reports that it does not halt.
It proves that HHH produces false negatives.
Not at all the huge mistake of computer science
is to believe that a Turing machine description
specifies the exact same behavior as the directly
executed machine.
This assumption is always correct except when a
simulating termination analyzer is applied to its
own machine description.
When it does do this then the behavior that HHH
reports supersedes and overrules the behavior of
the direct execution. Turing machines have never
been in the domain of any Turing machine decider.
Halt deciders are required to report on the behavior
that their finite string input specifies. The most
straight forward way to determine the behavior that
an input finite string specifies is to simulate this
finite string input and watch the behavior that results.
Directly executed Turing machines are outside of the
domain of every Turing machine decider because deciders
only take finite string inputs.
Part of the input to HHH is HHH itself, of which you claim that it
halts and returns 0. That makes both DDD and main halting. A
simulation that does not reproduce this specified behaviour fails.
Turing machine halt deciders have never been able
to report on the behavior of the direct execution
of any Turing machine.
They have used the behavior specified by their input
finite string machine description as a proxy for this
behavior.
When the input DDD to a simulating termination analyzer HHH
calls this same termination analyzer then the behavior of
DDD correctly simulated by HHH overrules and supersedes the
behavior of the directly executed DDD().
On 7/25/2025 2:53 AM, joes wrote:
Am Thu, 24 Jul 2025 16:41:26 -0500 schrieb olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
Aborting prematurely literally means that after N instructions of DDD >>>>> are correctly emulated by HHH that this emulated DDD would reach its >>>>> own emulated "ret" instruction final halt state.
What value of N are you proposing?
Let's see: the call to HHH is #4, [waves hands], then another 4 inside >>>> the next level of simulation, and after another 4 the first simulated
HHH (the one called by the input, not the outermost simulator. We are
now 3 levels in) decides that enough is enough and aborts,
Thus immediate killing its simulated DDD and everything else that HHH
was simulating thus no simulated DDD or simulated HHH can possibly ever
return no matter how many or how few X86 instructions that the executed
HHH correctly emulates.
This is the part that you fail to understand or understand that I am
correct and disagree anyway.
You failed to understand I was talking about the first simulated HHH
aborting, not the outermost simulator.
*I am trying to get you to understand that is impossible*
The only HHH that can possibly abort is the outermost
directly executed one.
returning to the outermost level which takes 3 more instructions to
halt, whereupon our treasured HHH returns that DDD halts. So,
4+4+4+3=15?
Of course the crux is that changing "HHH" changes the input, so HHH can >>>> never do it.
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. While >>>>>>>>>>>>>>>>> we do not dispute the conclusion that the Halting Problem >>>>>>>>>>>>>>>>> is undecidable, we argue that the conventional proof >>>>>>>>>>>>>>>>> fails to establish this conclusion due to a fundamental >>>>>>>>>>>>>>>>> misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>>>>> decider's domain that do not hold under a rigorous model >>>>>>>>>>>>>>>>> of computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, where >>>>>>>>>>>>>> he illustrated some of the words whose meaning PO fails to >>>>>>>>>>>>>> understand.
It never has been that I do not understand the definitions of >>>>>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>>> defined meaning. If you don't accept the definition the best >>>>>>>>>>>> you can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are >>>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>>> defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your
LYING to them.
I identified the category error in the halting problem definition in
this very forum several years ago independently of Olcott so stop
lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s "Impossible Program".
It actuality, DDD doesn't call out to an HHH that is "outside" of itself
(even if in the same memory space), but uses its internal copy (that
might be in the same memory space).
The problem of the decider needing the input to be in the same memory
space is that it can't then take all inputs, unless you define an input
in a way that is relocatable, and the decider needs to be able to handle
the input that actually uses a seperate copy of itself.
You may not have copied much of his arguement, but your method was
poluted by his logic.
And, your categories were NEVER actually defined in a usable method, as
either there is no way to decide if the program to be decided is valid,
or you can make a valid pathological program by just an appropriate
altered copy of the decider.
My method had/has nothing to do with Olcott's work; you are just a liar.
/Flibble
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. >>>>>>>>>>>>>>>>>> While we do not dispute the conclusion that the Halting >>>>>>>>>>>>>>>>>> Problem is undecidable, we argue that the conventional >>>>>>>>>>>>>>>>>> proof fails to establish this conclusion due to a >>>>>>>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. >>>>>>>>>>>>>>>>>> Specifically,
we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations >>>>>>>>>>>>>>>>>> with direct execution, and from making assumptions >>>>>>>>>>>>>>>>>> about a decider's domain that do not hold under a >>>>>>>>>>>>>>>>>> rigorous model of computation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>> where he illustrated some of the words whose meaning PO >>>>>>>>>>>>>>> fails to understand.Your problem is you don't understand the meaning of the >>>>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>
It never has been that I do not understand the definitions >>>>>>>>>>>>>> of words it is that I have proven that some of these >>>>>>>>>>>>>> definitions are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>>>> defined meaning. If you don't accept the definition the best >>>>>>>>>>>>> you can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are >>>>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>>>> defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your
LYING to them.
I identified the category error in the halting problem definition in
this very forum several years ago independently of Olcott so stop
lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
On 7/25/2025 12:33 PM, Richard Damon wrote:
On 7/25/25 12:24 PM, olcott wrote:
On 7/25/2025 3:01 AM, Mikko wrote:
On 2025-07-24 13:40:52 +0000, olcott said:
On 7/24/2025 1:31 AM, Mikko wrote:
On 2025-07-23 12:25:35 +0000, olcott said:
On 7/23/2025 2:42 AM, Mikko wrote:
On 2025-07-22 13:50:22 +0000, olcott said:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>> Problem ProofYour problem is you don't understand the meaning of the >>>>>>>>>>>>>> words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>> proof of the
undecidability of the Halting Problem. While we do not >>>>>>>>>>>>>>> dispute the
conclusion that the Halting Problem is undecidable, we >>>>>>>>>>>>>>> argue that the
conventional proof fails to establish this conclusion due >>>>>>>>>>>>>>> to a
fundamental misapplication of Turing machine semantics. >>>>>>>>>>>>>>> Specifically,
we show that the contradiction used in the proof arises >>>>>>>>>>>>>>> from conflating
the behavior of encoded simulations with direct
execution, and from
making assumptions about a decider's domain that do not >>>>>>>>>>>>>>> hold under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it >>>>>>>>>>>> should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg >>>>>>>>>> sufficient
technical compoetence unless a judge accepts your proof of >>>>>>>>>> your claims.
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
It is not possible to prove that someting is self-evidently true. >>>>>>>> No proof can convinceingly show that someting is self-evident to >>>>>>>> those who don't already see it as self-evident.
The definitions of the meaning of the words
make these meanings self-evidently true.
Any valid inference on the basis of these
meanings makes the derived conclusion true.
Nice to see that you don't disagree.
"It is not possible to prove that someting is self-evidently true."
*Sure it is*
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
Nice to see that you found a confirmation of my point.
Likewise that the execution trace of DDD correctly
simulated by HHH conclusively proves that the input
to HHH(DDD) specifies the recursive emulation non
terminating behavior pattern.
But you HHH doesn't do a correct simulation, so your claim is based on
a lie.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Every time that I ask for a correct execution trace
that does not have recursive emulation all that I
ever get as a reply is weasel word double talk not
any sequence of machine addresses.
Because you ask for strawmen.
That is asking for a sample of the cheese from the moon.
All you are doing is demonstarting your utter stupidity.
Note, you don't prove a claim by asking for counter examples, you need
to provide the proof, and that needs to START with the generally
accepted truths of the system, and use accepted truth preserving
operations on those to get to your final statement.
You can't do these steps.
The first step of DDD correctly emulated by HHH is
push ebp
The second step of DDD correctly emulated by HHH is
mov ebp,esp
The third step of DDD correctly emulated by HHH is
mov push 00002192
The fourth step of DDD correctly emulated by HHH is
call 000015d2
If you try to show otherwise every competent person
here will know that you are wrong.
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:No, it does not. Definitions are what they are. How they are >>>>>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>>>>> defintion is incorrect.
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. >>>>>>>>>>>>>>>>>>> While we do not dispute the conclusion that the Halting >>>>>>>>>>>>>>>>>>> Problem is undecidable, we argue that the conventional >>>>>>>>>>>>>>>>>>> proof fails to establish this conclusion due to a >>>>>>>>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. >>>>>>>>>>>>>>>>>>> Specifically,
we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations >>>>>>>>>>>>>>>>>>> with direct execution, and from making assumptions >>>>>>>>>>>>>>>>>>> about a decider's domain that do not hold under a >>>>>>>>>>>>>>>>>>> rigorous model of computation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>>> where he illustrated some of the words whose meaning PO >>>>>>>>>>>>>>>> fails to understand.Your problem is you don't understand the meaning of the >>>>>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>
It never has been that I do not understand the definitions >>>>>>>>>>>>>>> of words it is that I have proven that some of these >>>>>>>>>>>>>>> definitions are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>>>>> defined meaning. If you don't accept the definition the best >>>>>>>>>>>>>> you can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>>>>> assumptions proves that this definition is incorrect. >>>>>>>>>>>>
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your
LYING to them.
I identified the category error in the halting problem definition in >>>>> this very forum several years ago independently of Olcott so stop
lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++ programmer
who coded in C at University back in the early 1990s.
/Flibble
On 7/25/2025 10:10 AM, joes wrote:
Am Fri, 25 Jul 2025 09:15:52 -0500 schrieb olcott:
On 7/25/2025 2:53 AM, joes wrote:
Am Thu, 24 Jul 2025 16:41:26 -0500 schrieb olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
Aborting prematurely literally means that after N instructions of >>>>>>> DDD are correctly emulated by HHH that this emulated DDD would reach >>>>>>> its own emulated "ret" instruction final halt state.
What value of N are you proposing?
Let's see: the call to HHH is #4, [waves hands], then another 4
inside the next level of simulation, and after another 4 the first >>>>>> simulated HHH (the one called by the input, not the outermost
simulator. We are now 3 levels in) decides that enough is enough and >>>>>> aborts,
Thus immediate killing its simulated DDD and everything else that HHH >>>>> was simulating thus no simulated DDD or simulated HHH can possibly
ever return no matter how many or how few X86 instructions that the
executed HHH correctly emulates.
This is the part that you fail to understand or understand that I am >>>>> correct and disagree anyway.
You failed to understand I was talking about the first simulated HHH
aborting, not the outermost simulator.
*I am trying to get you to understand that is impossible*
The only HHH that can possibly abort is the outermost directly executed
one.
True if the input changes along with the simulator, but not if we
The input is always the exact same sequence of machine
language bytes.
simulate the fixed input (that aborts after 4+4=8 instructions of DDD,
when we encounter the second nested call to HHH) without prematurely
aborting.
*Correctly emulated is defined as*
Emulated according to the rules of the x86 language.
This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
There exists no finite or infinite number of correctly
emulated x86 instructions such that the emulated DDD
ever reaches its emulated "ret" instruction final halt
state because the input to HHH(DDD) specifies recursive
emulation.
I get that if you change what "HHH" refers to in order do extend the
simulation you necessarily simulate a different input. You don't.
On 7/25/2025 10:10 AM, joes wrote:Oh, really now? I thought it referred to its simulator HHH by name.
Am Fri, 25 Jul 2025 09:15:52 -0500 schrieb olcott:
On 7/25/2025 2:53 AM, joes wrote:
Am Thu, 24 Jul 2025 16:41:26 -0500 schrieb olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
Let's see: the call to HHH is #4, [waves hands], then another 4
inside the next level of simulation, and after another 4 the first >>>>>> simulated HHH (the one called by the input, not the outermost
simulator. We are now 3 levels in) decides that enough is enough
and aborts,
Thus immediate killing its simulated DDD and everything else that
HHH was simulating thus no simulated DDD or simulated HHH can
possibly ever return no matter how many or how few X86 instructions
that the executed HHH correctly emulates.
This is the part that you fail to understand or understand that I am >>>>> correct and disagree anyway.
You failed to understand I was talking about the first simulated HHH
aborting, not the outermost simulator.
*I am trying to get you to understand that is impossible*
The only HHH that can possibly abort is the outermost directly
executed one.
True if the input changes along with the simulator, but not if we
The input is always the exact same sequence of machine language bytes.
Not if DDD is simulated by something other than HHH, such as an UTM.simulate the fixed input (that aborts after 4+4=8 instructions of DDD,There exists no finite or infinite number of correctly emulated x86 instructions such that the emulated DDD ever reaches its emulated "ret" instruction final halt state because the input to HHH(DDD) specifies recursive emulation.
when we encounter the second nested call to HHH) without prematurely
aborting.
See above.I get that if you change what "HHH" refers to in order do extend the
simulation you necessarily simulate a different input. You don't.
On 7/25/2025 1:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:No, it does not. Definitions are what they are. How they are >>>>>>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>>>>>> defintion is incorrect.
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. >>>>>>>>>>>>>>>>>>>> While we do not dispute the conclusion that the Halting >>>>>>>>>>>>>>>>>>>> Problem is undecidable, we argue that the conventional >>>>>>>>>>>>>>>>>>>> proof fails to establish this conclusion due to a >>>>>>>>>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. >>>>>>>>>>>>>>>>>>>> Specifically,
we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations >>>>>>>>>>>>>>>>>>>> with direct execution, and from making assumptions >>>>>>>>>>>>>>>>>>>> about a decider's domain that do not hold under a >>>>>>>>>>>>>>>>>>>> rigorous model of computation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>>>> where he illustrated some of the words whose meaning PO >>>>>>>>>>>>>>>>> fails to understand.Your problem is you don't understand the meaning of the >>>>>>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>
It never has been that I do not understand the definitions >>>>>>>>>>>>>>>> of words it is that I have proven that some of these >>>>>>>>>>>>>>>> definitions are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>>>>>> defined meaning. If you don't accept the definition the best >>>>>>>>>>>>>>> you can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>>>>>> assumptions proves that this definition is incorrect. >>>>>>>>>>>>>
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your >>>>>>> LYING to them.
I identified the category error in the halting problem definition in >>>>>> this very forum several years ago independently of Olcott so stop
lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++ programmer
who coded in C at University back in the early 1990s.
/Flibble
// 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;
}
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
On 7/25/2025 10:10 AM, joes wrote:Oh, really now? I thought it referred to its simulator HHH by name.
Am Fri, 25 Jul 2025 09:15:52 -0500 schrieb olcott:
On 7/25/2025 2:53 AM, joes wrote:
Am Thu, 24 Jul 2025 16:41:26 -0500 schrieb olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
Let's see: the call to HHH is #4, [waves hands], then another 4 >>>>>>>> inside the next level of simulation, and after another 4 the first >>>>>>>> simulated HHH (the one called by the input, not the outermost
simulator. We are now 3 levels in) decides that enough is enough >>>>>>>> and aborts,
Thus immediate killing its simulated DDD and everything else that >>>>>>> HHH was simulating thus no simulated DDD or simulated HHH can
possibly ever return no matter how many or how few X86 instructions >>>>>>> that the executed HHH correctly emulates.
This is the part that you fail to understand or understand that I am >>>>>>> correct and disagree anyway.
You failed to understand I was talking about the first simulated HHH >>>>>> aborting, not the outermost simulator.
*I am trying to get you to understand that is impossible*
The only HHH that can possibly abort is the outermost directly
executed one.
True if the input changes along with the simulator, but not if we
The input is always the exact same sequence of machine language bytes.
The actual code has always been based on an x86 emulator
that emulates finite strings of x86 machine code bytes.
I only refer to the C code and the names of its functions
because this code is probably too difficult for anyone here:
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
simulate the fixed input (that aborts after 4+4=8 instructions of DDD, >>>> when we encounter the second nested call to HHH) without prematurelyThere exists no finite or infinite number of correctly emulated x86
aborting.
instructions such that the emulated DDD ever reaches its emulated "ret"
instruction final halt state because the input to HHH(DDD) specifies
recursive emulation.
Not if DDD is simulated by something other than HHH, such as an UTM.
For three years everyone here acts like it is
impossible for them to understand that the correct
emulation of an input that calls its own emulator
HHH(DDD) can possibly be different then the emulation
of the same input that does not call its own emulator
HHH1(DDD).
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
On 7/25/25 2:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:No, it does not. Definitions are what they are. How they are >>>>>>>>>>>>> derived does not matter. It is a category error to say that >>>>>>>>>>>>> a defintion is incorrect.
On 2025-07-20 15:36:51 +0000, olcott said:That I prove that a definition is derived from provably >>>>>>>>>>>>>> false assumptions proves that this definition is incorrect. >>>>>>>>>>>>>
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon >>>>>>>>>>>>>>>>>> wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. >>>>>>>>>>>>>>>>>>>> While we do not dispute the conclusion that the >>>>>>>>>>>>>>>>>>>> Halting Problem is undecidable, we argue that the >>>>>>>>>>>>>>>>>>>> conventional proof fails to establish this conclusion >>>>>>>>>>>>>>>>>>>> due to a fundamental misapplication of Turing machine >>>>>>>>>>>>>>>>>>>> semantics.
Specifically,
we show that the contradiction used in the proof >>>>>>>>>>>>>>>>>>>> arises from conflating the behavior of encoded >>>>>>>>>>>>>>>>>>>> simulations with direct execution, and from making >>>>>>>>>>>>>>>>>>>> assumptions about a decider's domain that do not hold >>>>>>>>>>>>>>>>>>>> under a rigorous model of computation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>>>> where he illustrated some of the words whose meaning PO >>>>>>>>>>>>>>>>> fails to understand.Your problem is you don't understand the meaning of >>>>>>>>>>>>>>>>>>> the words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>
It never has been that I do not understand the >>>>>>>>>>>>>>>> definitions of words it is that I have proven that some >>>>>>>>>>>>>>>> of these definitions are incorrect.
That you think a definition is incorrect does not change >>>>>>>>>>>>>>> the defined meaning. If you don't accept the definition >>>>>>>>>>>>>>> the best you can do is that you don't use the term. >>>>>>>>>>>>>>
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your >>>>>>> LYING to them.
I identified the category error in the halting problem definition
in this very forum several years ago independently of Olcott so
stop lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++
programmer who coded in C at University back in the early 1990s.
/Flibble
But if you were quoting Strachey, you would have used it or commented.
On Fri, 25 Jul 2025 15:10:39 -0400, Richard Damon wrote:
On 7/25/25 2:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:No, it does not. Definitions are what they are. How they are >>>>>>>>>>>>>> derived does not matter. It is a category error to say that >>>>>>>>>>>>>> a defintion is incorrect.
On 2025-07-20 15:36:51 +0000, olcott said:That I prove that a definition is derived from provably >>>>>>>>>>>>>>> false assumptions proves that this definition is incorrect. >>>>>>>>>>>>>>
On 7/20/2025 8:05 AM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>> [ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon >>>>>>>>>>>>>>>>>>> wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. >>>>>>>>>>>>>>>>>>>>> While we do not dispute the conclusion that the >>>>>>>>>>>>>>>>>>>>> Halting Problem is undecidable, we argue that the >>>>>>>>>>>>>>>>>>>>> conventional proof fails to establish this conclusion >>>>>>>>>>>>>>>>>>>>> due to a fundamental misapplication of Turing machine >>>>>>>>>>>>>>>>>>>>> semantics.
Specifically,
we show that the contradiction used in the proof >>>>>>>>>>>>>>>>>>>>> arises from conflating the behavior of encoded >>>>>>>>>>>>>>>>>>>>> simulations with direct execution, and from making >>>>>>>>>>>>>>>>>>>>> assumptions about a decider's domain that do not hold >>>>>>>>>>>>>>>>>>>>> under a rigorous model of computation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>>>>> where he illustrated some of the words whose meaning PO >>>>>>>>>>>>>>>>>> fails to understand.Your problem is you don't understand the meaning of >>>>>>>>>>>>>>>>>>>> the words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>>
It never has been that I do not understand the >>>>>>>>>>>>>>>>> definitions of words it is that I have proven that some >>>>>>>>>>>>>>>>> of these definitions are incorrect.
That you think a definition is incorrect does not change >>>>>>>>>>>>>>>> the defined meaning. If you don't accept the definition >>>>>>>>>>>>>>>> the best you can do is that you don't use the term. >>>>>>>>>>>>>>>
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your >>>>>>>> LYING to them.
I identified the category error in the halting problem definition >>>>>>> in this very forum several years ago independently of Olcott so
stop lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++
programmer who coded in C at University back in the early 1990s.
/Flibble
But if you were quoting Strachey, you would have used it or commented.
"I have an idea for a signaling simulating halt decider that forks the simulation into two branches if the input calls the halt decider as
per [Strachey 1965]'s "Impossible Program"" -- Flibble, 2022
/Flibblw
On 7/25/25 5:21 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 15:10:39 -0400, Richard Damon wrote:
On 7/25/25 2:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:That I prove that a definition is derived from provably >>>>>>>>>>>>>>>> false assumptions proves that this definition is >>>>>>>>>>>>>>>> incorrect.
On 7/20/2025 8:05 AM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>> [ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon >>>>>>>>>>>>>>>>>>>> wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard >>>>>>>>>>>>>>>>>>>>>> Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the >>>>>>>>>>>>>>>>>>>>>> standard proof of the undecidability of the Halting >>>>>>>>>>>>>>>>>>>>>> Problem. While we do not dispute the conclusion >>>>>>>>>>>>>>>>>>>>>> that the Halting Problem is undecidable, we argue >>>>>>>>>>>>>>>>>>>>>> that the conventional proof fails to establish this >>>>>>>>>>>>>>>>>>>>>> conclusion due to a fundamental misapplication of >>>>>>>>>>>>>>>>>>>>>> Turing machine semantics.
Specifically,
we show that the contradiction used in the proof >>>>>>>>>>>>>>>>>>>>>> arises from conflating the behavior of encoded >>>>>>>>>>>>>>>>>>>>>> simulations with direct execution, and from making >>>>>>>>>>>>>>>>>>>>>> assumptions about a decider's domain that do not >>>>>>>>>>>>>>>>>>>>>> hold under a rigorous model of computation. >>>>>>>>>>>>>>>>>>>
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>>>>>> where he illustrated some of the words whose meaning >>>>>>>>>>>>>>>>>>> PO fails to understand.Your problem is you don't understand the meaning of >>>>>>>>>>>>>>>>>>>>> the words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>>>
It never has been that I do not understand the >>>>>>>>>>>>>>>>>> definitions of words it is that I have proven that some >>>>>>>>>>>>>>>>>> of these definitions are incorrect.
That you think a definition is incorrect does not change >>>>>>>>>>>>>>>>> the defined meaning. If you don't accept the definition >>>>>>>>>>>>>>>>> the best you can do is that you don't use the term. >>>>>>>>>>>>>>>>
No, it does not. Definitions are what they are. How they >>>>>>>>>>>>>>> are derived does not matter. It is a category error to say >>>>>>>>>>>>>>> that a defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on >>>>>>>>> your LYING to them.
I identified the category error in the halting problem definition >>>>>>>> in this very forum several years ago independently of Olcott so >>>>>>>> stop lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++
programmer who coded in C at University back in the early 1990s.
/Flibble
But if you were quoting Strachey, you would have used it or commented.
"I have an idea for a signaling simulating halt decider that forks the
simulation into two branches if the input calls the halt decider as per
[Strachey 1965]'s "Impossible Program"" -- Flibble, 2022
/Flibblw
Well, the problem is that detecting that the input calls the decider
can't actually be done in the decider unless you use something like
Olcott's incorrect model.
It is proven that for Turing Machines, reliable detecting such a thing
is impossible, and thu there WILL be "impossible programs" that you
decider can't detect.
This is the same problem that makes your idea of categories not work,
Then, as I mentioned, you need to do a LOT of work about how to handle
the signalling, as what answer should you give for an input that
signals. You basically just refuesed to deal with that, just like Peter Olcott fails to try to handle the errors in his fault "proof"
[ Followup-To: set ]Honoured.
In comp.theory olcott <polcott333@gmail.com> wrote:...
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
More seriously, you told Ben Bacarisse on this newsgroup that you had
fully worked out turing machines which broke a proof of the Halting
Theorem. It transpired you were lying.
When the topic came up again for
discussion, you failed to deny writing the original lie.
That is the closest thing to a lie that I ever said.
When I said this I was actually meaning that I had
fully operational C code that is equivalent to a
Turing Machine.
I think it was a full blown lie intended to deceive. Did you ever
apologise to Ben for leading him up the garden path like that?
You have not and never have had "fully operational C code" that breaks a proof of the Halting Theorem. To say you had this, when you clearly
didn't, was a lie.
On Fri, 25 Jul 2025 17:40:49 -0400, Richard Damon wrote:
On 7/25/25 5:21 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 15:10:39 -0400, Richard Damon wrote:
On 7/25/25 2:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said: >>>>>>>>>>>>>>>>>>That I prove that a definition is derived from provably >>>>>>>>>>>>>>>>> false assumptions proves that this definition is >>>>>>>>>>>>>>>>> incorrect.
On 7/20/2025 8:05 AM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>>> [ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon >>>>>>>>>>>>>>>>>>>>> wrote:
On 7/20/25 12:58 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> Title: A Structural Analysis of the Standard >>>>>>>>>>>>>>>>>>>>>>> Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the >>>>>>>>>>>>>>>>>>>>>>> standard proof of the undecidability of the Halting >>>>>>>>>>>>>>>>>>>>>>> Problem. While we do not dispute the conclusion >>>>>>>>>>>>>>>>>>>>>>> that the Halting Problem is undecidable, we argue >>>>>>>>>>>>>>>>>>>>>>> that the conventional proof fails to establish this >>>>>>>>>>>>>>>>>>>>>>> conclusion due to a fundamental misapplication of >>>>>>>>>>>>>>>>>>>>>>> Turing machine semantics.
Specifically,
we show that the contradiction used in the proof >>>>>>>>>>>>>>>>>>>>>>> arises from conflating the behavior of encoded >>>>>>>>>>>>>>>>>>>>>>> simulations with direct execution, and from making >>>>>>>>>>>>>>>>>>>>>>> assumptions about a decider's domain that do not >>>>>>>>>>>>>>>>>>>>>>> hold under a rigorous model of computation. >>>>>>>>>>>>>>>>>>>>
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>>>>>>> where he illustrated some of the words whose meaning >>>>>>>>>>>>>>>>>>>> PO fails to understand.Your problem is you don't understand the meaning of >>>>>>>>>>>>>>>>>>>>>> the words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>>>>
It never has been that I do not understand the >>>>>>>>>>>>>>>>>>> definitions of words it is that I have proven that some >>>>>>>>>>>>>>>>>>> of these definitions are incorrect.
That you think a definition is incorrect does not change >>>>>>>>>>>>>>>>>> the defined meaning. If you don't accept the definition >>>>>>>>>>>>>>>>>> the best you can do is that you don't use the term. >>>>>>>>>>>>>>>>>
No, it does not. Definitions are what they are. How they >>>>>>>>>>>>>>>> are derived does not matter. It is a category error to say >>>>>>>>>>>>>>>> that a defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then >>>>>>>>>>>> "counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on >>>>>>>>>> your LYING to them.
I identified the category error in the halting problem definition >>>>>>>>> in this very forum several years ago independently of Olcott so >>>>>>>>> stop lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++
programmer who coded in C at University back in the early 1990s.
/Flibble
But if you were quoting Strachey, you would have used it or commented.
"I have an idea for a signaling simulating halt decider that forks the
simulation into two branches if the input calls the halt decider as per
[Strachey 1965]'s "Impossible Program"" -- Flibble, 2022
/Flibblw
Well, the problem is that detecting that the input calls the decider
can't actually be done in the decider unless you use something like
Olcott's incorrect model.
It is proven that for Turing Machines, reliable detecting such a thing
is impossible, and thu there WILL be "impossible programs" that you
decider can't detect.
This is the same problem that makes your idea of categories not work,
Then, as I mentioned, you need to do a LOT of work about how to handle
the signalling, as what answer should you give for an input that
signals. You basically just refuesed to deal with that, just like Peter
Olcott fails to try to handle the errors in his fault "proof"
My assertion that there is a category error in the halting problem proof
is orthogonal to and leveraged by my signalling halt decider idea.
/Flibble
On 7/25/25 5:49 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 17:40:49 -0400, Richard Damon wrote:
On 7/25/25 5:21 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 15:10:39 -0400, Richard Damon wrote:
On 7/25/25 2:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 7/20/2025 8:05 AM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>>>> [ Followup-To: set ]That you think a definition is incorrect does not >>>>>>>>>>>>>>>>>>> change the defined meaning. If you don't accept the >>>>>>>>>>>>>>>>>>> definition the best you can do is that you don't use >>>>>>>>>>>>>>>>>>> the term.
In comp.theory Mr Flibble
<flibble@red-dwarf.jmc.corp>
wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon >>>>>>>>>>>>>>>>>>>>>> wrote:
On 7/20/25 12:58 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> Title: A Structural Analysis of the Standard >>>>>>>>>>>>>>>>>>>>>>>> Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the >>>>>>>>>>>>>>>>>>>>>>>> standard proof of the undecidability of the >>>>>>>>>>>>>>>>>>>>>>>> Halting Problem. While we do not dispute the >>>>>>>>>>>>>>>>>>>>>>>> conclusion that the Halting Problem is >>>>>>>>>>>>>>>>>>>>>>>> undecidable, we argue that the conventional proof >>>>>>>>>>>>>>>>>>>>>>>> fails to establish this conclusion due to a >>>>>>>>>>>>>>>>>>>>>>>> fundamental misapplication of Turing machine >>>>>>>>>>>>>>>>>>>>>>>> semantics.
Specifically,
we show that the contradiction used in the proof >>>>>>>>>>>>>>>>>>>>>>>> arises from conflating the behavior of encoded >>>>>>>>>>>>>>>>>>>>>>>> simulations with direct execution, and from >>>>>>>>>>>>>>>>>>>>>>>> making assumptions about a decider's domain that >>>>>>>>>>>>>>>>>>>>>>>> do not hold under a rigorous model of >>>>>>>>>>>>>>>>>>>>>>>> computation.
Maybe it was you wanting to create that impression >>>>>>>>>>>>>>>>>>>>> by dishonestly snipping the substance of Richard's >>>>>>>>>>>>>>>>>>>>> post, where he illustrated some of the words whose >>>>>>>>>>>>>>>>>>>>> meaning PO fails to understand.Your problem is you don't understand the meaning >>>>>>>>>>>>>>>>>>>>>>> of the words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>>>>>
It never has been that I do not understand the >>>>>>>>>>>>>>>>>>>> definitions of words it is that I have proven that >>>>>>>>>>>>>>>>>>>> some of these definitions are incorrect. >>>>>>>>>>>>>>>>>>>
That I prove that a definition is derived from provably >>>>>>>>>>>>>>>>>> false assumptions proves that this definition is >>>>>>>>>>>>>>>>>> incorrect.
No, it does not. Definitions are what they are. How they >>>>>>>>>>>>>>>>> are derived does not matter. It is a category error to >>>>>>>>>>>>>>>>> say that a defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then >>>>>>>>>>>>> "counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on >>>>>>>>>>> your LYING to them.
I identified the category error in the halting problem
definition in this very forum several years ago independently >>>>>>>>>> of Olcott so stop lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s >>>>>>>> "Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++
programmer who coded in C at University back in the early 1990s.
/Flibble
But if you were quoting Strachey, you would have used it or
commented.
"I have an idea for a signaling simulating halt decider that forks
the simulation into two branches if the input calls the halt decider
as per [Strachey 1965]'s "Impossible Program"" -- Flibble, 2022
/Flibblw
Well, the problem is that detecting that the input calls the decider
can't actually be done in the decider unless you use something like
Olcott's incorrect model.
It is proven that for Turing Machines, reliable detecting such a thing
is impossible, and thu there WILL be "impossible programs" that you
decider can't detect.
This is the same problem that makes your idea of categories not work,
Then, as I mentioned, you need to do a LOT of work about how to handle
the signalling, as what answer should you give for an input that
signals. You basically just refuesed to deal with that, just like
Peter Olcott fails to try to handle the errors in his fault "proof"
My assertion that there is a category error in the halting problem
proof is orthogonal to and leveraged by my signalling halt decider
idea.
/Flibble
Yes, you assert that, but can't define it in a usable manner.
How can you tell if a given arbitrary program is in one or the other category?
Until you answer that, you idea is meaningless.
On Fri, 25 Jul 2025 18:24:39 -0400, Richard Damon wrote:
On 7/25/25 5:49 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 17:40:49 -0400, Richard Damon wrote:
On 7/25/25 5:21 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 15:10:39 -0400, Richard Damon wrote:
On 7/25/25 2:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote: >>>>>>>>>>>
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:No, the borrowed it for their learning, and used it based on >>>>>>>>>>>> your LYING to them.
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 7/20/2025 8:05 AM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>>>>> [ Followup-To: set ]That you think a definition is incorrect does not >>>>>>>>>>>>>>>>>>>> change the defined meaning. If you don't accept the >>>>>>>>>>>>>>>>>>>> definition the best you can do is that you don't use >>>>>>>>>>>>>>>>>>>> the term.
In comp.theory Mr Flibble
<flibble@red-dwarf.jmc.corp>
wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon >>>>>>>>>>>>>>>>>>>>>>> wrote:
On 7/20/25 12:58 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Title: A Structural Analysis of the Standard >>>>>>>>>>>>>>>>>>>>>>>>> Halting Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the >>>>>>>>>>>>>>>>>>>>>>>>> standard proof of the undecidability of the >>>>>>>>>>>>>>>>>>>>>>>>> Halting Problem. While we do not dispute the >>>>>>>>>>>>>>>>>>>>>>>>> conclusion that the Halting Problem is >>>>>>>>>>>>>>>>>>>>>>>>> undecidable, we argue that the conventional proof >>>>>>>>>>>>>>>>>>>>>>>>> fails to establish this conclusion due to a >>>>>>>>>>>>>>>>>>>>>>>>> fundamental misapplication of Turing machine >>>>>>>>>>>>>>>>>>>>>>>>> semantics.
Specifically,
we show that the contradiction used in the proof >>>>>>>>>>>>>>>>>>>>>>>>> arises from conflating the behavior of encoded >>>>>>>>>>>>>>>>>>>>>>>>> simulations with direct execution, and from >>>>>>>>>>>>>>>>>>>>>>>>> making assumptions about a decider's domain that >>>>>>>>>>>>>>>>>>>>>>>>> do not hold under a rigorous model of >>>>>>>>>>>>>>>>>>>>>>>>> computation.
Maybe it was you wanting to create that impression >>>>>>>>>>>>>>>>>>>>>> by dishonestly snipping the substance of Richard's >>>>>>>>>>>>>>>>>>>>>> post, where he illustrated some of the words whose >>>>>>>>>>>>>>>>>>>>>> meaning PO fails to understand.Your problem is you don't understand the meaning >>>>>>>>>>>>>>>>>>>>>>>> of the words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>>>>>>
It never has been that I do not understand the >>>>>>>>>>>>>>>>>>>>> definitions of words it is that I have proven that >>>>>>>>>>>>>>>>>>>>> some of these definitions are incorrect. >>>>>>>>>>>>>>>>>>>>
That I prove that a definition is derived from provably >>>>>>>>>>>>>>>>>>> false assumptions proves that this definition is >>>>>>>>>>>>>>>>>>> incorrect.
No, it does not. Definitions are what they are. How they >>>>>>>>>>>>>>>>>> are derived does not matter. It is a category error to >>>>>>>>>>>>>>>>>> say that a defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then >>>>>>>>>>>>>> "counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word. >>>>>>>>>>>>
I identified the category error in the halting problem
definition in this very forum several years ago independently >>>>>>>>>>> of Olcott so stop lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s >>>>>>>>> "Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++
programmer who coded in C at University back in the early 1990s. >>>>>>>
/Flibble
But if you were quoting Strachey, you would have used it or
commented.
"I have an idea for a signaling simulating halt decider that forks
the simulation into two branches if the input calls the halt decider >>>>> as per [Strachey 1965]'s "Impossible Program"" -- Flibble, 2022
/Flibblw
Well, the problem is that detecting that the input calls the decider
can't actually be done in the decider unless you use something like
Olcott's incorrect model.
It is proven that for Turing Machines, reliable detecting such a thing >>>> is impossible, and thu there WILL be "impossible programs" that you
decider can't detect.
This is the same problem that makes your idea of categories not work,
Then, as I mentioned, you need to do a LOT of work about how to handle >>>> the signalling, as what answer should you give for an input that
signals. You basically just refuesed to deal with that, just like
Peter Olcott fails to try to handle the errors in his fault "proof"
My assertion that there is a category error in the halting problem
proof is orthogonal to and leveraged by my signalling halt decider
idea.
/Flibble
Yes, you assert that, but can't define it in a usable manner.
How can you tell if a given arbitrary program is in one or the other
category?
Until you answer that, you idea is meaningless.
Category A: the halt decider
Category B: the input
/Flibble
On 7/25/2025 2:51 AM, Mikko wrote:
On 2025-07-24 12:51:52 +0000, olcott said:
On 7/24/2025 1:23 AM, Mikko wrote:
On 2025-07-23 12:33:56 +0000, olcott said:
The definition of the semantic meaning of words
and the behavior of finite strings of code proves
that they are true.
Strings don't have any behaviour.
*This string does specify its behavior*
No, it does not. The string does not behave according to the behaviour
it specifies.
*Correctly emulated is defined as*
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>>>>>> of the undecidability of the Halting Problem. While we do >>>>>>>>>>>>>>> not dispute the conclusion that the Halting Problem is >>>>>>>>>>>>>>> undecidable, we argue that the conventional proof fails to >>>>>>>>>>>>>>> establish this conclusion due to a fundamental
misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>>> decider's domain that do not hold under a rigorous model of >>>>>>>>>>>>>>> computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by
dishonestly snipping the substance of Richard's post, where he >>>>>>>>>>>> illustrated some of the words whose meaning PO fails to >>>>>>>>>>>> understand.
It never has been that I do not understand the definitions of >>>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>> defined meaning. If you don't accept the definition the best you >>>>>>>>>> can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are
derived does not matter. It is a category error to say that a
defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your LYING
to them.
I identified the category error in the halting problem definition in this very forum several years ago independently of Olcott so stop lying, Damon.
On 7/25/2025 4:26 PM, Richard Damon wrote:What words were changed to what?
On 7/25/25 4:34 PM, olcott wrote:
On 7/25/2025 3:04 PM, Richard Damon wrote:
On 7/25/25 3:50 PM, olcott wrote:
On 7/25/2025 1:07 PM, Richard Damon wrote:
I didn't call them a liar just because they disagreed.Yes, but you call anyone who disagrees with you as being dishonest.OK I will refrain from calling anyone a liar while I see that this
is mutually respected and there is no evidence that the reply is in
any way dishonest.
I called them a liar when they changed the words that I said and then
used these changed words as the basis of their rebuttal.
It is very wrong to say that DDD doesn't halt because HHH aborts it.If you want to insist on lying I will not stop calling you a liar.Changing the subject away from DDD simulated by HHH to anything elseNo, insisting that the criteria *IS* DDD simulated by HHH is the
counts as dishonesty.
dishonest claim, since it is a violation of the definition of halting.
Do you expect a nonterminating input to be completely simulated inThe only simulation that can be used as a replacement for the directThat you expect a correct simulation of a non-terminating input to be infinite is fucking nuts. When one instruction of a non-terminating
execution is the CORRECT (which means complete with no aborting)
input is correctly emulated then it is dishonest to conclude that zero instructions were emulated correctly.
Shown, where?Except it doesn't, as, as shown, it also includes statements that areI won't call you a liar unless you say a lie.The we must also agree that an actual lie only includes an
INTENTIONALLY false statement.
just blantently incorrect.
Guess how long the execution takes.That HHH emulates the exact sequence of machine code bytes that it isNo, you miss the requirement that to be correct, it must continue to
presented with according to the rules of the x86 language *IS THE
DEFINITION OF CORRECT EMULATION*
the final state, as that is also part of the x86 language.
Partial simulations are NOT "correct" when talking about non-halting.
That is fucking nuts. Non-terminating inputs cannot reach any final
state.
The simulation of an infinite loop is necessarily infinite. They areYou cannot possibly refute that with any kind of correct reasoning.
That the emulation must be infinite to be correct is fucking nuts.
I can vaguely imagine constructing infinitely many similar examples toIts the definition, to refuse to accept the definition is just stupid.
Your problem is you forget that the definition doesn't require HHH to
do that simulation, just show that the simulation by the UTM, of the
actual input (including the code of the *original* HHH) will not halt. Emphasis mine.
This is just your incorrect confusion between Knowledge and Truth.
The Truth of the halting is established by the UTM, but HHH can't
"wait" for the UTM, so needs to use proper logic to determine what it
will do.
The problem is that there is no proper logic to allow HHH to determine
a correct answer for D/DD (there is for DDD), because which ever answer
HHH ends up giving the correct answer will be the other.
For DDD, HHH just needs to return 1 to be correct, but your rules can't
justify that answer, so it can't do it and follow your rules.
That the correct answer is not computable isn't actually a problem, as
it was reaslized after Turing showned this one question wasn't
conputable, as the mathemeatics of infinity was discovered, it became
clear that there MUST have been MANY uncomputable problems by a simple
counting argument,but that seems to be beyond your understanding, as I
don't think you understand even simple infinities.
On 7/25/2025 8:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote: >>>>>>>>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof >>>>>>>>>>>>>>>> of the undecidability of the Halting Problem. While we do >>>>>>>>>>>>>>>> not dispute the conclusion that the Halting Problem is >>>>>>>>>>>>>>>> undecidable, we argue that the conventional proof fails to >>>>>>>>>>>>>>>> establish this conclusion due to a fundamental >>>>>>>>>>>>>>>> misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>>>> decider's domain that do not hold under a rigorous model of >>>>>>>>>>>>>>>> computation.
Your problem is you don't understand the meaning of the >>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, where he >>>>>>>>>>>>> illustrated some of the words whose meaning PO fails to >>>>>>>>>>>>> understand.
It never has been that I do not understand the definitions of >>>>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>> defined meaning. If you don't accept the definition the best you >>>>>>>>>>> can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are >>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>> defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your LYING
to them.
I identified the category error in the halting problem definition in this
very forum several years ago independently of Olcott so stop lying, Damon. >>
/Flibble
*This is professor Hehner's paper on the category error issue*
WST Workshop on Termination, Oxford, 2018
Objective and Subjective Specifications
Eric C.R. Hehner
Department of Computer Science, University of Toronto
Can Carol correctly answer “no” to this question? https://www.cs.toronto.edu/~hehner/OSS.pdf
On Fri, 25 Jul 2025 15:10:39 -0400, Richard Damon wrote:
On 7/25/25 2:10 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 14:05:27 -0400, Richard Damon wrote:
On 7/25/25 1:43 PM, Mr Flibble wrote:
On Fri, 25 Jul 2025 13:17:48 -0400, Richard Damon wrote:
On 7/25/25 9:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:No, it does not. Definitions are what they are. How they are >>>>>>>>>>>>>> derived does not matter. It is a category error to say that >>>>>>>>>>>>>> a defintion is incorrect.
On 2025-07-20 15:36:51 +0000, olcott said:That I prove that a definition is derived from provably >>>>>>>>>>>>>>> false assumptions proves that this definition is incorrect. >>>>>>>>>>>>>>
On 7/20/2025 8:05 AM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>> [ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon >>>>>>>>>>>>>>>>>>> wrote:
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>>>>>> proof of the undecidability of the Halting Problem. >>>>>>>>>>>>>>>>>>>>> While we do not dispute the conclusion that the >>>>>>>>>>>>>>>>>>>>> Halting Problem is undecidable, we argue that the >>>>>>>>>>>>>>>>>>>>> conventional proof fails to establish this conclusion >>>>>>>>>>>>>>>>>>>>> due to a fundamental misapplication of Turing machine >>>>>>>>>>>>>>>>>>>>> semantics.
Specifically,
we show that the contradiction used in the proof >>>>>>>>>>>>>>>>>>>>> arises from conflating the behavior of encoded >>>>>>>>>>>>>>>>>>>>> simulations with direct execution, and from making >>>>>>>>>>>>>>>>>>>>> assumptions about a decider's domain that do not hold >>>>>>>>>>>>>>>>>>>>> under a rigorous model of computation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>>>>> where he illustrated some of the words whose meaning PO >>>>>>>>>>>>>>>>>> fails to understand.Your problem is you don't understand the meaning of >>>>>>>>>>>>>>>>>>>> the words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>>>>
It never has been that I do not understand the >>>>>>>>>>>>>>>>> definitions of words it is that I have proven that some >>>>>>>>>>>>>>>>> of these definitions are incorrect.
That you think a definition is incorrect does not change >>>>>>>>>>>>>>>> the defined meaning. If you don't accept the definition >>>>>>>>>>>>>>>> the best you can do is that you don't use the term. >>>>>>>>>>>>>>>
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your >>>>>>>> LYING to them.
I identified the category error in the halting problem definition >>>>>>> in this very forum several years ago independently of Olcott so
stop lying, Damon.
/Flibble
No, you borrowed his same broken program setup.
Eh? No, I didn't you lying fool: my reference was [Strachey]'s
"Impossible Program".
Then why did you use Olcotts notation and not Strachey's
Note, Strachey uses CPL, not C.
Because nobody knows CPL as it is a dead language; I am a C++
programmer who coded in C at University back in the early 1990s.
/Flibble
But if you were quoting Strachey, you would have used it or commented.
"I have an idea for a signaling simulating halt decider that forks the simulation into two branches if the input calls the halt decider as
per [Strachey 1965]'s "Impossible Program"" -- Flibble, 2022
On 7/25/2025 3:01 AM, Mikko wrote:
On 2025-07-24 13:40:52 +0000, olcott said:
On 7/24/2025 1:31 AM, Mikko wrote:
On 2025-07-23 12:25:35 +0000, olcott said:
On 7/23/2025 2:42 AM, Mikko wrote:
On 2025-07-22 13:50:22 +0000, olcott said:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:It is also honest and truthful that people
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem ProofYour problem is you don't understand the meaning of the words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>>>>>
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient >>>>>>>> technical compoetence unless a judge accepts your proof of your claims.
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
It is not possible to prove that someting is self-evidently true.
No proof can convinceingly show that someting is self-evident to
those who don't already see it as self-evident.
The definitions of the meaning of the words
make these meanings self-evidently true.
Any valid inference on the basis of these
meanings makes the derived conclusion true.
Nice to see that you don't disagree.
"It is not possible to prove that someting is self-evidently true."
*Sure it is*
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
Nice to see that you found a confirmation of my point.
Likewise that the execution trace of DDD correctly
simulated by HHH conclusively proves that the input
to HHH(DDD) specifies the recursive emulation non
terminating behavior pattern.
On 7/25/2025 2:10 PM, joes wrote:But does DDD call whatever is behind the name "HHH" or does it call
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:The actual code has always been based on an x86 emulator that emulates
On 7/25/2025 10:10 AM, joes wrote:Oh, really now? I thought it referred to its simulator HHH by name.
Am Fri, 25 Jul 2025 09:15:52 -0500 schrieb olcott:
On 7/25/2025 2:53 AM, joes wrote:
Am Thu, 24 Jul 2025 16:41:26 -0500 schrieb olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
Let's see: the call to HHH is #4, [waves hands], then another 4 >>>>>>>> inside the next level of simulation, and after another 4 the
first simulated HHH (the one called by the input, not the
outermost simulator. We are now 3 levels in) decides that enough >>>>>>>> is enough and aborts,
Thus immediate killing its simulated DDD and everything else that >>>>>>> HHH was simulating thus no simulated DDD or simulated HHH can
possibly ever return no matter how many or how few X86
instructions that the executed HHH correctly emulates.
This is the part that you fail to understand or understand that I >>>>>>> am correct and disagree anyway.
You failed to understand I was talking about the first simulated
HHH aborting, not the outermost simulator.
*I am trying to get you to understand that is impossible*
The only HHH that can possibly abort is the outermost directly
executed one.
True if the input changes along with the simulator, but not if we
The input is always the exact same sequence of machine language bytes.
finite strings of x86 machine code bytes.
It is not impossible to understand. It is wrong. If we prefix allFor three years everyone here acts like it is impossible for them to understand that the correct emulation of an input that calls its ownNot if DDD is simulated by something other than HHH, such as an UTM.simulate the fixed input (that aborts after 4+4=8 instructionsThere exists no finite or infinite number of correctly emulated x86
of DDD, when we encounter the second nested call to HHH) without
prematurely aborting.
instructions such that the emulated DDD ever reaches its emulated
"ret" instruction final halt state because the input to HHH(DDD)
specifies recursive emulation.
emulator HHH(DDD) can possibly be different than the emulation of the
same input that does not call its own emulator HHH1(DDD).
On 7/25/2025 1:50 AM, Fred. Zwarts wrote:Your huge mistake is that you believe that what a decider sees is what
Op 24.jul.2025 om 23:41 schreef olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:_DDD()
On 7/24/2025 5:03 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 17:29 schreef olcott:
The directly executed HHH does reach its final halt state. DDD
correctly simulated by HHH cannot possibly reach its final halt
state
no matter what HHH does because it remains stuck in recursive
simulation.
Indeed, but irrelevant. The simulating HHH does not do a correct
simulation, it aborts prematurely.
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We told you numerous times that these 18 bytes are irrelevant for the
problem. The whole DDD is irrelevant. Without DDD HHH has the same
problem:
int main() {
return HHH(main);
}
Here there is no DDD. HHH halts and reports that it does not halt.
It proves that HHH produces false negatives.
Not at all the huge mistake of computer science
is to believe that a Turing machine description
specifies the exact same behavior as the directly
executed machine.
Alan Mackenzie <acm@muc.de> writes:
In comp.theory olcott <polcott333@gmail.com> wrote:...
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
More seriously, you told Ben Bacarisse on this newsgroup that you had
fully worked out turing machines which broke a proof of the Halting
Theorem. It transpired you were lying.
Just for the record, here is what PO said late 2018 early 2019:
On 12/14/2018 5:27 PM, peteolcott wrote that he had
"encoded all of the exact TMD [Turing Machine Description]
instructions of the Linz Turing machine H that correctly decides
halting for its fully encoded input pair: (Ĥ, Ĥ)."
Date: Sat, 15 Dec 2018 11:03:21 -0600
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
Date: Sat, 15 Dec 2018 01:28:22 -0600
"I now have an actual H that decides actual halting for an actual (Ĥ,
Ĥ) input pair. I have to write the UTM to execute this code, that
should not take very long. The key thing is the H and Ĥ are 100%
fully encoded as actual Turing machines."
Date: Sun, 16 Dec 2018 09:02:50 -0600
"I am waiting to encode the UTM in C++ so that I can actually execute
H on the input pair: (Ĥ, Ĥ). This should take a week or two [...] it
is exactly and precisely the Peter Linz H and Ĥ, with H actually
deciding input pair: (Ĥ, Ĥ)"
Date: Fri, 11 Jan 2019 16:24:36 -0600
"I provide the exact ⊢* wildcard states after the Linz H.q0 and after
Ĥ.qx (Linz incorrectly uses q0 twice) showing exactly how the actual
Linz H would correctly decide the actual Linz (Ĥ, Ĥ)."
When the topic came up again for
discussion, you failed to deny writing the original lie.
That is the closest thing to a lie that I ever said.
When I said this I was actually meaning that I had
fully operational C code that is equivalent to a
Turing Machine.
I think it was a full blown lie intended to deceive. Did you ever
apologise to Ben for leading him up the garden path like that?
No, never. In fact he kept insulting me until it became so egregious
that I decided to having nothing more to do with him.
What he did do was take months to slowly walk back the claim he made in December 2018. H and Ĥ became "virtual machines" and then started to be "sufficiently equivalent" to Linz's H and Ĥ rather the "exactly and precisely the Peter Linz H and Ĥ". By Sep 2020 he didn't even have it anymore:
"I will soon have a partial halt decider sufficiently equivalent to
the Linz H correctly deciding halting on the Linz Ĥ"
It took nearly two years to walk back the clear and explicit claim to
this vague and ill-defined claim of not having something!
You have not and never have had "fully operational C code" that breaks a
proof of the Halting Theorem. To say you had this, when you clearly
didn't, was a lie.
He also tried to pretend that the C code (which, as you say, he didn't
have) is what he always meant when he wrote the words I quoted above. I
defy anyone to read those words with PO's later claim that he meant C
code all along and not conclude that he was just lying again to try to
save some little face.
C code does not have "TMD instructions" that can be encoded. TMs (as in Linz) do. When executed, C code has no "exact ⊢* wildcard states after
the Linz H.q0" for PO to show. A TM would. C code does not need a UTM
to execute it (a TM does) and if he really meant that he had C code all along, does anyone think he could write a UTM for C in "a week or two"?
It is so patently obvious that he just had a manic episode in Dec 2018
that caused he to post all those exuberant claims, and so patently
obvious that he simply can't admit being wrong about anything that I
ended up feeling rather sorry for him -- until the insults started up
again.
--
Ben.
On 7/26/2025 3:50 AM, Fred. Zwarts wrote:I mean... what else would you need for a complete description?
Op 25.jul.2025 om 17:11 schreef olcott:
On 7/25/2025 1:50 AM, Fred. Zwarts wrote:
We told you numerous times that these 18 bytes are irrelevant for theNot at all the huge mistake of computer science is to believe that a
problem. The whole DDD is irrelevant. Without DDD HHH has the same
problem:
int main() {
return HHH(main);
}
Here there is no DDD. HHH halts and reports that it does not halt. It
proves that HHH produces false negatives.
Turing machine description specifies the exact same behavior as the
directly executed machine.
Exactly. He starts with the assumption that HHH necessarily decidesYour huge mistake is that you believe that what a decider sees is what
the input specifies.
But when there are bugs or limitations in the decider that makes that
it does not (cannot) see the specification, that does not change the
specification.
Until you refute that with an execution trace that conforms to the rulesThat would be the trace of DDD simulated by something nonaborting.
of the x86 language you will be considered insufficiently competent.
On 7/26/2025 3:05 AM, joes wrote:Ok, so modifying HHH to simulate further also changes the input DDD,
Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
When HHH emulates DDD then DDD calls HHH(DDD) based on whatever code isBut does DDD call whatever is behind the name "HHH" or does it call theOh, really now? I thought it referred to its simulator HHH by name.The actual code has always been based on an x86 emulator that emulates
finite strings of x86 machine code bytes.
fixed code that aborts just before the second recursive call? Because
DDD calling a modified HHH' is a different program.
at machine address 000015d2.
The trace only shows it is different. It remains to be shown that theSince the execution trace conclusively proves that it is correct yourFor three years everyone here acts like it is impossible for them toIt is not impossible to understand. It is wrong.
understand that the correct emulation of an input that calls its own
emulator HHH(DDD) can possibly be different than the emulation of the
same input that does not call its own emulator HHH1(DDD).
mere intuition to the contrary is proven to be incorrect.
Right?If we prefix all programs we pass to HHH with DDD, they should not be
aborted as if the were the same.
If HHH were a correct simulator, it would produce the same behaviour as
an UTM. (HHH1 is the same as HHH, right?)
On 7/26/2025 2:42 AM, joes wrote:I was asking for an example.
Am Fri, 25 Jul 2025 16:51:25 -0500 schrieb olcott:
On 7/25/2025 4:26 PM, Richard Damon wrote:
On 7/25/25 4:34 PM, olcott wrote:
On 7/25/2025 3:04 PM, Richard Damon wrote:
On 7/25/25 3:50 PM, olcott wrote:
On 7/25/2025 1:07 PM, Richard Damon wrote:
Richard changes whatever words I said to that he can rebut the changedWhat words were changed to what?Yes, but you call anyone who disagrees with you as being dishonest.I called them a liar when they changed the words that I said and then
used these changed words as the basis of their rebuttal.
words. Its different every time. This is an error of reasoning called strawman.
The input to HHH, which is DDD, does not specify non-halting.HHH aborts DDD because DDD correctly simulated by HHH cannot possiblyIt is very wrong to say that DDD doesn't halt because HHH aborts it.No, insisting that the criteria *IS* DDD simulated by HHH is theIf you want to insist on lying I will not stop calling you a liar.
dishonest claim, since it is a violation of the definition of
halting.
reach its "return" instruction final halt state. This proves that the
input to HHH(DDD) specifies non-halting behavior.
How many times do I have to keep repeating this before you can payNot at all, please.
attention?
No, and they are universally accepted. Do you expect an infinite loopRichards requirements are simply nuts and violate these requirements.That you expect a correct simulation of a non-terminating input to beDo you expect a nonterminating input to be completely simulated in
infinite is fucking nuts. When one instruction of a non-terminating
input is correctly emulated then it is dishonest to conclude that zero
instructions were emulated correctly.
finite time??? ALL instructions need to be simulated.
Where have you shown that unintentionally false statements are lies?The we must also agree that an actual lie only includes anExcept it doesn't, as, as shown, it also includes statements that are
INTENTIONALLY false statement.
just blantently incorrect.
...they don't need to halt.Guess how long the execution takes.No, you miss the requirement that to be correct, it must continue toThat is fucking nuts. Non-terminating inputs cannot reach any final
the final state, as that is also part of the x86 language.
Partial simulations are NOT "correct" when talking about non-halting.
state.
Proof pending.The simulating of any non-terminating input is only until theThe simulation of an infinite loop is necessarily infinite. They areThat the emulation must be infinite to be correct is fucking nuts.
not equivalent to bounded loops. Sometimes you want an infinite one.
non-terminating behavior pattern is correctly detected.
What do you think UTMs do.Its the definition, to refuse to accept the definition is just
stupid.
Ĥ applied to its own Turing Machine description WM requires Ĥ to report
on the behavior of itself: M.
No Turing machine can do that. Turing machines can only report on their inputs.
So HHH aborts after one repetition. Suppose HHH' aborted after twoEmphasis mine.Your problem is you forget that the definition doesn't require HHH to
do that simulation, just show that the simulation by the UTM, of the
actual input (including the code of the *original* HHH) will not
halt.
You completely missed the topic, but I wasn't talking to you.I can vaguely imagine constructing infinitely many similar examples toThis one fails to prove that halting is undecidable.
the halting problem, but I've always wondered if there are any more
interesting cases?
On 7/26/2025 1:06 PM, joes wrote:Or are you actually interested in how HHH simulates things, but who cares?
Am Sat, 26 Jul 2025 09:19:40 -0500 schrieb olcott:
On 7/26/2025 3:50 AM, Fred. Zwarts wrote:
Op 25.jul.2025 om 17:11 schreef olcott:
On 7/25/2025 1:50 AM, Fred. Zwarts wrote:
I mean... what else would you need for a complete description?Not at all the huge mistake of computer science is to believe that a >>>>> Turing machine description specifies the exact same behavior as the
directly executed machine.
Also, I got nothing to prove to you. Not that you would ever accept it.Exactly. He starts with the assumption that HHH necessarily decides
correctly, without a proof of the repeated call detection.
Until you refute that with an execution trace that conforms to theThat would be the trace of DDD simulated by something nonaborting. You
rules of the x86 language you will be considered insufficiently
competent.
know what it looks like.
In other words you do not understand these things well enough toThis here is an example of "rebutting changed words", or rather a
understand that when N instructions of DDD are correctly simulated by
HHH that no simulated DDD ever reaches its own simulated final halt
state.
On 7/26/2025 2:48 AM, Mikko wrote:
On 2025-07-25 14:42:20 +0000, olcott said:
On 7/25/2025 8:49 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:16:29 -0400, Richard Damon wrote:
On 7/24/25 9:36 AM, olcott wrote:
On 7/24/2025 1:28 AM, Mikko wrote:
On 2025-07-23 12:30:18 +0000, olcott said:I did not even come up with that word.
On 7/23/2025 2:50 AM, Mikko wrote:
On 2025-07-22 13:43:50 +0000, olcott said:
On 7/22/2025 5:33 AM, Mikko wrote:
On 2025-07-21 13:57:04 +0000, olcott said:
On 7/21/2025 4:10 AM, Mikko wrote:
On 2025-07-20 15:36:51 +0000, olcott said:
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> >>>>>>>>>>>>>>> wrote:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting >>>>>>>>>>>>>>>>>> Problem Proof
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard >>>>>>>>>>>>>>>>>> proof
of the undecidability of the Halting Problem. While we do >>>>>>>>>>>>>>>>>> not dispute the conclusion that the Halting Problem is >>>>>>>>>>>>>>>>>> undecidable, we argue that the conventional proof >>>>>>>>>>>>>>>>>> fails to
establish this conclusion due to a fundamental >>>>>>>>>>>>>>>>>> misapplication of Turing machine semantics. Specifically, >>>>>>>>>>>>>>>>>> we show that the contradiction used in the proof arises >>>>>>>>>>>>>>>>>> from conflating the behavior of encoded simulations with >>>>>>>>>>>>>>>>>> direct execution, and from making assumptions about a >>>>>>>>>>>>>>>>>> decider's domain that do not hold under a rigorous >>>>>>>>>>>>>>>>>> model of
computation.
Maybe it was you wanting to create that impression by >>>>>>>>>>>>>>> dishonestly snipping the substance of Richard's post, >>>>>>>>>>>>>>> where heYour problem is you don't understand the meaning of the >>>>>>>>>>>>>>>>> words you are using.
This is an ad hominem attack, not argumentation. >>>>>>>>>>>>>>>
illustrated some of the words whose meaning PO fails to >>>>>>>>>>>>>>> understand.
It never has been that I do not understand the definitions of >>>>>>>>>>>>>> words it is that I have proven that some of these definitions >>>>>>>>>>>>>> are incorrect.
That you think a definition is incorrect does not change the >>>>>>>>>>>>> defined meaning. If you don't accept the definition the >>>>>>>>>>>>> best you
can do is that you don't use the term.
That I prove that a definition is derived from provably false >>>>>>>>>>>> assumptions proves that this definition is incorrect.
No, it does not. Definitions are what they are. How they are >>>>>>>>>>> derived does not matter. It is a category error to say that a >>>>>>>>>>> defintion is incorrect.
*Yes this is a strange and rare case*
A category esrror is not a case.
Counter-factual.
If you need a magic word to make a truth of a lie then
"counter-factual"
is not that word.
ChatGPT, Claude.ai and Flibble came up with that word.
No, the borrowed it for their learning, and used it based on your
LYING
to them.
I identified the category error in the halting problem definition in
this
very forum several years ago independently of Olcott so stop lying,
Damon.
/Flibble
*This is professor Hehner's paper on the category error issue*
No, it is not. Hehner says nothing about categories or category errors.
WST Workshop on Termination, Oxford, 2018
Objective and Subjective Specifications
Eric C.R. Hehner
Department of Computer Science, University of Toronto
Can Carol correctly answer “no” to this question?
https://www.cs.toronto.edu/~hehner/OSS.pdf
He calls the category error by a different name.
On 7/26/2025 12:31 PM, Alan Mackenzie wrote:
Hello, Ben.
Ben Bacarisse <ben@bsb.me.uk> wrote:
Alan Mackenzie <acm@muc.de> writes:
[ .... ]
In comp.theory olcott <polcott333@gmail.com> wrote:...
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
More seriously, you told Ben Bacarisse on this newsgroup that you had >>>>>> fully worked out turing machines which broke a proof of the Halting >>>>>> Theorem. It transpired you were lying.
Just for the record, here is what PO said late 2018 early 2019:
On 12/14/2018 5:27 PM, peteolcott wrote that he had
"encoded all of the exact TMD [Turing Machine Description]
instructions of the Linz Turing machine H that correctly decides
halting for its fully encoded input pair: (Ĥ, Ĥ)."
Date: Sat, 15 Dec 2018 11:03:21 -0600
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz >>> specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
Date: Sat, 15 Dec 2018 01:28:22 -0600
"I now have an actual H that decides actual halting for an actual (Ĥ, >>> Ĥ) input pair. I have to write the UTM to execute this code, that >>> should not take very long. The key thing is the H and Ĥ are 100% >>> fully encoded as actual Turing machines."
Date: Sun, 16 Dec 2018 09:02:50 -0600
"I am waiting to encode the UTM in C++ so that I can actually execute >>> H on the input pair: (Ĥ, Ĥ). This should take a week or two [...] it >>> is exactly and precisely the Peter Linz H and Ĥ, with H actually
deciding input pair: (Ĥ, Ĥ)"
Date: Fri, 11 Jan 2019 16:24:36 -0600
"I provide the exact ⊢* wildcard states after the Linz H.q0 and after
Ĥ.qx (Linz incorrectly uses q0 twice) showing exactly how the actual >>> Linz H would correctly decide the actual Linz (Ĥ, Ĥ)."
Thanks for clarifying that.
I think I can understand a bit what it must feel like to be on the
receiving end of all this. Firstly you know through training that what
you're being told is definitely false, but on the other hand you don't
like to believe that somebody is lying; somehow you give them the
(temporary) benefit of the doubt. Then comes the depressing restoration
of truth and reality.
When the topic came up again for
discussion, you failed to deny writing the original lie.
That is the closest thing to a lie that I ever said.
When I said this I was actually meaning that I had
fully operational C code that is equivalent to a
Turing Machine.
I think it was a full blown lie intended to deceive. Did you ever
apologise to Ben for leading him up the garden path like that?
No, never. In fact he kept insulting me until it became so egregious
that I decided to having nothing more to do with him.
Somehow, that doesn't surprise me. I only post a little on this group
now (I never really posted much more) for similar reasons. I care about
the truth, including mathematical truth; although I've never specialised
in computation theory or mathematical logic, I care when these are
falsified by ignorant posters.
What really got my goat this time around was PO stridently and
hypocritically accusing others of being liars, given his own record.
What he did do was take months to slowly walk back the claim he made in
December 2018. H and Ĥ became "virtual machines" and then started to be >>> "sufficiently equivalent" to Linz's H and Ĥ rather the "exactly and
precisely the Peter Linz H and Ĥ". By Sep 2020 he didn't even have it >>> anymore:
"I will soon have a partial halt decider sufficiently equivalent to >>> the Linz H correctly deciding halting on the Linz Ĥ"
It took nearly two years to walk back the clear and explicit claim to
this vague and ill-defined claim of not having something!
Yes. I've watched the latter part of this process.
You have not and never have had "fully operational C code" that
breaks a
proof of the Halting Theorem. To say you had this, when you clearly
didn't, was a lie.
He also tried to pretend that the C code (which, as you say, he didn't
have) is what he always meant when he wrote the words I quoted above. I >>> defy anyone to read those words with PO's later claim that he meant C
code all along and not conclude that he was just lying again to try to
save some little face.
What amazes me is he somehow thinks that theorems don't apply to him.
Of course, he doesn't understand what a theorem is, somehow construing
it as somebody's opinion. If it's just opinion, then his contrasting
opinion must be "just as good". Or something like that.
C code does not have "TMD instructions" that can be encoded. TMs (as in >>> Linz) do. When executed, C code has no "exact ⊢* wildcard states after >>> the Linz H.q0" for PO to show. A TM would. C code does not need a UTM >>> to execute it (a TM does) and if he really meant that he had C code all
along, does anyone think he could write a UTM for C in "a week or two"?
It is so patently obvious that he just had a manic episode in Dec 2018
that caused he to post all those exuberant claims, and so patently
obvious that he simply can't admit being wrong about anything that I
ended up feeling rather sorry for him -- until the insults started up
again.
That's another reason I don't post much, here. I really don't feel like
being insulted by somebody of PO's intellectual stature.
Have a good Sunday!
--
Ben.
In other words you will not give me an honest review.
On 7/26/2025 1:33 PM, joes wrote:Yeah, there aren't any.
Am Sat, 26 Jul 2025 08:41:08 -0500 schrieb olcott:
On 7/26/2025 2:42 AM, joes wrote:
Am Fri, 25 Jul 2025 16:51:25 -0500 schrieb olcott:
On 7/25/2025 4:26 PM, Richard Damon wrote:
On 7/25/25 4:34 PM, olcott wrote:
On 7/25/2025 3:04 PM, Richard Damon wrote:
Richard changes whatever words I said to that he can rebut the changedI was asking for an example.
words. Its different every time. This is an error of reasoning called
strawman.
How did you make that up? The correct trace is that of an UTM simulatingThe "correct" trace that you presume requires something like HHH takingThe input to HHH, which is DDD, does not specify non-halting.HHH aborts DDD because DDD correctly simulated by HHH cannot possiblyIt is very wrong to say that DDD doesn't halt because HHH aborts it.No, insisting that the criteria *IS* DDD simulated by HHH is theIf you want to insist on lying I will not stop calling you a liar.
dishonest claim, since it is a violation of the definition of
halting.
reach its "return" instruction final halt state. This proves that the
input to HHH(DDD) specifies non-halting behavior.
This only proves that HHH can't produce the correct trace.
"push ebp" to mean "jmp 000021a3"
On 7/26/2025 2:59 AM, Mikko wrote:
On 2025-07-25 16:24:37 +0000, olcott said:
On 7/25/2025 3:01 AM, Mikko wrote:
On 2025-07-24 13:40:52 +0000, olcott said:
On 7/24/2025 1:31 AM, Mikko wrote:
On 2025-07-23 12:25:35 +0000, olcott said:
On 7/23/2025 2:42 AM, Mikko wrote:
On 2025-07-22 13:50:22 +0000, olcott said:
On 7/22/2025 5:37 AM, Mikko wrote:
On 2025-07-21 13:45:24 +0000, olcott said:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote: >>>>>>>>>>>>>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem ProofYour problem is you don't understand the meaning of the words you are
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a >>>>>>>>>>>>>>> fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a
rigorous model of computation.
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should.
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
Where I live it is a crime to call anyone a liar or lacinkg sufficient
technical compoetence unless a judge accepts your proof of your claims.
I have proven that my claims are self-evidently
true on the basis of the meaning of their words
and the meaning of the code samples that I have
provided.
It is not possible to prove that someting is self-evidently true. >>>>>>>> No proof can convinceingly show that someting is self-evident to >>>>>>>> those who don't already see it as self-evident.
The definitions of the meaning of the words
make these meanings self-evidently true.
Any valid inference on the basis of these
meanings makes the derived conclusion true.
Nice to see that you don't disagree.
"It is not possible to prove that someting is self-evidently true."
*Sure it is*
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
Nice to see that you found a confirmation of my point.
Likewise that the execution trace of DDD correctly
simulated by HHH conclusively proves that the input
to HHH(DDD) specifies the recursive emulation non
terminating behavior pattern.
No, it does not. If it did the HHH would not be a decider.
The input specifies that the emulation is aborted and the
ececution is halted.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Unless the emulation of DDD by HHH (according to the
rules of the x86 language) proves that the emulated
DDD cannot possibly reach its own emulated "ret"
instruction final halt state.
On 7/26/2025 1:53 PM, joes wrote:
Am Sat, 26 Jul 2025 13:35:09 -0500 schrieb olcott:
On 7/26/2025 1:06 PM, joes wrote:Or are you actually interested in how HHH simulates things, but who
Am Sat, 26 Jul 2025 09:19:40 -0500 schrieb olcott:
On 7/26/2025 3:50 AM, Fred. Zwarts wrote:
Op 25.jul.2025 om 17:11 schreef olcott:
On 7/25/2025 1:50 AM, Fred. Zwarts wrote:
I mean... what else would you need for a complete description?Not at all the huge mistake of computer science is to believe that a >>>>>>> Turing machine description specifies the exact same behavior as the >>>>>>> directly executed machine.
cares?
Also, I got nothing to prove to you. Not that you would ever accept it.Exactly. He starts with the assumption that HHH necessarily decides
correctly, without a proof of the repeated call detection.
Until you refute that with an execution trace that conforms to theThat would be the trace of DDD simulated by something nonaborting. You >>>> know what it looks like.
rules of the x86 language you will be considered insufficiently
competent.
In other words you do not understand these things well enough to
understand that when N instructions of DDD are correctly simulated by
HHH that no simulated DDD ever reaches its own simulated final halt
state.
This here is an example of "rebutting changed words", or rather a
complete non sequitur copypaste.
Then you do understand that the above correctly simulated DDD
cannot possibly reach its own simulated "return" statement
final halt state?
On 7/27/2025 2:52 AM, Mikko wrote:
On 2025-07-26 14:02:15 +0000, olcott said:
On 7/26/2025 6:14 AM, Richard the Demon wrote:
On 7/25/25 9:29 PM, olcott wrote:
On 7/25/2025 8:22 PM, Richard the Demon wrote:
On 7/25/25 7:42 PM, olcott wrote: >>>>*You dishonestly changed the words that I said, as you always do*
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Until you provide the execution trace of DDD emulated
by HHH (according to the rules of the x86 language)
such that this emulated DDD reaches its own emulated
"ret" instruction final halt state
*you will be considered a fucking liar*
That is just a lIE.
Until you realize that HHH just doesn't do a correct simulation,
*Here are the words that I actually said*
(according to the rules of the x86 language)
Because your HHH ignores the last step of the last instruction it
processes, that of execute the next instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider *H correctly simulates its*
*input D until H correctly determines that its simulated D*
*would never stop running unless aborted* then
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
As soon as HHH emulates DDD then emulates itself
emulating DDD and this DDD calls HHH(DDD) to do it
again, HHH has matched a non-terminating behavior pattern.
That is false. The behavour of DDD is that it terminates.
Therefore no pattern it matches is a non-terminating pattern.
This ChatGPT analysis of its input below
correctly derives both of our views.
On 7/27/2025 3:27 AM, joes wrote:
Am Sat, 26 Jul 2025 14:04:16 -0500 schrieb olcott:
On 7/26/2025 1:33 PM, joes wrote:Yeah, there aren't any.
Am Sat, 26 Jul 2025 08:41:08 -0500 schrieb olcott:
On 7/26/2025 2:42 AM, joes wrote:
Am Fri, 25 Jul 2025 16:51:25 -0500 schrieb olcott:
On 7/25/2025 4:26 PM, Richard Damon wrote:
On 7/25/25 4:34 PM, olcott wrote:
On 7/25/2025 3:04 PM, Richard Damon wrote:
Richard changes whatever words I said to that he can rebut the changed >>>>> words. Its different every time. This is an error of reasoning called >>>>> strawman.I was asking for an example.
How did you make that up? The correct trace is that of an UTM simulatingThe "correct" trace that you presume requires something like HHH takingThe input to HHH, which is DDD, does not specify non-halting.No, insisting that the criteria *IS* DDD simulated by HHH is the >>>>>>>> dishonest claim, since it is a violation of the definition ofIf you want to insist on lying I will not stop calling you a liar. >>>>>> It is very wrong to say that DDD doesn't halt because HHH aborts it. >>>>> HHH aborts DDD because DDD correctly simulated by HHH cannot possibly >>>>> reach its "return" instruction final halt state. This proves that the >>>>> input to HHH(DDD) specifies non-halting behavior.
halting.
This only proves that HHH can't produce the correct trace.
"push ebp" to mean "jmp 000021a3"
DDD, which is one level longer than HHH's.
This ChatGPT analysis of its input below
correctly derives both of our views. I did
not bias this analysis by telling ChatGPT
what I expect to see.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then it returns 1.
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c
On 7/26/2025 3:50 AM, Fred. Zwarts wrote:
Op 25.jul.2025 om 17:11 schreef olcott:
On 7/25/2025 1:50 AM, Fred. Zwarts wrote:
Op 24.jul.2025 om 23:41 schreef olcott:
On 7/24/2025 4:24 PM, joes wrote:
Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:_DDD()
On 7/24/2025 5:03 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 17:29 schreef olcott:
The directly executed HHH does reach its final halt state. DDD >>>>>>>>> correctly simulated by HHH cannot possibly reach its final halt >>>>>>>>> state
no matter what HHH does because it remains stuck in recursive >>>>>>>>> simulation.
Indeed, but irrelevant. The simulating HHH does not do a correct >>>>>>>> simulation, it aborts prematurely.
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
We told you numerous times that these 18 bytes are irrelevant for
the problem. The whole DDD is irrelevant. Without DDD HHH has the
same problem:
int main() {
return HHH(main);
}
Here there is no DDD. HHH halts and reports that it does not halt.
It proves that HHH produces false negatives.
Not at all the huge mistake of computer science
is to believe that a Turing machine description
specifies the exact same behavior as the directly
executed machine.
Your huge mistake is that you believe that what a decider sees is what
the input specifies.
But when there are bugs or limitations in the decider that makes that
it does not (cannot) see the specification, that does not change the
specification.
All Turing machine halt deciders only compute
the mapping from finite string inputs on the
basis of the behavior that these finite strings
specify.
No Turing machine halt deciders ever directly
report on the behavior of any directly executed
Turing machine. They all use finite string machine
descriptions as a proxy. I have shown that this
is not a perfect proxy.
The behavior that these finite string specify
is correctly measured by DDD emulated by HHH
according to the rules of the x86 language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a verified fact that no matter how many or few
x86 instructions of DDD that HHH emulates that no
emulated DDD can possibly ever reach its own emulated
"ret" instruction final halt state.
Until you refute that with an execution trace that
conforms to the rules of the x86 language you will
be considered insufficiently competent.
The specification of the input does not depend on who looks at it.
Just like a red stain on your back is present, even if you cannot see it.
If some tools are insufficient to see the whole specification, that is
only an indication that it is not the correct tool.
If correct tools show us what is specified, we can conclude that other
tools that did not see it are incorrect.
On 7/26/2025 2:42 AM, joes wrote:
Am Fri, 25 Jul 2025 16:51:25 -0500 schrieb olcott:
On 7/25/2025 4:26 PM, Richard Damon wrote:What words were changed to what?
On 7/25/25 4:34 PM, olcott wrote:
On 7/25/2025 3:04 PM, Richard Damon wrote:
On 7/25/25 3:50 PM, olcott wrote:
On 7/25/2025 1:07 PM, Richard Damon wrote:
I didn't call them a liar just because they disagreed.Yes, but you call anyone who disagrees with you as being dishonest.OK I will refrain from calling anyone a liar while I see that this >>>>>>> is mutually respected and there is no evidence that the reply is in >>>>>>> any way dishonest.
I called them a liar when they changed the words that I said and then
used these changed words as the basis of their rebuttal.
Richard changes whatever words I said to that
he can rebut the changed words. Its different
every time. This is an error of reasoning called
strawman.
If you want to insist on lying I will not stop calling you a liar.Changing the subject away from DDD simulated by HHH to anything else >>>>> counts as dishonesty.No, insisting that the criteria *IS* DDD simulated by HHH is the
dishonest claim, since it is a violation of the definition of halting.
It is very wrong to say that DDD doesn't halt because HHH aborts it.
HHH aborts DDD because DDD correctly simulated by
HHH cannot possibly reach its "return" instruction
final halt state. This proves
that the input to
HHH(DDD) specifies non-halting behavior.
How many times do I have to keep repeating this before
you can pay attention?
On 7/28/2025 3:16 AM, Mikko wrote:
On 2025-07-27 14:47:13 +0000, olcott said:
On 7/27/2025 2:52 AM, Mikko wrote:
On 2025-07-26 14:02:15 +0000, olcott said:
On 7/26/2025 6:14 AM, Richard the Demon wrote:
On 7/25/25 9:29 PM, olcott wrote:
On 7/25/2025 8:22 PM, Richard the Demon wrote:
On 7/25/25 7:42 PM, olcott wrote: >>>>(according to the rules of the x86 language)
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Until you provide the execution trace of DDD emulated
by HHH (according to the rules of the x86 language)
such that this emulated DDD reaches its own emulated
"ret" instruction final halt state
*you will be considered a fucking liar*
That is just a lIE.
Until you realize that HHH just doesn't do a correct simulation, >>>>>>> *You dishonestly changed the words that I said, as you always do* >>>>>>> *Here are the words that I actually said*
Because your HHH ignores the last step of the last instruction it
processes, that of execute the next instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider *H correctly simulates its*
*input D until H correctly determines that its simulated D* >>>>> *would never stop running unless aborted* then
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
As soon as HHH emulates DDD then emulates itself
emulating DDD and this DDD calls HHH(DDD) to do it
again, HHH has matched a non-terminating behavior pattern.
That is false. The behavour of DDD is that it terminates.
Therefore no pattern it matches is a non-terminating pattern.
This ChatGPT analysis of its input below
correctly derives both of our views.
What ChatGPT says is irrelevant.
https://www.researchgate.net/publication/394042683_ChatGPT_analyzes_HHHDDD
The reasoning that ChatGPT provides proves that you are wrong.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:57:56 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,581 |