[ 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.
You seem far too ready to shout "AD HOMINEM!" whenever a post contains personal criticism. It's a cheap tool, and you use it dishonestly, as
you did in your last post.
It is a generally acknowledged fact that PO's understanding of the
topic dominating this newsgroup is far from good. Part of that is his failure to understand the meaning of the technical words he uses. To
write this from time to time is entirely legitimate.
/Flibble
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.
*The definition of the halting problem is provably incorrect*
<ChatGPT>[ Snip further garbage ]
</ChatGPT>
----
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/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, 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.
*The definition of the halting problem is provably incorrect*
Garbage. It is perfectly OK. 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.
<ChatGPT>[ Snip further garbage ]
</ChatGPT>
[ .... ]
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
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.
/Flibble
On 7/20/2025 6:13 AM, 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.
You are starting with an incorrect assumption that a "Correct
Simulation" can possible show behavior that is not in the direct
exectuion of the machine, but that is IMPOSSIBLE, as the DEFINITION of
"Correct Simulation" is that it reveals exactly the same behavior as
the direct execution of the machine.
<ChatGPT>
Misrepresentation of Input:
The standard proof assumes a decider
H(M,x) that determines whether machine
M halts on input x.
But this formulation is flawed, because:
Turing machines can only process finite
encodings (e.g. ⟨M⟩), not executable entities
like M.
So the valid formulation must be
H(⟨M⟩,x), where ⟨M⟩ is a string.
</ChatGPT>
You talk about the "misapplication of Turing Machine Semantics", but
you have shown that you don't understand what those are,
Sorry, your abstract just reveals that you don't know what you are
talking about.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
--
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 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.
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*
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.
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.
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.
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.
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:
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().
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.
The best that they can do is use a machine description
as a proxy for the behavior of the direct execution.
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.
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?
Its not that hard to determine that DD simulated by HHH
(according to the semantics of the C programming language)
specifies the non halting behavior of recursive simulation.
----
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.
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]
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?
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.
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.
I have also told you countless times that HHH
does simulate itself simulating DDD and I
have proven this by this execution trace.
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.
*This right here is a type mismatch error*
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.
Everyone here sees that the behavior is not the same
and rules that the simulation is wrong because it
differs from the behavior of the direct execution.
*That is an incorrect measure of correct simulation*
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.
I have also told you countless times that HHH
does simulate itself simulating DDD and I
have proven this by this execution trace.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That you don't know how to read an execution
trace does not mean that I have not proven this.
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.
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.
It is sufficient to note that "definition is incorrect" is a category
error and consequently a "proof" of that is bogus.
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.
On 7/21/25 11:50 PM, olcott wrote:
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
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.
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.
Because you are just showing you don't know English.
It is a verified fact that the PROGRAM DDD halts
since your HHH(DDD) returns 0.
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.
HHH emulates DDD and then emulates itself emulating DDD
until it sees that this emulated emulated DDD calls
HHH(DDD) to do this again.
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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
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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
It is a verified fact that the PROGRAM DDD halts
since your HHH(DDD) returns 0.
Turing machine halt deciders cannot possibly take
directly executed Turing machines as inputs thus
the behavior of any directly executed machine has
always been outside of the domain of every Turing
machine halt decider.
Every time that any proof says that decider H is
reporting on whether machine M halts on input i
this has always been incorrect.
Turing machine halt deciders can only report on
the behavior that their finite string input specifies.
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.
On 7/22/25 11:49 AM, olcott wrote:You are a fucking liar as anyone case see by my preceding sentence.
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE behavior
of the execution of DDD,
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE behavior
of the execution of DDD, to the SUBJECTIVE criteria of what HHH sees.
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.
The DDD built on your hypothetical HHH that doesn't is a different DDD
then the given to your real HHH, and thus its behavior is irrelevent.
HHH emulates DDD and then emulates itself emulating DDD
until it sees that this emulated emulated DDD calls
HHH(DDD) to do this again.
Whixh means you admirt that you "input" above is incomplete, as HHH--
can't "emulate itself" unless it is in the input that it uses.
THus we have diffferent input when we have different HHHs.
Your arguments to the contray are just admitting that neither your HHH
or your DDD are in the category of Programs, as required by the problem,
and thus your whole argument is a category error.
All you are doing it just proving and confirming that you are just a pathological liar that doesn't know what he is talking about, and
doesn't care about that error, as you think lies and strawmen are
acceptable logic.
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE behavior
of the execution of DDD, to the SUBJECTIVE criteria of what HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:You are a fucking liar as anyone case see by my preceding sentence.
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE behavior
of the execution of DDD,
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.
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.
Yet you know that you changed the question to a different question.
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.
The DDD built on your hypothetical HHH that doesn't is a different DDD
then the given to your real HHH, and thus its behavior is irrelevent.
HHH emulates DDD and then emulates itself emulating DDD
until it sees that this emulated emulated DDD calls
HHH(DDD) to do this again.
Whixh means you admirt that you "input" above is incomplete, as HHH
can't "emulate itself" unless it is in the input that it uses.
THus we have diffferent input when we have different HHHs.
Your arguments to the contray are just admitting that neither your HHH
or your DDD are in the category of Programs, as required by the
problem, and thus your whole argument is a category error.
All you are doing it just proving and confirming that you are just a
pathological liar that doesn't know what he is talking about, and
doesn't care about that error, as you think lies and strawmen are
acceptable logic.
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:You are a fucking liar as anyone case see by my preceding sentence.
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE behavior
of the execution of DDD,
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE behavior
of the execution of DDD, to the SUBJECTIVE criteria of what HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
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.
Yet you know that you changed the question to a different question.
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is irrelevant.
D halts even when not aborted,
because it calls a function H that aborts--
and halts. The simulation of an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 >>>>>>>>>>>> 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is irrelevant.
D halts even when not aborted,
because it calls a function H that aborts
and halts. The simulation of an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is irrelevant.
D halts even when not aborted,
because it calls a function H that aborts
and halts. The simulation of an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
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.
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.
Op 23.jul.2025 om 05:15 schreef olcott:
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.
Yet you know that you changed the question to a different question.
As usual counter-factual claims without evidence.
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/23/2025 3:40 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 05:15 schreef olcott:
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.
Yet you know that you changed the question to a different question.
As usual counter-factual claims without evidence.
*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.
*The question is*
Can DDD correctly emulated by HHH possibly reach
its own emulated "ret" instruction?
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is
irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Counter-factual.
That you do not understand the semantics of the
x86 language well enough to understand that this
is true is less than no rebuttal at all.
In the several years that I have presenting this
not one person has come up with a single correct
rebuttal to the statement that DD emulated by HHH
(according to the semantics of the x86 language)
would ever stop running of not aborted.
All of the rebuttals either used the strawman
deception to change the subject or were merely
a statement that my statement was really really
disbelieved. No one ever pointed out any actual error.
D halts even when not aborted,
Neither DD simulated by HHH, HHH nor DD()
halts unless HHH aborts its simulation of DD.
Disagreement is merely a failure to understand.
because it calls a function H that aborts and halts. The simulation of
an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is
irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Counter-factual.
That you do not understand the semantics of the
x86 language well enough to understand that this
is true is less than no rebuttal at all.
In the several years that I have presenting this
not one person has come up with a single correct
rebuttal to the statement that DD emulated by HHH
(according to the semantics of the x86 language)
would ever stop running of not aborted.
All of the rebuttals either used the strawman
deception to change the subject or were merely
a statement that my statement was really really
disbelieved. No one ever pointed out any actual error.
D halts even when not aborted,
Neither DD simulated by HHH, HHH nor DD()
halts unless HHH aborts its simulation of DD.
Disagreement is merely a failure to understand.
because it calls a function H that aborts and halts. The simulation of
an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
Alternatively DD emulated by HHH cannot possibly
reach its own "ret" instruction and halt no matter
what HHH does.
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
It is always the case that every halt decider is
only accountable for the behavior that its actual
input specifies and not accountable for the behavior
of any non-inputs. The textbooks don't do it this
way proves that textbooks are wrong.
Textbooks incorrectly assume that the behavior specified
by the finite string machine description of ⟨M⟩ is always
the same as the behavior of machine M. That is not the
case when M calls its own termination analyzer.
Turing machine halt deciders compute the mapping from
their input finite strings to the behavior that these
finite strings specify.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is
irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Counter-factual.
That you do not understand the semantics of the
x86 language well enough to understand that this
is true is less than no rebuttal at all.
In the several years that I have presenting this
not one person has come up with a single correct
rebuttal to the statement that DD emulated by HHH
(according to the semantics of the x86 language)
would ever stop running of not aborted.
All of the rebuttals either used the strawman
deception to change the subject or were merely
a statement that my statement was really really
disbelieved. No one ever pointed out any actual error.
D halts even when not aborted,
Neither DD simulated by HHH, HHH nor DD()
halts unless HHH aborts its simulation of DD.
Disagreement is merely a failure to understand.
because it calls a function H that aborts and halts. The simulation of
an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
Alternatively DD emulated by HHH cannot possibly
reach its own "ret" instruction and halt no matter
what HHH does.
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is
irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Counter-factual.
That you do not understand the semantics of the
x86 language well enough to understand that this
is true is less than no rebuttal at all.
In the several years that I have presenting this
not one person has come up with a single correct
rebuttal to the statement that DD emulated by HHH
(according to the semantics of the x86 language)
would ever stop running of not aborted.>
All of the rebuttals either used the strawman
deception to change the subject or were merely
a statement that my statement was really really
disbelieved. No one ever pointed out any actual error.
D halts even when not aborted,
Neither DD simulated by HHH, HHH nor DD()
halts unless HHH aborts its simulation of DD.
Disagreement is merely a failure to understand.
because it calls a function H that aborts and halts. The simulation of
an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
Alternatively DD emulated by HHH cannot possibly
reach its own "ret" instruction and halt no matter
what HHH does.
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
On 7/22/25 11:49 AM, olcott wrote:
On 7/22/2025 6:33 AM, Richard Damon wrote:
On 7/21/25 11:50 PM, olcott wrote:
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 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.
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.
Because you are just showing you don't know English.
Not at all. You dishonestly change the subject to
something besides DDD simulated by HHH.
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of what
HHH sees.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion is
irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
Counter-factual.
That you do not understand the semantics of the
x86 language well enough to understand that this
is true is less than no rebuttal at all.
In the several years that I have presenting this
not one person has come up with a single correct
rebuttal to the statement that DD emulated by HHH
(according to the semantics of the x86 language)
would ever stop running of not aborted.
All of the rebuttals either used the strawman
deception to change the subject or were merely
a statement that my statement was really really
disbelieved. No one ever pointed out any actual error.
D halts even when not aborted,
Neither DD simulated by HHH, HHH nor DD()
halts unless HHH aborts its simulation of DD.
Disagreement is merely a failure to understand.
because it calls a function H that aborts and halts. The simulation of
an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.
No, you have just been too stupid to see your error and to morally
corrupt to admit it.
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are you Damon?
/Flibble
Op 23.jul.2025 om 15:31 schreef olcott:
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of
what HHH sees.
It is always the case that every halt decider is
only accountable for the behavior that its actual
input specifies and not accountable for the behavior
of any non-inputs. The textbooks don't do it this
way proves that textbooks are wrong.
As usual irrelevant claim without evidence
Up to now you could not point to any textbook that is wrong.
Textbooks incorrectly assume that the behavior specified
by the finite string machine description of ⟨M⟩ is always
the same as the behavior of machine M. That is not the
case when M calls its own termination analyzer.
As usual repeated claims without any evidence.
The behaviour specified in the description of the input does not depend
on who analyses it. When some analysers are unable to see the whole specification, that is an error in the analyser, it does not change the specification.
Turing machine halt deciders compute the mapping from
their input finite strings to the behavior that these
finite strings specify.
Exactly.
And when a halting behaviour is specified, but the analyser is unable to
see that, the analyser is wrong. It should not compute the behaviour of
a hypothetical non-halting non-input.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion
is irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have been told many times that these 35 bytes are not the complete input. In fact they are the least interesting part of the input. DD is completely irrelevant. What is relevant is that HHH must simulate itself.
int main() {
return HHH(main);
}
Here is no DD, and your own words are that HHH returns and reports that
it does not halt.
This clearly shows that HHH is unable to analyse its own behaviour and produces false negative when it tries to do so.
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are you Damon?
/Flibble
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are you
Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
On 7/25/2025 3:49 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 15:31 schreef olcott:
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of
what HHH sees.
It is always the case that every halt decider is
only accountable for the behavior that its actual
input specifies and not accountable for the behavior
of any non-inputs. The textbooks don't do it this
way proves that textbooks are wrong.
As usual irrelevant claim without evidence
Up to now you could not point to any textbook that is wrong.
Textbooks incorrectly assume that the behavior specified
by the finite string machine description of ⟨M⟩ is always
the same as the behavior of machine M. That is not the
case when M calls its own termination analyzer.
As usual repeated claims without any evidence.
The behaviour specified in the description of the input does not
depend on who analyses it. When some analysers are unable to see the
whole specification, that is an error in the analyser, it does not
change the specification.
Turing machine halt deciders compute the mapping from
their input finite strings to the behavior that these
finite strings specify.
Exactly.
And when a halting behaviour is specified, but the analyser is unable
to see that, the analyser is wrong. It should not compute the
behaviour of a hypothetical non-halting non-input.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D >>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion
is irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have been told many times that these 35 bytes are not the complete
input. In fact they are the least interesting part of the input. DD is
completely irrelevant. What is relevant is that HHH must simulate itself.
int main() {
return HHH(main);
}
Here is no DD, and your own words are that HHH returns and reports
that it does not halt.
This clearly shows that HHH is unable to analyse its own behaviour and
produces false negative when it tries to do so.
When-so-ever the input to a simulating termination
analyzer calls its actual self as (your example above)
or when the HHH(DDD) input calls HHH(DDD) this does
specify recursive emulation that must be aborted to
prevent the non-termination of the directly executed HHH.
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are you
Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your lies.
I point out your stupidity to help people understand where you are
coming from so they don't try to find the logic in your illogical statements.
On 7/25/25 12:44 PM, olcott wrote:
On 7/25/2025 3:49 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 15:31 schreef olcott:
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
No, YOU changed the subject of the problem from the OBJECTIVE
behavior of the execution of DDD, to the SUBJECTIVE criteria of >>>>>>> what HHH sees.
It is always the case that every halt decider is
only accountable for the behavior that its actual
input specifies and not accountable for the behavior
of any non-inputs. The textbooks don't do it this
way proves that textbooks are wrong.
As usual irrelevant claim without evidence
Up to now you could not point to any textbook that is wrong.
Textbooks incorrectly assume that the behavior specified
by the finite string machine description of ⟨M⟩ is always
the same as the behavior of machine M. That is not the
case when M calls its own termination analyzer.
As usual repeated claims without any evidence.
The behaviour specified in the description of the input does not
depend on who analyses it. When some analysers are unable to see the
whole specification, that is an error in the analyser, it does not
change the specification.
Turing machine halt deciders compute the mapping from
their input finite strings to the behavior that these
finite strings specify.
Exactly.
And when a halting behaviour is specified, but the analyser is unable
to see that, the analyser is wrong. It should not compute the
behaviour of a hypothetical non-halting non-input.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D >>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly
detects that its D would never stop unless aborted', the conclusion >>>>> is irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have been told many times that these 35 bytes are not the
complete input. In fact they are the least interesting part of the
input. DD is completely irrelevant. What is relevant is that HHH must
simulate itself.
int main() {
return HHH(main);
}
Here is no DD, and your own words are that HHH returns and reports
that it does not halt.
This clearly shows that HHH is unable to analyse its own behaviour
and produces false negative when it tries to do so.
When-so-ever the input to a simulating termination
analyzer calls its actual self as (your example above)
or when the HHH(DDD) input calls HHH(DDD) this does
specify recursive emulation that must be aborted to
prevent the non-termination of the directly executed HHH.
Where do you get this claim from?
REMEMBER the problem order, HHH existed first, and can't change to avoid problems, THEN we create the input DDD, which uses that SPECIFIC HHH.
The template DDD might have existed first, but not the program DDD, and
the input is of the PROGRAM.
Either it aborted in this condition, at which the program that calls it
can use that fact to establish that it will halt,
or it doesn't abort, and then fails in the way you describe.
HHH can't treat the input that calls this HHH (that aborts) as calling
some other code (a version that does).
All you are doing is showing that your "logic" is based on lying.
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are you
Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your lies.
I point out your stupidity to help people understand where you are
coming from so they don't try to find the logic in your illogical
statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
On 7/25/2025 12:30 PM, Richard Damon wrote:
On 7/25/25 12:44 PM, olcott wrote:
On 7/25/2025 3:49 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 15:31 schreef olcott:
On 7/23/2025 3:24 AM, Fred. Zwarts wrote:
Op 23.jul.2025 om 06:05 schreef olcott:
On 7/22/2025 9:32 PM, Richard Damon wrote:
No, YOU changed the subject of the problem from the OBJECTIVE >>>>>>>> behavior of the execution of DDD, to the SUBJECTIVE criteria of >>>>>>>> what HHH sees.
It is always the case that every halt decider is
only accountable for the behavior that its actual
input specifies and not accountable for the behavior
of any non-inputs. The textbooks don't do it this
way proves that textbooks are wrong.
As usual irrelevant claim without evidence
Up to now you could not point to any textbook that is wrong.
Textbooks incorrectly assume that the behavior specified
by the finite string machine description of ⟨M⟩ is always
the same as the behavior of machine M. That is not the
case when M calls its own termination analyzer.
As usual repeated claims without any evidence.
The behaviour specified in the description of the input does not
depend on who analyses it. When some analysers are unable to see the
whole specification, that is an error in the analyser, it does not
change the specification.
Turing machine halt deciders compute the mapping from
their input finite strings to the behavior that these
finite strings specify.
Exactly.
And when a halting behaviour is specified, but the analyser is
unable to see that, the analyser is wrong. It should not compute the
behaviour of a hypothetical non-halting non-input.
*Its been three years now and you can't remember*
<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
H can abort its simulation of D and correctly report that D >>>>>>> specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly >>>>>> detects that its D would never stop unless aborted', the
conclusion is irrelevant.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have been told many times that these 35 bytes are not the
complete input. In fact they are the least interesting part of the
input. DD is completely irrelevant. What is relevant is that HHH
must simulate itself.
int main() {
return HHH(main);
}
Here is no DD, and your own words are that HHH returns and reports
that it does not halt.
This clearly shows that HHH is unable to analyse its own behaviour
and produces false negative when it tries to do so.
When-so-ever the input to a simulating termination
analyzer calls its actual self as (your example above)
or when the HHH(DDD) input calls HHH(DDD) this does
specify recursive emulation that must be aborted to
prevent the non-termination of the directly executed HHH.
Where do you get this claim from?
If you understood recursion well enough you
could have figured this out on your own
as four different chatbots did figure this
out on their own.
REMEMBER the problem order, HHH existed first, and can't change to
avoid problems, THEN we create the input DDD, which uses that SPECIFIC
HHH.
The template DDD might have existed first, but not the program DDD,
and the input is of the PROGRAM.
Either it aborted in this condition, at which the program that calls
it can use that fact to establish that it will halt,
or it doesn't abort, and then fails in the way you describe.
HHH can't treat the input that calls this HHH (that aborts) as calling
some other code (a version that does).
All you are doing is showing that your "logic" is based on lying.
All that the above shows is that you don't understand
recursion well enough. If you did understand recursion
well enough you would understand that the input to HHH(DDD)
does specify the recursive emulation non-halting 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]
The conclusive proof that I am right and you are
wrong is provided by the correct execution trace
of DDD emulated by HHH.
On 7/25/25 1:31 PM, olcott wrote:
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally >>>>>> corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are
you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your lies.
I point out your stupidity to help people understand where you are
coming from so they don't try to find the logic in your illogical
statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire.
You will need to get Fibber to agree to, or I will continue on him.
On 7/25/2025 1:07 PM, Richard Damon wrote:
On 7/25/25 1:31 PM, olcott wrote:
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally >>>>>>> corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are
you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your lies.
I point out your stupidity to help people understand where you are
coming from so they don't try to find the logic in your illogical
statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire.
You will need to get Fibber to agree to, or I will continue on him.
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.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
If you change the subject to anything else then this
change of subject makes you a liar.
On 7/25/25 3:50 PM, olcott wrote:
On 7/25/2025 1:07 PM, Richard Damon wrote:
On 7/25/25 1:31 PM, olcott wrote:
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally >>>>>>>> corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are >>>>>>> you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your lies. >>>>>
I point out your stupidity to help people understand where you are
coming from so they don't try to find the logic in your illogical
statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire.
You will need to get Fibber to agree to, or I will continue on him.
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.
Since you see anyone who disagrees with you as being dishonest that
doesn't count.
I won't call you a liar unless you say a lie.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the statement
is just a LIE.
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:
On 7/25/25 1:31 PM, olcott wrote:
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to morally >>>>>>>>> corrupt to admit it.
Yet another ad hominem attack, you are not very good at this are >>>>>>>> you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your lies. >>>>>>
I point out your stupidity to help people understand where you are >>>>>> coming from so they don't try to find the logic in your illogical >>>>>> statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire.
You will need to get Fibber to agree to, or I will continue on him.
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.
Since you see anyone who disagrees with you as being dishonest that
doesn't count.
Disagreeing doesn't count as dishonesty.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
I 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.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
You cannot possibly refute that with any kind of correct
reasoning. That the emulation must be infinite to be
correct is fucking nuts.
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:
On 7/25/25 1:31 PM, olcott wrote:
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to >>>>>>>>>> morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this >>>>>>>>> are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your >>>>>>> lies.
I point out your stupidity to help people understand where you
are coming from so they don't try to find the logic in your
illogical statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire.
You will need to get Fibber to agree to, or I will continue on him.
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.
Since you see anyone who disagrees with you as being dishonest that
doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest.
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.
The only simulation that can be used as a replacement for the direct execution is the CORRECT (which means complete with no aborting)
SIMULATION of the exact input, which must include in it ALL the code used.
I 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.
Except it doesn't, as, as shown, it also includes statements that are
just blantently incorrect.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue to the final state, as that is also part of the x86 language.
Partial simulations are NOT "correct" when talking about non-halting.
--
You cannot possibly refute that with any kind of correct
reasoning. That the emulation must be infinite to be
correct is fucking nuts.
Its the definition, do 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.
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 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:
On 7/25/25 1:31 PM, olcott wrote:OK I will refrain from calling anyone a liar while
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote:
No, you have just been too stupid to see your error and to >>>>>>>>>>> morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this >>>>>>>>>> are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance.
No, it is just the method that you both use to try to mask your >>>>>>>> lies.
I point out your stupidity to help people understand where you >>>>>>>> are coming from so they don't try to find the logic in your
illogical statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire.
You will need to get Fibber to agree to, or I will continue on him. >>>>>
I see that this is mutually respected and there is
no evidence that the reply is in any way dishonest.
Since you see anyone who disagrees with you as being dishonest that
doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest.
I didn't call them a liar just because they disagreed.
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.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
No,
Yes you are a liar otherwise.
insisting that the criteria *IS* DDD simulated by HHH is the dishonest
claim, since it is a violation of the definition of halting.
If you want to insist on lying I will not stop calling you a liar.
The only simulation that can be used as a replacement for the direct
execution is the CORRECT (which means complete with no aborting)
That you expect a correct simulation of a non-terminating
input to be 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.
SIMULATION of the exact input, which must include in it ALL the code
used.
I 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.
Except it doesn't, as, as shown, it also includes statements that are
just blantently incorrect.
Since that is not the way that most people take
the meaning of the word your use of this term
in that way is libelous.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue to
the final state, as that is also part of the x86 language.
That is fucking nuts. Non-terminating inputs cannot
reach any final state.
Partial simulations are NOT "correct" when talking about non-halting.
<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
until H correctly determines
until H correctly determines
You cannot possibly refute that with any kind of correct
reasoning. That the emulation must be infinite to be
correct is fucking nuts.
Its the definition, do 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.
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/25 5:51 PM, olcott wrote:
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:
On 7/25/25 1:31 PM, olcott wrote:OK I will refrain from calling anyone a liar while
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote: >>>>>>>>>>>
No, you have just been too stupid to see your error and to >>>>>>>>>>>> morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this >>>>>>>>>>> are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance. >>>>>>>>>>
No, it is just the method that you both use to try to mask your >>>>>>>>> lies.
I point out your stupidity to help people understand where you >>>>>>>>> are coming from so they don't try to find the logic in your >>>>>>>>> illogical statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire. >>>>>>>
You will need to get Fibber to agree to, or I will continue on him. >>>>>>
I see that this is mutually respected and there is
no evidence that the reply is in any way dishonest.
Since you see anyone who disagrees with you as being dishonest that >>>>> doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest.
I didn't call them a liar just because they disagreed.
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.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
No,
Yes you are a liar otherwise.
insisting that the criteria *IS* DDD simulated by HHH is the
dishonest claim, since it is a violation of the definition of halting.
If you want to insist on lying I will not stop calling you a liar.
The only simulation that can be used as a replacement for the direct
execution is the CORRECT (which means complete with no aborting)
That you expect a correct simulation of a non-terminating
input to be 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.
SIMULATION of the exact input, which must include in it ALL the code
used.
I 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.
Except it doesn't, as, as shown, it also includes statements that are
just blantently incorrect.
Since that is not the way that most people take
the meaning of the word your use of this term
in that way is libelous.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue to
the final state, as that is also part of the x86 language.
That is fucking nuts. Non-terminating inputs cannot
reach any final state.
Partial simulations are NOT "correct" when talking about non-halting.
<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
until H correctly determines
until H correctly determines
[[ Two year old style rant trimed ]]
But H can't "Correctly Determine" that, since it isn't true.
On 7/25/25 5:51 PM, olcott wrote:
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:
On 7/25/25 1:31 PM, olcott wrote:OK I will refrain from calling anyone a liar while
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote: >>>>>>>>>>>
No, you have just been too stupid to see your error and to >>>>>>>>>>>> morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this >>>>>>>>>>> are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance. >>>>>>>>>>
No, it is just the method that you both use to try to mask your >>>>>>>>> lies.
I point out your stupidity to help people understand where you >>>>>>>>> are coming from so they don't try to find the logic in your >>>>>>>>> illogical statements.
Try not using any insults and only rely on correct reasoning.
When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire. >>>>>>>
You will need to get Fibber to agree to, or I will continue on him. >>>>>>
I see that this is mutually respected and there is
no evidence that the reply is in any way dishonest.
Since you see anyone who disagrees with you as being dishonest that >>>>> doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest.
I didn't call them a liar just because they disagreed.
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.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
No,
Yes you are a liar otherwise.
insisting that the criteria *IS* DDD simulated by HHH is the
dishonest claim, since it is a violation of the definition of halting.
If you want to insist on lying I will not stop calling you a liar.
The only simulation that can be used as a replacement for the direct
execution is the CORRECT (which means complete with no aborting)
That you expect a correct simulation of a non-terminating
input to be 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.
SIMULATION of the exact input, which must include in it ALL the code
used.
I 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.
Except it doesn't, as, as shown, it also includes statements that are
just blantently incorrect.
Since that is not the way that most people take
the meaning of the word your use of this term
in that way is libelous.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue to
the final state, as that is also part of the x86 language.
That is fucking nuts. Non-terminating inputs cannot
reach any final state.
Partial simulations are NOT "correct" when talking about non-halting.
<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
until H correctly determines
until H correctly determines
[[ Two year old style rant trimed ]]
But H can't "Correctly Determine" that, since it isn't true.
The CORRECT SIMULATION of D WILL HALT, BECAUSE you H ultimate has been assumed to detect some pattern and stopped.
On 7/25/2025 5:45 PM, Richard Damon wrote:
On 7/25/25 5:51 PM, olcott wrote:
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:
On 7/25/25 1:31 PM, olcott wrote:OK I will refrain from calling anyone a liar while
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote: >>>>>>>>>>>>
No, you have just been too stupid to see your error and to >>>>>>>>>>>>> morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this >>>>>>>>>>>> are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance. >>>>>>>>>>>
No, it is just the method that you both use to try to mask >>>>>>>>>> your lies.
I point out your stupidity to help people understand where you >>>>>>>>>> are coming from so they don't try to find the logic in your >>>>>>>>>> illogical statements.
Try not using any insults and only rely on correct reasoning. >>>>>>>>> When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire. >>>>>>>>
You will need to get Fibber to agree to, or I will continue on him. >>>>>>>
I see that this is mutually respected and there is
no evidence that the reply is in any way dishonest.
Since you see anyone who disagrees with you as being dishonest
that doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest.
I didn't call them a liar just because they disagreed.
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.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
No,
Yes you are a liar otherwise.
insisting that the criteria *IS* DDD simulated by HHH is the
dishonest claim, since it is a violation of the definition of halting. >>>>
If you want to insist on lying I will not stop calling you a liar.
The only simulation that can be used as a replacement for the direct
execution is the CORRECT (which means complete with no aborting)
That you expect a correct simulation of a non-terminating
input to be 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.
SIMULATION of the exact input, which must include in it ALL the code
used.
I 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.
Except it doesn't, as, as shown, it also includes statements that
are just blantently incorrect.
Since that is not the way that most people take
the meaning of the word your use of this term
in that way is libelous.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue to
the final state, as that is also part of the x86 language.
That is fucking nuts. Non-terminating inputs cannot
reach any final state.
Partial simulations are NOT "correct" when talking about non-halting.
<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
until H correctly determines
until H correctly determines
[[ Two year old style rant trimed ]]
But H can't "Correctly Determine" that, since it isn't true.
I have told you that 500 times and you keep contradicting it.
That is either dishonestly or brain damage.
On 7/25/2025 5:45 PM, Richard Damon wrote:
On 7/25/25 5:51 PM, olcott wrote:
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:
On 7/25/25 1:31 PM, olcott wrote:OK I will refrain from calling anyone a liar while
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote: >>>>>>>>>>>>
No, you have just been too stupid to see your error and to >>>>>>>>>>>>> morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at this >>>>>>>>>>>> are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance. >>>>>>>>>>>
No, it is just the method that you both use to try to mask >>>>>>>>>> your lies.
I point out your stupidity to help people understand where you >>>>>>>>>> are coming from so they don't try to find the logic in your >>>>>>>>>> illogical statements.
Try not using any insults and only rely on correct reasoning. >>>>>>>>> When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars.
Remember, YOU started it, and refused the offer of a cease-fire. >>>>>>>>
You will need to get Fibber to agree to, or I will continue on him. >>>>>>>
I see that this is mutually respected and there is
no evidence that the reply is in any way dishonest.
Since you see anyone who disagrees with you as being dishonest
that doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest.
I didn't call them a liar just because they disagreed.
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.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
No,
Yes you are a liar otherwise.
insisting that the criteria *IS* DDD simulated by HHH is the
dishonest claim, since it is a violation of the definition of halting. >>>>
If you want to insist on lying I will not stop calling you a liar.
The only simulation that can be used as a replacement for the direct
execution is the CORRECT (which means complete with no aborting)
That you expect a correct simulation of a non-terminating
input to be 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.
SIMULATION of the exact input, which must include in it ALL the code
used.
I 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.
Except it doesn't, as, as shown, it also includes statements that
are just blantently incorrect.
Since that is not the way that most people take
the meaning of the word your use of this term
in that way is libelous.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue to
the final state, as that is also part of the x86 language.
That is fucking nuts. Non-terminating inputs cannot
reach any final state.
Partial simulations are NOT "correct" when talking about non-halting.
<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
until H correctly determines
until H correctly determines
[[ Two year old style rant trimed ]]
But H can't "Correctly Determine" that, since it isn't true.
The CORRECT SIMULATION of D WILL HALT, BECAUSE you H ultimate has been
assumed to detect some pattern and stopped.
_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*
On 7/25/25 7:42 PM, olcott wrote:*You dishonestly changed the words that I said, as you always do*
On 7/25/2025 5:45 PM, Richard Damon wrote:
On 7/25/25 5:51 PM, olcott wrote:
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:
On 7/25/25 1:31 PM, olcott wrote:
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote: >>>>>>>>>>>>>
No, you have just been too stupid to see your error and to >>>>>>>>>>>>>> morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at >>>>>>>>>>>>> this are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance. >>>>>>>>>>>>
No, it is just the method that you both use to try to mask >>>>>>>>>>> your lies.
I point out your stupidity to help people understand where >>>>>>>>>>> you are coming from so they don't try to find the logic in >>>>>>>>>>> your illogical statements.
Try not using any insults and only rely on correct reasoning. >>>>>>>>>> When you do this your reasoning errors will be laid bare.
Only if you first promise to also stop calling people liars. >>>>>>>>>
Remember, YOU started it, and refused the offer of a cease-fire. >>>>>>>>>
You will need to get Fibber to agree to, or I will continue on >>>>>>>>> him.
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.
Since you see anyone who disagrees with you as being dishonest
that doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest.
I didn't call them a liar just because they disagreed.
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.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
No,
Yes you are a liar otherwise.
insisting that the criteria *IS* DDD simulated by HHH is the
dishonest claim, since it is a violation of the definition of halting. >>>>>
If you want to insist on lying I will not stop calling you a liar.
The only simulation that can be used as a replacement for the
direct execution is the CORRECT (which means complete with no
aborting)
That you expect a correct simulation of a non-terminating
input to be 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.
SIMULATION of the exact input, which must include in it ALL the
code used.
I 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.
Except it doesn't, as, as shown, it also includes statements that
are just blantently incorrect.
Since that is not the way that most people take
the meaning of the word your use of this term
in that way is libelous.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the
statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue
to the final state, as that is also part of the x86 language.
That is fucking nuts. Non-terminating inputs cannot
reach any final state.
Partial simulations are NOT "correct" when talking about non-halting. >>>>>
<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
until H correctly determines
until H correctly determines
[[ Two year old style rant trimed ]]
But H can't "Correctly Determine" that, since it isn't true.
The CORRECT SIMULATION of D WILL HALT, BECAUSE you H ultimate has
been assumed to detect some pattern and stopped.
_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,
On 7/25/2025 8:22 PM, Richard Damon wrote:
On 7/25/25 7:42 PM, olcott wrote:*You dishonestly changed the words that I said, as you always do*
On 7/25/2025 5:45 PM, Richard Damon wrote:
On 7/25/25 5:51 PM, olcott wrote:
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:
On 7/25/25 1:31 PM, olcott wrote:
On 7/25/2025 12:25 PM, Richard Damon wrote:
On 7/25/25 10:43 AM, olcott wrote:
On 7/25/2025 8:56 AM, Mr Flibble wrote:
On Thu, 24 Jul 2025 22:58:34 -0400, Richard Damon wrote: >>>>>>>>>>>>>>
No, you have just been too stupid to see your error and >>>>>>>>>>>>>>> to morally
corrupt to admit it.
Yet another ad hominem attack, you are not very good at >>>>>>>>>>>>>> this are you Damon?
/Flibble
I think that he does this to attempt to mask his ignorance. >>>>>>>>>>>>>
No, it is just the method that you both use to try to mask >>>>>>>>>>>> your lies.
I point out your stupidity to help people understand where >>>>>>>>>>>> you are coming from so they don't try to find the logic in >>>>>>>>>>>> your illogical statements.
Try not using any insults and only rely on correct reasoning. >>>>>>>>>>> When you do this your reasoning errors will be laid bare. >>>>>>>>>>>
Only if you first promise to also stop calling people liars. >>>>>>>>>>
Remember, YOU started it, and refused the offer of a cease-fire. >>>>>>>>>>
You will need to get Fibber to agree to, or I will continue on >>>>>>>>>> him.
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.
Since you see anyone who disagrees with you as being dishonest >>>>>>>> that doesn't count.
Disagreeing doesn't count as dishonesty.
Yes, but you call anyone who disagrees with you as being dishonest. >>>>>>
I didn't call them a liar just because they disagreed.
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.
Changing the subject away from DDD simulated by
HHH to anything else counts as dishonesty.
No,
Yes you are a liar otherwise.
insisting that the criteria *IS* DDD simulated by HHH is the
dishonest claim, since it is a violation of the definition of
halting.
If you want to insist on lying I will not stop calling you a liar.
The only simulation that can be used as a replacement for the
direct execution is the CORRECT (which means complete with no
aborting)
That you expect a correct simulation of a non-terminating
input to be 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.
SIMULATION of the exact input, which must include in it ALL the
code used.
I 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.
Except it doesn't, as, as shown, it also includes statements that >>>>>> are just blantently incorrect.
Since that is not the way that most people take
the meaning of the word your use of this term
in that way is libelous.
For example when I refer to DDD correctly emulated
by HHH I mean that one or more instructions of DDD
have been emulated by HHH according to the rules
of the x86 language. This does include HHH emulating
itself when the emulated DDD calls HHH(DDD).
But that ISN'T the definition of a correct simulation, so the >>>>>>>> statement is just a LIE.
That HHH emulates the exact sequence of machine code bytes
that it is presented with according to the rules of the x86
language *IS THE DEFINITION OF CORRECT EMULATION*
No, you miss the requirement that to be correct, it must continue >>>>>> to the final state, as that is also part of the x86 language.
That is fucking nuts. Non-terminating inputs cannot
reach any final state.
Partial simulations are NOT "correct" when talking about non-halting. >>>>>>
<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
until H correctly determines
until H correctly determines
[[ Two year old style rant trimed ]]
But H can't "Correctly Determine" that, since it isn't true.
The CORRECT SIMULATION of D WILL HALT, BECAUSE you H ultimate has
been assumed to detect some pattern and stopped.
_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)
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 148:15:09 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
33 files (6,120K bytes) |
| Messages: | 2,410,932 |