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.
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.
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.
/Flibble
On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Mr Flibble <[email protected]> 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
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 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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/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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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.
In comp.theory olcott <[email protected]> wrote:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH might do is far short of sufficient "conclusively to prove" that the emulation is correct. To prove that is likely impossible in principle, that's even assuming you could define "correct" coherently.
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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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
Author: PL Olcott
Abstract:
This paper presents a formal critique of the standard proof of the >>>>>>>>> undecidability of the Halting Problem. While we do not dispute the >>>>>>>>> conclusion that the Halting Problem is undecidable, we argue >>>>>>>>> that the
conventional proof fails to establish this conclusion due to a >>>>>>>>> fundamental misapplication of Turing machine semantics.
Specifically,
we show that the contradiction used in the proof arises from >>>>>>>>> conflating
the behavior of encoded simulations with direct execution, and >>>>>>>>> from
making assumptions about a decider's domain that do not hold >>>>>>>>> under a
rigorous model of computation.
you are
using.
This is an ad hominem attack, not argumentation.
It is also honest and truthful, which is not as common as it should. >>>>>>
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/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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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: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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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.
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.
olcott <[email protected]> wrote:
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
[ .... ]
You will have a get out clause from the vagueness of your language, which >>>>> could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH >>> might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Which appears to be beside the point.
Exactly how is it that you could have construed this
as impossible in principle?
You seem to be "proving" the correctness of your emulation by giving one example of its execution and saying "because it works for this particular case, it works in general".
It is as though you are testing a multiplication program and give it the inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly. Actually, what you were testing turned out to be an addition program.
You can never prove a program is correct just by getting correct results
from a single run of it, or even correct results from several or many
runs. This is impossible in principle. And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.
On 7/22/2025 2:58 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
[ .... ]
You will have a get out clause from the vagueness of your
language, which
could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie.
Whatever HHH
might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle, >>>> that's even assuming you could define "correct" coherently.
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Which appears to be beside the point.
Exactly how is it that you could have construed this
as impossible in principle?
You seem to be "proving" the correctness of your emulation by giving one
example of its execution and saying "because it works for this particular
case, it works in general".
It is as though you are testing a multiplication program and give it the
inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly.
Actually, what you were testing turned out to be an addition program.
You can never prove a program is correct just by getting correct results
from a single run of it, or even correct results from several or many
runs. This is impossible in principle. And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.
It is certainly not impossible in principle
to prove that DDD is correctly emulated by HHH.
I claim that it is proved that DDD is correctly
emulated by HHH and your rebuttal totally changes
the subject. This strawman deception is the primary
form of every fake rebuttal of my work.
There have been zero correct rebuttals of any
detail of the essence of my work. Not one person
can point to any correct rebuttal of the essence
of my work in the last three years.
The fact that HHH(DD) rejects its input as non-halting
never was contradicted by the fact that the directly
executed DD() halts. It only seemed that way because
no one ever bothered to notice:
(a) Turing machine deciders only take finite
string inputs they never take directly executing
Turing machines as inputs.
(b) Turing machine deciders only compute the mapping
from their inputs on the basis of the behavior
specified by these inputs.
(c) When the input to a Turing machine decider
calls this same decider then the behavior of the
direct execution and the correct simulation diverge.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH(DD)==0 even though DD() halts.
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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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: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: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 <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
olcott <[email protected]> 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:
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 7/22/2025 2:58 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <[email protected]> wrote:
On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
[ .... ]
You will have a get out clause from the vagueness of your
language, which
could be construed to mean practically anything.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.
That's nauseatingly overstretching things into another lie.
Whatever HHH
might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle, >>>> that's even assuming you could define "correct" coherently.
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.
When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.
*That is a 100% concrete example of correct emulation*
Which appears to be beside the point.
Exactly how is it that you could have construed this
as impossible in principle?
You seem to be "proving" the correctness of your emulation by giving one
example of its execution and saying "because it works for this particular
case, it works in general".
It is as though you are testing a multiplication program and give it the
inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly.
Actually, what you were testing turned out to be an addition program.
You can never prove a program is correct just by getting correct results
from a single run of it, or even correct results from several or many
runs. This is impossible in principle. And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.
It is certainly not impossible in principle
to prove that DDD is correctly emulated by HHH.
I claim that it is proved that DDD is correctly
emulated by HHH and your rebuttal totally changes
the subject. This strawman deception is the primary
form of every fake rebuttal of my work.
There have been zero correct rebuttals of any
detail of the essence of my work. Not one person
can point to any correct rebuttal of the essence
of my work in the last three years.
The fact that HHH(DD) rejects its input as non-halting
never was contradicted by the fact that the directly
executed DD() halts. It only seemed that way because
no one ever bothered to notice:
(a) Turing machine deciders only take finite
string inputs they never take directly executing
Turing machines as inputs.
(b) Turing machine deciders only compute the mapping
from their inputs on the basis of the behavior
specified by these inputs.
(c) When the input to a Turing machine decider
calls this same decider then the behavior of the
direct execution and the correct simulation diverge.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH(DD)==0 even though DD() halts.
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/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/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/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/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/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/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)
On 7/26/2025 6:14 AM, Richard the Demon wrote:
On 7/25/25 9:29 PM, olcott wrote:
On 7/25/2025 8:22 PM, Richard the Demon wrote:
On 7/25/25 7:42 PM, olcott wrote: >>>>*You dishonestly changed the words that I said, as you always do*
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Until you provide the execution trace of DDD emulated
by HHH (according to the rules of the x86 language)
such that this emulated DDD reaches its own emulated
"ret" instruction final halt state
*you will be considered a fucking liar*
That is just a lIE.
Until you realize that HHH just doesn't do a correct simulation,
*Here are the words that I actually said*
(according to the rules of the x86 language)
Because your HHH ignores the last step of the last instruction it
processes, that of execute the next instruction.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider *H correctly simulates its*
*input D until H correctly determines that its simulated D*
*would never stop running unless aborted* then
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
As soon as HHH emulates DDD then emulates itself
emulating DDD and this DDD calls HHH(DDD) to do it
again, HHH has matched a non-terminating behavior pattern.
*You cannot possibly show any actual mistake in that*
It is a verified fact that no matter how many or few
x86 instructions of DDD that HHH emulates that no
emulated DDD can possibly ever reach its own emulated
"ret" instruction final halt state.
Like I said you remain a fucking liar until you refute
that with an execution trace that conforms to the rules
of the x86 language.
On 7/26/2025 1:11 PM, joes wrote:
Am Sat, 26 Jul 2025 08:48:48 -0500 schrieb olcott:
On 7/26/2025 3:05 AM, joes wrote:Ok, so modifying HHH to simulate further also changes the input DDD,
Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
When HHH emulates DDD then DDD calls HHH(DDD) based on whatever code isBut does DDD call whatever is behind the name "HHH" or does it call the >>>> fixed code that aborts just before the second recursive call? BecauseOh, really now? I thought it referred to its simulator HHH by name. >>>>> The actual code has always been based on an x86 emulator that emulates >>>>> finite strings of x86 machine code bytes.
DDD calling a modified HHH' is a different program.
at machine address 000015d2.
because it calls the same address. Gotcha.
The trace only shows it is different. It remains to be shown that theSince the execution trace conclusively proves that it is correct yourFor three years everyone here acts like it is impossible for them to >>>>> understand that the correct emulation of an input that calls its own >>>>> emulator HHH(DDD) can possibly be different than the emulation of the >>>>> same input that does not call its own emulator HHH1(DDD).It is not impossible to understand. It is wrong.
mere intuition to the contrary is proven to be incorrect.
abort was correct.
Right?If we prefix all programs we pass to HHH with DDD, they should not be
aborted as if the were the same.
If HHH were a correct simulator, it would produce the same behaviour as >>>> an UTM. (HHH1 is the same as HHH, right?)
All of the chatbots figure out that I am correct
on their own. I only give them this input:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then it returns 1.
Then they figure out all the other details on their own.Going from invalid and contradictory information, any conclusion can be
https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c
On 7/28/2025 3:43 AM, Fred. Zwarts wrote:
Op 26.jul.2025 om 20:46 schreef olcott:
On 7/26/2025 1:11 PM, joes wrote:
Am Sat, 26 Jul 2025 08:48:48 -0500 schrieb olcott:
On 7/26/2025 3:05 AM, joes wrote:Ok, so modifying HHH to simulate further also changes the input DDD,
Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
When HHH emulates DDD then DDD calls HHH(DDD) based on whateverBut does DDD call whatever is behind the name "HHH" or does itOh, really now? I thought it referred to its simulator HHH by name. >>>>>>> The actual code has always been based on an x86 emulator thatemulates
finite strings of x86 machine code bytes.
call the
fixed code that aborts just before the second recursive call? Because >>>>>> DDD calling a modified HHH' is a different program.
code is
at machine address 000015d2.
because it calls the same address. Gotcha.
The trace only shows it is different. It remains to be shown that theSince the execution trace conclusively proves that it is correct your >>>>> mere intuition to the contrary is proven to be incorrect.For three years everyone here acts like it is impossible for them to >>>>>>> understand that the correct emulation of an input that calls its own >>>>>>> emulator HHH(DDD) can possibly be different than the emulation of >>>>>>> theIt is not impossible to understand. It is wrong.
same input that does not call its own emulator HHH1(DDD).
abort was correct.
Right?If we prefix all programs we pass to HHH with DDD, they should not be >>>>>> aborted as if the were the same.
If HHH were a correct simulator, it would produce the same
behaviour as
an UTM. (HHH1 is the same as HHH, right?)
All of the chatbots figure out that I am correct
on their own. I only give them this input:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) It detects a non-terminating behavior pattern then it aborts its
simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then
it returns 1.
These cache-boxes are fed with invalid and contradictory information:
(a) No non-termination pattern can be detected when it aborts and
return, because the simulated HHH is also programmed to abort and return.
DDD correctly simulated by HHH cannot possibly reach its own
simulated "return" instruction final halt state in one to
infinity steps of correct simulation. This is a verified fact.
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
Op 28.jul.2025 om 14:46 schreef olcott:
On 7/28/2025 3:43 AM, Fred. Zwarts wrote:As usual incorrect claims without evidence.
Op 26.jul.2025 om 20:46 schreef olcott:
On 7/26/2025 1:11 PM, joes wrote:
Am Sat, 26 Jul 2025 08:48:48 -0500 schrieb olcott:
On 7/26/2025 3:05 AM, joes wrote:Ok, so modifying HHH to simulate further also changes the input DDD, >>>>>> because it calls the same address. Gotcha.
Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
When HHH emulates DDD then DDD calls HHH(DDD) based on whateverBut does DDD call whatever is behind the name "HHH" or does it >>>>>>>> call theOh, really now? I thought it referred to its simulator HHH by >>>>>>>>>> name.The actual code has always been based on an x86 emulator that >>>>>>>>> emulates
finite strings of x86 machine code bytes.
fixed code that aborts just before the second recursive call?
Because
DDD calling a modified HHH' is a different program.
code is
at machine address 000015d2.
The trace only shows it is different. It remains to be shown that the >>>>>> abort was correct.Since the execution trace conclusively proves that it is correct >>>>>>> yourFor three years everyone here acts like it is impossible for >>>>>>>>> them toIt is not impossible to understand. It is wrong.
understand that the correct emulation of an input that calls >>>>>>>>> its own
emulator HHH(DDD) can possibly be different than the emulation >>>>>>>>> of the
same input that does not call its own emulator HHH1(DDD).
mere intuition to the contrary is proven to be incorrect.
Right?If we prefix all programs we pass to HHH with DDD, they should >>>>>>>> not be
aborted as if the were the same.
If HHH were a correct simulator, it would produce the same
behaviour as
an UTM. (HHH1 is the same as HHH, right?)
All of the chatbots figure out that I am correct
on their own. I only give them this input:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) It detects a non-terminating behavior pattern then it aborts
its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement
then it returns 1.
These cache-boxes are fed with invalid and contradictory information:
(a) No non-termination pattern can be detected when it aborts and
return, because the simulated HHH is also programmed to abort and
return.
DDD correctly simulated by HHH cannot possibly reach its own
simulated "return" instruction final halt state in one to
infinity steps of correct simulation. This is a verified fact.
Your dreams are no verified facts. HHH aborts before the simulation
would reach the final halt state in a finite number of steps, as
proven by world-class simulators using exactly the same input. The
infinity is only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation
would reach the final halt state in a finite number of steps, as proven
by world-class simulators using exactly the same input. The infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
--
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/29/2025 5:38 PM, Richard Damon wrote:
On 7/29/25 5:15 PM, olcott wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
Op 28.jul.2025 om 14:46 schreef olcott:
On 7/28/2025 3:43 AM, Fred. Zwarts wrote:As usual incorrect claims without evidence.
Op 26.jul.2025 om 20:46 schreef olcott:
On 7/26/2025 1:11 PM, joes wrote:
Am Sat, 26 Jul 2025 08:48:48 -0500 schrieb olcott:
On 7/26/2025 3:05 AM, joes wrote:Ok, so modifying HHH to simulate further also changes the input >>>>>>>> DDD,
Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
When HHH emulates DDD then DDD calls HHH(DDD) based on whatever >>>>>>>>> code isBut does DDD call whatever is behind the name "HHH" or does it >>>>>>>>>> call theOh, really now? I thought it referred to its simulator HHH >>>>>>>>>>>> by name.The actual code has always been based on an x86 emulator that >>>>>>>>>>> emulates
finite strings of x86 machine code bytes.
fixed code that aborts just before the second recursive call? >>>>>>>>>> Because
DDD calling a modified HHH' is a different program.
at machine address 000015d2.
because it calls the same address. Gotcha.
The trace only shows it is different. It remains to be shownSince the execution trace conclusively proves that it isFor three years everyone here acts like it is impossible for >>>>>>>>>>> them to
understand that the correct emulation of an input that calls >>>>>>>>>>> its own
emulator HHH(DDD) can possibly be different than the
emulation of the
same input that does not call its own emulator HHH1(DDD). >>>>>>>>>> It is not impossible to understand. It is wrong.
correct your
mere intuition to the contrary is proven to be incorrect.
that the
abort was correct.
Right?If we prefix all programs we pass to HHH with DDD, they should >>>>>>>>>> not be
aborted as if the were the same.
If HHH were a correct simulator, it would produce the same >>>>>>>>>> behaviour as
an UTM. (HHH1 is the same as HHH, right?)
All of the chatbots figure out that I am correct
on their own. I only give them this input:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) It detects a non-terminating behavior pattern then it aborts >>>>>>> its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement >>>>>>> then it returns 1.
These cache-boxes are fed with invalid and contradictory information: >>>>>> (a) No non-termination pattern can be detected when it aborts and
return, because the simulated HHH is also programmed to abort and
return.
DDD correctly simulated by HHH cannot possibly reach its own
simulated "return" instruction final halt state in one to
infinity steps of correct simulation. This is a verified fact.
Your dreams are no verified facts. HHH aborts before the simulation
would reach the final halt state in a finite number of steps, as
proven by world-class simulators using exactly the same input. The
infinity is only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
And must CORRECTLY (amd completely) simulate that.
No you fucking liar a person can count to ten
without counting to infinity.
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <[email protected]> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation
would reach the final halt state in a finite number of steps, as proven >>>> by world-class simulators using exactly the same input. The infinity is >>>> only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no position to
call anybody else here a liar. Glass house inhabitants, throwing stones, >> and all that.
It has never actually been established that I even
made one single material mistake in any of my claims.
I have proved that the conventional proofs of the halting
problem can easily be overcome by a simulating termination
analyzer.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
DD correctly simulated by any HHH cannot possibly
reach the classic contradiction at the "if" statement
because DD calls HHH(DD) in recursive simulation.
Everyone here simply denies the possibility the
recursive simulation can possibly exist and claims
that my insistence that it does is a mistake that
I made.
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <[email protected]> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation
would reach the final halt state in a finite number of steps, as proven >>>> by world-class simulators using exactly the same input. The infinity is >>>> only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no position to
call anybody else here a liar. Glass house inhabitants, throwing stones, >> and all that.
And you used to distinguish yourself from other cranks by sticking to
decorous language, and generally being courteous. Not any more. That is >> a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
Op 28.jul.2025 om 14:46 schreef olcott:
On 7/28/2025 3:43 AM, Fred. Zwarts wrote:As usual incorrect claims without evidence.
Op 26.jul.2025 om 20:46 schreef olcott:
On 7/26/2025 1:11 PM, joes wrote:
Am Sat, 26 Jul 2025 08:48:48 -0500 schrieb olcott:
On 7/26/2025 3:05 AM, joes wrote:Ok, so modifying HHH to simulate further also changes the input DDD, >>>>>> because it calls the same address. Gotcha.
Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
When HHH emulates DDD then DDD calls HHH(DDD) based on whateverBut does DDD call whatever is behind the name "HHH" or does it >>>>>>>> call theOh, really now? I thought it referred to its simulator HHH by >>>>>>>>>> name.The actual code has always been based on an x86 emulator that >>>>>>>>> emulates
finite strings of x86 machine code bytes.
fixed code that aborts just before the second recursive call?
Because
DDD calling a modified HHH' is a different program.
code is
at machine address 000015d2.
The trace only shows it is different. It remains to be shown that the >>>>>> abort was correct.Since the execution trace conclusively proves that it is correct >>>>>>> yourFor three years everyone here acts like it is impossible for >>>>>>>>> them toIt is not impossible to understand. It is wrong.
understand that the correct emulation of an input that calls >>>>>>>>> its own
emulator HHH(DDD) can possibly be different than the emulation >>>>>>>>> of the
same input that does not call its own emulator HHH1(DDD).
mere intuition to the contrary is proven to be incorrect.
Right?If we prefix all programs we pass to HHH with DDD, they should >>>>>>>> not be
aborted as if the were the same.
If HHH were a correct simulator, it would produce the same
behaviour as
an UTM. (HHH1 is the same as HHH, right?)
All of the chatbots figure out that I am correct
on their own. I only give them this input:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) It detects a non-terminating behavior pattern then it aborts
its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement
then it returns 1.
These cache-boxes are fed with invalid and contradictory information:
(a) No non-termination pattern can be detected when it aborts and
return, because the simulated HHH is also programmed to abort and
return.
DDD correctly simulated by HHH cannot possibly reach its own
simulated "return" instruction final halt state in one to
infinity steps of correct simulation. This is a verified fact.
Your dreams are no verified facts. HHH aborts before the simulation
would reach the final halt state in a finite number of steps, as
proven by world-class simulators using exactly the same input. The
infinity is only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
On 7/29/2025 8:37 PM, Richard Damon wrote:
On 7/29/25 9:18 PM, olcott wrote:
On 7/29/2025 5:38 PM, Richard Damon wrote:
On 7/29/25 5:15 PM, olcott wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
Op 28.jul.2025 om 14:46 schreef olcott:
On 7/28/2025 3:43 AM, Fred. Zwarts wrote:As usual incorrect claims without evidence.
Op 26.jul.2025 om 20:46 schreef olcott:
On 7/26/2025 1:11 PM, joes wrote:
Am Sat, 26 Jul 2025 08:48:48 -0500 schrieb olcott:
On 7/26/2025 3:05 AM, joes wrote:Ok, so modifying HHH to simulate further also changes the
Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:
On 7/25/2025 2:10 PM, joes wrote:
Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
When HHH emulates DDD then DDD calls HHH(DDD) based onBut does DDD call whatever is behind the name "HHH" or does >>>>>>>>>>>> it call theOh, really now? I thought it referred to its simulator HHH >>>>>>>>>>>>>> by name.The actual code has always been based on an x86 emulator >>>>>>>>>>>>> that emulates
finite strings of x86 machine code bytes.
fixed code that aborts just before the second recursive >>>>>>>>>>>> call? Because
DDD calling a modified HHH' is a different program.
whatever code is
at machine address 000015d2.
input DDD,
because it calls the same address. Gotcha.
abort was correct.Since the execution trace conclusively proves that it is >>>>>>>>>>> correct yourFor three years everyone here acts like it is impossible >>>>>>>>>>>>> for them to
understand that the correct emulation of an input that >>>>>>>>>>>>> calls its own
emulator HHH(DDD) can possibly be different than the >>>>>>>>>>>>> emulation of the
same input that does not call its own emulator HHH1(DDD). >>>>>>>>>>>> It is not impossible to understand. It is wrong.
mere intuition to the contrary is proven to be incorrect. >>>>>>>>>> The trace only shows it is different. It remains to be shown >>>>>>>>>> that the
Right?If we prefix all programs we pass to HHH with DDD, they >>>>>>>>>>>> should not be
aborted as if the were the same.
If HHH were a correct simulator, it would produce the same >>>>>>>>>>>> behaviour as
an UTM. (HHH1 is the same as HHH, right?)
All of the chatbots figure out that I am correct
on their own. I only give them this input:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
DDD();
}
Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) It detects a non-terminating behavior pattern then it
aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return"
statement then it returns 1.
These cache-boxes are fed with invalid and contradictory
information:
(a) No non-termination pattern can be detected when it aborts
and return, because the simulated HHH is also programmed to
abort and return.
DDD correctly simulated by HHH cannot possibly reach its own
simulated "return" instruction final halt state in one to
infinity steps of correct simulation. This is a verified fact.
Your dreams are no verified facts. HHH aborts before the
simulation would reach the final halt state in a finite number of
steps, as proven by world-class simulators using exactly the same
input. The infinity is only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls
HHH(DDD)
And must CORRECTLY (amd completely) simulate that.
No you fucking liar a person can count to ten
without counting to infinity.
Sure, and you can simulate the first 4 instructions of DDD. But that
doesn't say you know or show what DDD will do.
It is the repeating sequence that cannot possibly
reach the "return" instruction final halt state of
DDD that is recognized in a finite number of steps.
I know that you are smart enough to see this so that
only leaves liar.
On 7/29/2025 8:40 PM, Richard Damon wrote:
On 7/29/25 7:52 PM, olcott wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <[email protected]> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>> would reach the final halt state in a finite number of steps, as
proven
by world-class simulators using exactly the same input. The
infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls
HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT >>>>> CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants, throwing
stones,
and all that.
It has never actually been established that I even
made one single material mistake in any of my claims.
Sure it has, you are just proven to be too stupid to understand it.
This ad hominem The way that damned liar forms a rebuttal.
If you were not a damned liar you would have brought up
a concrete example of a material mistake that I made.
Because you are a damned liar you know that no such
mistake exists.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 58:53:48 |
| Calls: | 12,117 |
| Files: | 15,010 |
| Messages: | 6,518,711 |