Simulating Termination Analyzer HHH correctly simulates its input
On 06/08/2025 19:34, olcott wrote:
Simulating Termination Analyzer HHH correctly simulates its input
No, it doesn't.
You posted your question in comp.lang.c, so I will post a C answer in comp.lang.c and honour your followup request by copying it to
comp.theory, but it is a C question belonging in a C group, so I have
set followups to comp.lang.c.
In C, HHH as defined cannot correctly simulate its input. You declare
HHH as taking a pointer to function returning void, but you attempt to
pass it a pointer to a function returning int.
If we gloss over that oversight, we run up against the problem that
while C allows you to call DD from HHH by using pointer-deferencing, it
does not offer you the access you seek to the machine code instructions
that make up the function's object code. A given implementation might
offer such access as an extension, but C does not impose upon any implementation any obligation to provide such access as you seek, and
your attempt to take advantage of it takes you firmly into the realm of undefined behaviour.
In short, your question is based on a misunderstanding of the C
language, and the only meaningful answer is that when you break the
rules of C, all bets are off.
<snip>
On 8/6/2025 1:57 PM, Richard Heathfield wrote:
On 06/08/2025 19:34, olcott wrote:
Simulating Termination Analyzer HHH correctly simulates its input
No, it doesn't.
If we gloss over that oversight, we run up against the problem
that while C allows you to call DD from HHH by using
pointer-deferencing, it does not offer you the access you seek
to the machine code instructions that make up the function's
object code. A given implementation might offer such access as
an extension, but C does not impose upon any implementation any
obligation to provide such access as you seek, and your attempt
to take advantage of it takes you firmly into the realm of
undefined behaviour.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
unsigned char *P;
__asm mov eax, DD
__asm mov P, eax
for (int N = 0; N < 35; N++)
printf("[%02d] %02x \n", N, (unsigned char) *(P+N));
}
Not standard C but it works on ever compiler
that enables embedded assembly language.
In short, your question is based on a misunderstanding of the C
language, and the only meaningful answer is that when you break
the rules of C, all bets are off.
<snip>
So that is just a limitation of C implementations
that does not actually negate the gist of my reasoning.
My x86utm operating system
Then on the basis of the correct emulation of HHH(DD)
It is a proven fact that HHH(DD) does correctly emulate
On 06/08/2025 21:40, olcott wrote:
On 8/6/2025 1:57 PM, Richard Heathfield wrote:
On 06/08/2025 19:34, olcott wrote:
Simulating Termination Analyzer HHH correctly simulates its input
No, it doesn't.
<snip>
If we gloss over that oversight, we run up against the problem that
while C allows you to call DD from HHH by using pointer-deferencing,
it does not offer you the access you seek to the machine code
instructions that make up the function's object code. A given
implementation might offer such access as an extension, but C does
not impose upon any implementation any obligation to provide such
access as you seek, and your attempt to take advantage of it takes
you firmly into the realm of undefined behaviour.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
unsigned char *P;
__asm mov eax, DD
You're no longer writing in the language defined by ISO. Whether it does what you want depends entirely on whether it does what you want. The
rules of C do not impose any requirements on this code.
__asm mov P, eax
for (int N = 0; N < 35; N++)
printf("[%02d] %02x \n", N, (unsigned char) *(P+N));
}
Not standard C but it works on ever compiler
that enables embedded assembly language.
By which I presume you mean the one or two you've tried it on.
Your question (subject line) is: "What value should HHH(DD) correctly return?"
And I have answered that question: "In C, HHH as defined cannot
correctly simulate its input."
If you are now changing the question to "does it work on the platforms
it works on?" it's no longer a question about the C language, so I
suggest you ask it in a newsgroup devoted to the platform you care about.
In short, your question is based on a misunderstanding of the C
language, and the only meaningful answer is that when you break the
rules of C, all bets are off.
<snip>
So that is just a limitation of C implementations
On the contrary! ISO C grants C implementations licence to implement any extension they wish. But it doesn't force all C implementations to
implement all the extensions offered by other C implementations. The
core C language and library are portable, but if you step outside the
core (as you have done) the language no longer defines what your program will do.
that does not actually negate the gist of my reasoning.
What negates the gist of your reasoning is that the behaviour of your
code is not defined by the rules of C.
What your code does on any given run can be determined by observation.
If it does the same thing on the next run, count yourself lucky.
My x86utm operating system
may be topical in an X86 newsgroup. This is not that group.
Then on the basis of the correct emulation of HHH(DD)
Stop right there.
In comp.lang.c we discuss C, not pipedreams. HHH cannot correctly
emulate anything passed to it as a function pointer. It can call the function, but that's all.
<pipedream snipped>
It is a proven fact that HHH(DD) does correctly emulate
That's not what the rules of C tell us.
You are confusing implementation extensions with the rules of C. They
are very different things.
On 8/6/2025 4:23 PM, Richard Heathfield wrote:
On 06/08/2025 21:40, olcott wrote:
It is a proven fact that HHH(DD) does correctly emulate
That's not what the rules of C tell us.
You are confusing implementation extensions with the rules of
C. They are very different things.
This does work in C/C++
On 06/08/2025 23:11, olcott wrote:
On 8/6/2025 4:23 PM, Richard Heathfield wrote:
On 06/08/2025 21:40, olcott wrote:
<snip>
It is a proven fact that HHH(DD) does correctly emulate
That's not what the rules of C tell us.
You are confusing implementation extensions with the rules of C. They
are very different things.
This does work in C/C++
No. You don't get to decide what those terms mean.
You have the correct answer to your question.
If you don't like the answer, that really is your problem. Asking the question again and posting your code again won't change the answer.
On 8/6/2025 5:21 PM, Richard Heathfield wrote:
You have the correct answer to your question.
If you don't like the answer, that really is your problem.
Asking the question again and posting your code again won't
change the answer.
If we assume away
that limitation of C and simply understand
that there is some complex infrastructure that does handle
that then my 22 years of work can be easily validated.
At least now with your help I do know that I must at least
reference this underlying infrastructure.
How valuable to computer science would it be to understand
that the conventional halting problem proofs do not actually
derive their undecidability conclusion?
On 06/08/2025 23:50, olcott wrote:
On 8/6/2025 5:21 PM, Richard Heathfield wrote:
<snip>
You have the correct answer to your question.
If you don't like the answer, that really is your problem. Asking the
question again and posting your code again won't change the answer.
If we assume away
But we don't.
that limitation of C and simply understand
that there is some complex infrastructure that does handle
that then my 22 years of work can be easily validated.
If you assume you're right, in your eyes you're right.
The rest of us are not as gullible.
At least now with your help I do know that I must at least
reference this underlying infrastructure.
It won't help with your goal, because your whole simulation thing is
just a blind alley.
How valuable to computer science would it be to understand
that the conventional halting problem proofs do not actually
derive their undecidability conclusion?
The conventional halting problem proof took a genius to figure out, but
it's really quite trivial. I don't know of any intelligent programmer
who struggles to understand why it's true.
On 06/08/2025 23:11, olcott wrote:
On 8/6/2025 4:23 PM, Richard Heathfield wrote:
On 06/08/2025 21:40, olcott wrote:
<snip>
It is a proven fact that HHH(DD) does correctly emulate
That's not what the rules of C tell us.
You are confusing implementation extensions with the rules of
C. They are very different things.
This does work in C/C++
No. You don't get to decide what those terms mean.
On 2025-08-06, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 06/08/2025 23:11, olcott wrote:
On 8/6/2025 4:23 PM, Richard Heathfield wrote:
On 06/08/2025 21:40, olcott wrote:
<snip>
It is a proven fact that HHH(DD) does correctly emulate
That's not what the rules of C tell us.
You are confusing implementation extensions with the rules of
C. They are very different things.
This does work in C/C++
No. You don't get to decide what those terms mean.
The main problem with Peter Olcott's reasoning is that he equivocates among multiple test cases as being one single program operating on one input.
There is a kind of Cantor diagonal argument at play in Halting in that
we have an infinite table with rows that are halting functions, and
columns that are test cases. Entries in the table indicate the halting
or not. Along the diagonal is where the trick test cases lie: procedures
that behave opposite to the halting verdict.
The undecidability of halting says that in every row of the table there
is a wrongly decided or non-halting column.
Peter doesn't understand this; he thinks that a halting decider that
has been deceived can see through the ruse, mutate itself and correctly decide---without that test case being identified as different row/column column of the table!
When Peter uses pronouns like "itself", "it" and whatnot, or even
explicit names like HH or whatever, those terms all equivocate among
multiple different entities in a way that suits the narrative at hand.
He is not able to grasp the concept that a symbol must name exactly one, immutable mathematical object, and that association must not change over
the course of a valid argument. If equivocation is perpetrated over
even a single symbol, the whole train of reasoning likely falls victim
to fallacy.
Peter is deeply committed to these errors of reasoning, and
that is why he doesn't get anywhere, and his debaters likewise.
Least effective is the strategy of debating the points that arise out of
the fallacious reasoning, and are several steps removed. When you do
that, you are accepting the bad premises, and the debate then takes
place on Peter's terms (or even if not in reality, in his mind it does).
Peter created (and I believe this) a simulation system based
on some off-the-shelf emulation code for the x86 architecture.
In this sytem he can have functions tracing the execution of other
functions at mulitiple nestings. He has used this system to "prove"
things to himself. I've never had access to his system to run it, but
from looking in detail at his execution traces, I found issues
such as gaps: pauses in the log where the instrucction pointer suddenly
jumps somewhere.
His approach encodes the fallacious reasoning;
for instance, he identifies a procedure to be decided for halting
only by its address in the x86 address space, even though halting is
a property of program/input pairs, not of programs. The code is
befuddled by impurity such as global variables.
Peter went to a considerable software development effort in order to translate his fallacious chains of reasoning into code, the idea being
that if something is represented in nicely executing, clever code,
its results must be speaking the truth, and it will be held in high
esteem by computer scientists as quality work who will accept the conclusions. Or something like that.
On 8/6/2025 6:13 PM, Richard Heathfield wrote:
On 06/08/2025 23:50, olcott wrote:
At least now with your help I do know that I must at least
reference this underlying infrastructure.
It won't help with your goal, because your whole simulation
thing is just a blind alley.
Unless you spend five minutes carefully studying
this single page of text.
https://philpapers.org/archive/OLCHPS.pdf
The conventional halting problem proof took a genius to figure
out, but it's really quite trivial. I don't know of any
intelligent programmer who struggles to understand why it's true.
*This is very difficult to understand*
On 07/08/2025 00:46, olcott wrote:
On 8/6/2025 6:13 PM, Richard Heathfield wrote:
On 06/08/2025 23:50, olcott wrote:
<snip>
At least now with your help I do know that I must at least
reference this underlying infrastructure.
It won't help with your goal, because your whole simulation thing is
just a blind alley.
Unless you spend five minutes carefully studying
this single page of text.
https://philpapers.org/archive/OLCHPS.pdf
It only took a second or two to see that your C is compromised the same
way there as in your OP.
The C answer to your C question stands - your C code is broken and rests
on a false premise. C doesn't work the way you want it to.
On 07/08/2025 00:46, olcott wrote:
On 8/6/2025 6:13 PM, Richard Heathfield wrote:
On 06/08/2025 23:50, olcott wrote:
<snip>
At least now with your help I do know that I must at least
reference this underlying infrastructure.
It won't help with your goal, because your whole simulation thing is
just a blind alley.
Unless you spend five minutes carefully studying
this single page of text.
https://philpapers.org/archive/OLCHPS.pdf
It only took a second or two to see that your C is compromised the same
way there as in your OP.
The C answer to your C question stands - your C code is broken and rests
on a false premise. C doesn't work the way you want it to.
Given that HHH can recursively simulate an instance of itself
simulating an instance of DD: What value should HHH(DD) correctly
return?
On 8/6/2025 10:35 PM, Richard Heathfield wrote:
The C answer to your C question stands - your C code is broken
and rests on a false premise. C doesn't work the way you want
it to.
The infrastructure that enables one C function to simulate
another C function in debugstep mode is provided by the
x86utm operating system.
Given that HHH can recursively
simulate an instance of itself
What value should HHH(DD) correctly return?
Am 06.08.2025 um 20:34 schrieb olcott:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
*Same analysis as a one page PDF*
https://www.researchgate.net/
publication/394345150_Halting_Problem_Simulation_Paradox
*Same analysis by ChatGPT*
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
*Same analysis by Grok*
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
Your question is neither C, nor C++-specific but fits with
any language. It also doesn't match with comp.ai.philosophy.
So go back to comp.theory.
How valuable to computer science would it be to understand
that the conventional halting problem proofs do not actually
derive their undecidability conclusion?
On 06/08/2025 23:50, olcott wrote:
...
How valuable to computer science would it be to understand
that the conventional halting problem proofs do not actually
derive their undecidability conclusion?
Understanding a falsehood to be true would have a very large negative
value. The validity of the proof of the halting problem isn't hard for
most mathematically minded people to understand - the hard part was
coming up with it.
On 07/08/2025 00:46, olcott wrote:[...]
*This is very difficult to understand*
No, it really isn't. You're just wrong and your C sucks.
On 8/7/2025 2:14 PM, James Kuyper wrote:
On 06/08/2025 23:50, olcott wrote:
...
How valuable to computer science would it be to understand
that the conventional halting problem proofs do not actually
derive their undecidability conclusion?
Understanding a falsehood to be true would have a very large
negative
value. The validity of the proof of the halting problem isn't
hard for
most mathematically minded people to understand - the hard part
was
coming up with it.
Unless you want to understand the notion of the
recursive simulation non-halting behavior pattern
please do not reply.
On 07/08/2025 20:35, olcott wrote:
On 8/7/2025 2:14 PM, James Kuyper wrote:
On 06/08/2025 23:50, olcott wrote:
...
How valuable to computer science would it be to understand
that the conventional halting problem proofs do not actually
derive their undecidability conclusion?
Understanding a falsehood to be true would have a very large negative
value. The validity of the proof of the halting problem isn't hard for
most mathematically minded people to understand - the hard part was
coming up with it.
Unless you want to understand the notion of the
recursive simulation non-halting behavior pattern
please do not reply.
The recursive nature of your code is irrelevant because it is only when
it has all unwound and HHH has returned for the last time that DD makes
its decision.
HHH *cannot* report on the outermost DD call because the
outermost DD's termination status cannot be determined until the
outermost HHH's return value is known.
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
The recursive nature of your code is irrelevant because it is
only when it has all unwound and HHH has returned for the last
time that DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
the
separate process context DD stack is no longer accessible.
HHH *cannot* report on the outermost DD call because the
outermost DD's termination status cannot be determined until
the outermost HHH's return value is known.
Counter-factual
Three different LLM AI systems figured this all out on
their own as soon as they were given this notion of a
simulating termination analyzer:
For instance, if you ask for code, you can tell that it
doesn't work.
On 2025-08-07, olcott <polcott333@gmail.com> wrote:
Three different LLM AI systems figured this all out on
their own as soon as they were given this notion of a
simulating termination analyzer:
Please, just stop the LLM stuff.
Or at least explore it in areas where you are sure you have iron-clad knowledge (i.e. anything but halting).
LLMs are just "Eliza on steroids" token predictors that predict
tokens based o large volumes of training texts, and effectively
interpolate among the data.
The commercial models are programmed to be sycophantic to the end users
in order to promote the popularity of AI.
Crackpots all over the world are using AI to validate their
cockamamie theories, since humans refuse.
Language models often spew outright incorrect statements
("hallucinations"); you have to be knowledgable in the area you are conversing about in order to spot the falsehoods, or otherwise check the output. For instance, if you ask for code, you can tell that it
doesn't work.
Quite recently, LLM AI insisted me that a certain configuration change
in Windows was /not/ responsible for the issue I was trying to
investigate, and tried to persuade me that leaving the configuration
as-is was necessary for getting things working. In fact, it /was/
that configuration; I flipped it, rebooted, and the problem was fixed.
Currently breaking story: "After using ChatGPT, man swaps his salt for
sodium bromide?and suffers psychosis"
https://arstechnica.com/health/2025/08/after-using-chatgpt-man-swaps-his-salt-for-sodium-bromide-and-suffers-psychosis/
Older: "ChatGPT Made My Husband Think He's God"
https://medium.com/write-a-catalyst/chatgpt-made-my-husband-think-hes-god-the-ai-apocalypse-destroying-american-families-5f33e4d04a51
On 8/7/2025 5:59 PM, Kaz Kylheku wrote:
On 2025-08-07, olcott <polcott333@gmail.com> wrote:
Three different LLM AI systems figured this all out on
their own as soon as they were given this notion of a
simulating termination analyzer:
Please, just stop the LLM stuff.
Or at least explore it in areas where you are sure you have
iron-clad
knowledge (i.e. anything but halting).
LLMs are just "Eliza on steroids" token predictors that predict
tokens based o large volumes of training texts, and effectively
interpolate among the data.
The commercial models are programmed to be sycophantic to the
end users
in order to promote the popularity of AI.
Crackpots all over the world are using AI to validate their
cockamamie theories, since humans refuse.
Language models often spew outright incorrect statements
("hallucinations"); you have to be knowledgable in the area you
are
conversing about in order to spot the falsehoods, or otherwise
check the
output. For instance, if you ask for code, you can tell that it
doesn't work.
Quite recently, LLM AI insisted me that a certain configuration
change
in Windows was /not/ responsible for the issue I was trying to
investigate, and tried to persuade me that leaving the
configuration
as-is was necessary for getting things working. In fact, it /was/
that configuration; I flipped it, rebooted, and the problem was
fixed.
Currently breaking story: "After using ChatGPT, man swaps his
salt for
sodium bromide?and suffers psychosis"
https://arstechnica.com/health/2025/08/after-using-chatgpt-man-swaps-his-salt-for-sodium-bromide-and-suffers-psychosis/
Older: "ChatGPT Made My Husband Think He's God"
https://medium.com/write-a-catalyst/chatgpt-made-my-husband-think-hes-god-the-ai-apocalypse-destroying-american-families-5f33e4d04a51
None-the-less ALL three LLM systems were able to
correctly figure out the
*recursive simulation non-halting behavior pattern*
entirely on the basis of this definition:
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
On 07/08/2025 21:54, olcott wrote:
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
<snip>
The recursive nature of your code is irrelevant because it is only
when it has all unwound and HHH has returned for the last time that
DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
May I remind you that in comp.lang.c HHH can't even begin its simulation because it has no legal way to get at DD's instructions.
the
separate process context DD stack is no longer accessible.
That's nothing to do with C.
What C can tell us is that (however it obtains its result) if HHH
reports "DD halts" DD loops, and if HHH reports "DD loops" DD halts. So
no matter how HHH does its work it gets the answer wrong.
HHH *cannot* report on the outermost DD call because the outermost
DD's termination status cannot be determined until the outermost
HHH's return value is known.
Counter-factual
No, sir. Self-evident.
On 8/7/2025 5:06 PM, Richard Heathfield wrote:
On 07/08/2025 21:54, olcott wrote:
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
<snip>
The recursive nature of your code is irrelevant because it is
only when it has all unwound and HHH has returned for the
last time that DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
May I remind you that in comp.lang.c HHH can't even begin its
simulation because it has no legal way to get at DD's
instructions.
Yes of course we all know that it is completely
impossible for any C program to read binary files
such as the COFF object file named Halt7.obj.
the
separate process context DD stack is no longer accessible.
That's nothing to do with C.
What C can tell us is that (however it obtains its result) if
HHH reports "DD halts" DD loops, and if HHH reports "DD loops"
DD halts. So no matter how HHH does its work it gets the answer
wrong.
I will keep insisting that you understand this
otherwise you are cheating.
*recursive simulation non-halting behavior pattern*
Giving a review of a work without looking at the work
is dishonest.
On 08/08/2025 00:32, olcott wrote:
On 8/7/2025 5:06 PM, Richard Heathfield wrote:
On 07/08/2025 21:54, olcott wrote:
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
<snip>
The recursive nature of your code is irrelevant because it is only
when it has all unwound and HHH has returned for the last time that >>>>> DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
May I remind you that in comp.lang.c HHH can't even begin its
simulation because it has no legal way to get at DD's instructions.
Yes of course we all know that it is completely
impossible for any C program to read binary files
such as the COFF object file named Halt7.obj.
Clearly not, but HHH doesn't do that. Are you planning a new version of
HHH that uses fopen and fread to access the object file? That would certainly be possible to do in C, but that isn't how HHH works, so it's
a blind alley.
the
separate process context DD stack is no longer accessible.
That's nothing to do with C.
What C can tell us is that (however it obtains its result) if HHH
reports "DD halts" DD loops, and if HHH reports "DD loops" DD halts.
So no matter how HHH does its work it gets the answer wrong.
I will keep insisting that you understand this
otherwise you are cheating.
Cheating? It's not a game. It's logic.
*recursive simulation non-halting behavior pattern*
Giving a review of a work without looking at the work
is dishonest.
The opinion I gave was on your DD function, the code for which you
posted, and which I used to explain why your conclusion is false.
If you don't want to be told why your code doesn't prove what you think
it proves, don't post it.
On 07/08/2025 23:59, Kaz Kylheku wrote:
For instance, if you ask for code, you can tell that it
doesn't work.
...or it does.
Perfect it isn't, but it's impressive even so.
You have to be firm, and you have to be clear about what you want, but
it's surprisingly adept at turning intentions into working code.
On the other hand, it fails disappointingly often to count the number of letters in a word.
Let's see how it copes with olcott's code:
I am testing the assumption that simulating termination analyzer HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
What does that tell me about my assumption? --------------------------------------------
Alright — let’s unpack your test case step-by-step.
1. Restating your setup
You have:
typedef int (*ptr)();
int HHH(ptr P); // Halting analyser simulator: returns 0 if detects nontermination, 1 if detects return
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Your rules for HHH:
Return 0 → You’ve detected that P() will run forever.
Return 1 → You’ve simulated P() to the point it would return.
2. Tracing what happens if HHH works per your assumption
Let’s pretend HHH(DD) really does what you hope — simulate exactly until it sees one of your stopping conditions.
Case A: HHH(DD) returns 1
In DD():
if (Halt_Status) // 1 means true
HERE: goto HERE; // infinite loop
So if HHH predicts “halts”, the actual execution of DD will loop forever.
That means HHH’s prediction was wrong — it said “halts”, but it
doesn’t.
Case B: HHH(DD) returns 0
Then:
if (0) // false
HERE: goto HERE;
return 0;
So if HHH predicts “loops forever”, DD() actually terminates (returns 0 immediately).
Again, prediction is wrong — it said “nonterminates”, but it halts.
3. The paradox
In both cases, whatever HHH returns is falsified by the actual behaviour
of DD():
HHH(DD) says... Actual behaviour of DD()
1 (halts) loops forever
0 (loops) halts
This is basically a diagonalisation: DD is constructed to do the
opposite of what HHH predicts about it. --------------------------------------------
Full marks to ChatGPT.
On 08/08/2025 00:32, olcott wrote:
On 8/7/2025 5:06 PM, Richard Heathfield wrote:
On 07/08/2025 21:54, olcott wrote:
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
<snip>
The recursive nature of your code is irrelevant because it is only
when it has all unwound and HHH has returned for the last time that >>>>> DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
May I remind you that in comp.lang.c HHH can't even begin its
simulation because it has no legal way to get at DD's instructions.
Yes of course we all know that it is completely
impossible for any C program to read binary files
such as the COFF object file named Halt7.obj.
Clearly not, but HHH doesn't do that. Are you planning a new version of
HHH that uses fopen and fread to access the object file? That would certainly be possible to do in C, but that isn't how HHH works, so it's
a blind alley.
the
separate process context DD stack is no longer accessible.
That's nothing to do with C.
What C can tell us is that (however it obtains its result) if HHH
reports "DD halts" DD loops, and if HHH reports "DD loops" DD halts.
So no matter how HHH does its work it gets the answer wrong.
I will keep insisting that you understand this
otherwise you are cheating.
Cheating? It's not a game. It's logic.
*recursive simulation non-halting behavior pattern*
Giving a review of a work without looking at the work
is dishonest.
The opinion I gave was on your DD function, the code for which you
posted, and which I used to explain why your conclusion is false.
If you don't want to be told why your code doesn't prove what you think
it proves, don't post it.
On 8/7/2025 6:44 PM, Richard Heathfield wrote:
On 08/08/2025 00:32, olcott wrote:
On 8/7/2025 5:06 PM, Richard Heathfield wrote:
On 07/08/2025 21:54, olcott wrote:
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
<snip>
The recursive nature of your code is irrelevant because it is only >>>>>> when it has all unwound and HHH has returned for the last time
that DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
May I remind you that in comp.lang.c HHH can't even begin its
simulation because it has no legal way to get at DD's instructions.
Yes of course we all know that it is completely
impossible for any C program to read binary files
such as the COFF object file named Halt7.obj.
Clearly not, but HHH doesn't do that. Are you planning a new version
of HHH that uses fopen and fread to access the object file? That would
certainly be possible to do in C, but that isn't how HHH works, so
it's a blind alley.
https://github.com/plolcott/x86utm/blob/master/include/Read_COFF_Object.h
the
separate process context DD stack is no longer accessible.
That's nothing to do with C.
What C can tell us is that (however it obtains its result) if HHH
reports "DD halts" DD loops, and if HHH reports "DD loops" DD halts.
So no matter how HHH does its work it gets the answer wrong.
I will keep insisting that you understand this
otherwise you are cheating.
Cheating? It's not a game. It's logic.
*recursive simulation non-halting behavior pattern*
Giving a review of a work without looking at the work
is dishonest.
The opinion I gave was on your DD function, the code for which you
posted, and which I used to explain why your conclusion is false.
If you don't want to be told why your code doesn't prove what you
think it proves, don't post it.
recursive simulation non-halting behavior pattern
recursive simulation non-halting behavior pattern
recursive simulation non-halting behavior pattern
Full marks to ChatGPT.
*ChatGPT 5.0 had to be reminded*
On 8/7/2025 6:27 PM, Richard Heathfield wrote:^^^^^^^^^^^^^^^^^^^^^^^^^
Let's see how [ChatGPT] copes with olcott's code:
I am testing the assumption that simulating termination
analyzer HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
Yet the real DD() is not an input to HHH
*Then it completely validates my whole proof*
Clearly not, but HHH doesn't do that. Are you planning a new
version of HHH that uses fopen and fread to access the object
file? That would certainly be possible to do in C, but that isn't
how HHH works, so it's a blind alley.
On 8/7/2025 6:44 PM, Richard Heathfield wrote:
On 08/08/2025 00:32, olcott wrote:
On 8/7/2025 5:06 PM, Richard Heathfield wrote:
On 07/08/2025 21:54, olcott wrote:
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
<snip>
The recursive nature of your code is irrelevant because it
is only when it has all unwound and HHH has returned for
the last time that DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
May I remind you that in comp.lang.c HHH can't even begin its
simulation because it has no legal way to get at DD's
instructions.
Yes of course we all know that it is completely
impossible for any C program to read binary files
such as the COFF object file named Halt7.obj.
Clearly not, but HHH doesn't do that. Are you planning a new
version of HHH that uses fopen and fread to access the object
file? That would certainly be possible to do in C, but that
isn't how HHH works, so it's a blind alley.
https://github.com/plolcott/x86utm/blob/master/include/Read_COFF_Object.h
The opinion I gave was on your DD function, the code for which
you posted, and which I used to explain why your conclusion is
false.
If you don't want to be told why your code doesn't prove what
you think it proves, don't post it.
recursive simulation non-halting behavior pattern
Would DD correctly simulated by HHH reach its own simulated
"return" statement final halt state?
At that point I realized that Peter's conviction is likely unbreakable.
On 08/08/2025 01:05, olcott wrote:
On 8/7/2025 6:27 PM, Richard Heathfield wrote:^^^^^^^^^^^^^^^^^^^^^^^^^
Let's see how [ChatGPT] copes with olcott's code:
I am testing the assumption that simulating termination analyzer HHH
correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
<snip>
Yet the real DD() is not an input to HHH
Yeah it is. See quoted code.
<snip>
*Then it completely validates my whole proof*
You clearly skipped over the part where it said you were talking
complete bollocks:
So if HHH predicts “halts”, the actual execution of DD will loop forever. That means HHH’s prediction was wrong — it said “halts”, but it
doesn’t. So if HHH predicts “loops forever”, DD() actually terminates (returns 0 immediately). Again, prediction is wrong — it said “nonterminates”, but it halts. In both cases, whatever HHH returns is falsified by the actual behaviour of DD():
On 2025-08-07, Richard Heathfield <rjh@cpax.org.uk> wrote:
Clearly not, but HHH doesn't do that. Are you planning a new
version of HHH that uses fopen and fread to access the object
file? That would certainly be possible to do in C, but that isn't
how HHH works, so it's a blind alley.
A numbrer of years ago, Peter had a working system (according to
plausible evidence from detailed execution traces) consisting of a
modified x86 simulator, for which he compiled C code. It was able to do
the introspection and nested simulations you are hinting at.
The only problem is that he believed that to be proving things that it
wasn't proving.
I don't think he's given anyone the materials to run for themselves,
but I analyzed his execution traces in some detail.
If my memory serves me, he endowed the simulator (existing work
from someone else) with logic that tried to detect the looping
behavior of the halting test case (the code that tries to "behave
opposite" to the halting decision).
I'm afraid this line of discussion is blind alley in a different sense.
Peter Olcott "been there and done that" in terms of getting up to the
elbows in a CPU simulating tech stack and trying to make a synthetic CPU
that runs compiled C code and all that.
I remember that one of the issues with this solutions (as far as I
was able to guess from his execution traces) was that he hacked
the x86 simulator to detect, in the nested simulated situation,
when it was simulating its own code. And that was part of where
the reasonign went astray; he thought you can pull a ruse like that,
and still be proving something about halting.
What happens in the halting proof is that the rebellious program
that behaves opposite has access to a halting decision about itself,
and that requires it to /embed/ the halting decider. I.e. given
a halting we can build a program /around/ it which reacts to
its decision by infinitely looping when the decision says "halts",
or terminating when it says "doesn't halt".
Olcott's system, however, had built-in detection for when the
instruction pointer entered into the halting decider (I think simply by comparing the addresses), and it pulled some invalid shennanigans there, gaming the control flow. I remember seeing impossible events in the instruction-by-instruction execution traces, like the instruction
pointer jumping somwhere without having executed a branch.
It is all actually admirable hacking effort, but for the muddled
thinking and wrong conclusions.
At that point I realized that Peter's conviction is likely unbreakable.
Or, if there is a way, it has to be via the fundamentals. Getting him to accept the diagnonalizaton argument, and the concepts of pure functions
and all the rest of it.
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
On 08/08/2025 01:11, olcott wrote:
On 8/7/2025 6:44 PM, Richard Heathfield wrote:
On 08/08/2025 00:32, olcott wrote:
On 8/7/2025 5:06 PM, Richard Heathfield wrote:
On 07/08/2025 21:54, olcott wrote:
On 8/7/2025 3:19 PM, Richard Heathfield wrote:
<snip>
The recursive nature of your code is irrelevant because it is
only when it has all unwound and HHH has returned for the last
time that DD makes its decision.
Incorrect. When HHH(DD) aborts its simulation
May I remind you that in comp.lang.c HHH can't even begin its
simulation because it has no legal way to get at DD's instructions.
Yes of course we all know that it is completely
impossible for any C program to read binary files
such as the COFF object file named Halt7.obj.
Clearly not, but HHH doesn't do that. Are you planning a new version
of HHH that uses fopen and fread to access the object file? That
would certainly be possible to do in C, but that isn't how HHH works,
so it's a blind alley.
https://github.com/plolcott/x86utm/blob/master/include/Read_COFF_Object.h
That isn't the HHH code, and it isn't how HHH works, so it's a blind alley.
The opinion I gave was on your DD function, the code for which you
posted, and which I used to explain why your conclusion is false.
If you don't want to be told why your code doesn't prove what you
think it proves, don't post it.
recursive simulation non-halting behavior pattern
...is irrelevant to the question of whether HHH does what you imagine it does. Tis tis tis tis tis does not constitute a proof.
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
(This pathological thread, revived and re-triggered by the unwary,
now lasts for years without any new insights; it's just pointless reiterations.)
No party will convince the other; this is quite obvious since long.
I think *this* is the relevant "key insight". - Act accordingly![*]
Janis
[*] Just a suggestion [for folks who try to avoid useless frays].
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
On 8/8/2025 12:51 AM, Richard Heathfield wrote:
On 08/08/2025 01:05, olcott wrote:
On 8/7/2025 6:27 PM, Richard Heathfield wrote:^^^^^^^^^^^^^^^^^^^^^^^^^
Let's see how [ChatGPT] copes with olcott's code:
I am testing the assumption that simulating termination
analyzer HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
<snip>
Yet the real DD() is not an input to HHH
Yeah it is. See quoted code.
<snip>
*Then it completely validates my whole proof*
You clearly skipped over the part where it said you were
talking complete bollocks:
So if HHH predicts “halts”, the actual execution of DD will
loop forever. That means HHH’s prediction was wrong — it said
“halts”, but it doesn’t. So if HHH predicts “loops forever”,
DD() actually terminates (returns 0 immediately). Again,
prediction is wrong — it said “nonterminates”, but it halts. In
both cases, whatever HHH returns is falsified by the actual
behaviour of DD():
*You have to examine its final analysis*
https://chatgpt.com/share/68953d9e-6efc-8011-b266-502025818430
Its final analysis agrees with my whole proof.
On 8/8/2025 12:59 AM, Kaz Kylheku wrote:
DD correctly simulated by HHH cannot possibly reach
the "do the opposite" code because it remains stuck
in recursive simulation.
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
On 08/08/2025 14:29, olcott wrote:
On 8/8/2025 12:51 AM, Richard Heathfield wrote:
On 08/08/2025 01:05, olcott wrote:
On 8/7/2025 6:27 PM, Richard Heathfield wrote:^^^^^^^^^^^^^^^^^^^^^^^^^
Let's see how [ChatGPT] copes with olcott's code:
I am testing the assumption that simulating termination analyzer
HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
<snip>
Yet the real DD() is not an input to HHH
Yeah it is. See quoted code.
<snip>
*Then it completely validates my whole proof*
You clearly skipped over the part where it said you were talking
complete bollocks:
So if HHH predicts “halts”, the actual execution of DD will loop
forever. That means HHH’s prediction was wrong — it said “halts”, but
it doesn’t. So if HHH predicts “loops forever”, DD() actually
terminates (returns 0 immediately). Again, prediction is wrong — it
said “nonterminates”, but it halts. In both cases, whatever HHH
returns is falsified by the actual behaviour of DD():
*You have to examine its final analysis*
In the transcript I posted, I posted the whole thing. The whole thing
said bollocks.
https://chatgpt.com/share/68953d9e-6efc-8011-b266-502025818430
Its final analysis agrees with my whole proof.
So we now know that it will cheerfully take either side of the debate, depending on how you prime it. You therefore cannot reasonably point to
it as supporting your side and *only* your side.
<snip>
On 08/08/2025 15:09, olcott wrote:
On 8/8/2025 12:59 AM, Kaz Kylheku wrote:
<snip>
DD correctly simulated by HHH cannot possibly reach
the "do the opposite" code because it remains stuck
in recursive simulation.
So what you're saying is that HHH cannot correctly simulate DD.
<snip>
It is a verified fact that DD correctly simulated by HHH
cannot possibly reach its own simulated "return" statement
final halt state.
It is a verified fact that HHH(DD) correctly detects this.
I am attesting to the fact that Claude AI did correctly
determine why HHH(DD)==0 is correct.
When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:
Then it can be directly seen that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state.
On 08/08/2025 17:35, olcott wrote:
When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:
And when I tell it (neutrally) to check that assumption, it says the assumption is bollocks... which it is.
On 08/08/2025 15:27, olcott wrote:
<snip>
It is a verified fact that DD correctly simulated by HHH
cannot possibly reach its own simulated "return" statement
final halt state.
Then it's not a correct simulation.
It is a verified fact that HHH(DD) correctly detects this.
I am attesting to the fact that Claude AI did correctly
determine why HHH(DD)==0 is correct.
If that's correct, HHH's judgement is that DD doesn't halt. Having
received that report from HHH, DD promptly halts, invalidating HHH's judgement, so it's not correct after all. HHH fails in its mission as a
halt decider.
On 08/08/2025 17:40, olcott wrote:
Then it can be directly seen that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state.
And therefore you have derived a contradiction which demonstrates that
your reasoning contains a false assumption, namely that DD is correctly simulated by HHH.
QED.
On 2025-08-07, Richard Heathfield <rjh@cpax.org.uk> wrote:
Clearly not, but HHH doesn't do that. Are you planning a new
version of HHH that uses fopen and fread to access the object
file? That would certainly be possible to do in C, but that isn't
how HHH works, so it's a blind alley.
A numbrer of years ago, Peter had a working system (according to
plausible evidence from detailed execution traces) consisting of a
modified x86 simulator, for which he compiled C code. It was able to do
the introspection and nested simulations you are hinting at.
The only problem is that he believed that to be proving things that it
wasn't proving.
I don't think he's given anyone the materials to run for themselves,
but I analyzed his execution traces in some detail.
If my memory serves me, he endowed the simulator (existing work
from someone else) with logic that tried to detect the looping
behavior of the halting test case (the code that tries to "behave
opposite" to the halting decision).
I'm afraid this line of discussion is blind alley in a different sense.
Peter Olcott "been there and done that" in terms of getting up to the
elbows in a CPU simulating tech stack and trying to make a synthetic CPU
that runs compiled C code and all that.
I remember that one of the issues with this solutions (as far as I
was able to guess from his execution traces) was that he hacked
the x86 simulator to detect, in the nested simulated situation,
when it was simulating its own code. And that was part of where
the reasonign went astray; he thought you can pull a ruse like that,
and still be proving something about halting.
What happens in the halting proof is that the rebellious program
that behaves opposite has access to a halting decision about itself,
and that requires it to /embed/ the halting decider. I.e. given
a halting we can build a program /around/ it which reacts to
its decision by infinitely looping when the decision says "halts",
or terminating when it says "doesn't halt".
Olcott's system, however, had built-in detection for when the
instruction pointer entered into the halting decider (I think simply by comparing the addresses), and it pulled some invalid shennanigans there, gaming the control flow.
I remember seeing impossible events in the
instruction-by-instruction execution traces, like the instruction
pointer jumping somwhere without having executed a branch.
It is all actually admirable hacking effort, but for the muddled
thinking and wrong conclusions.
At that point I realized that Peter's conviction is likely unbreakable.
Or, if there is a way, it has to be via the fundamentals. Getting him to accept the diagnonalizaton argument, and the concepts of pure functions
and all the rest of it.
On 8/8/2025 1:26 PM, Richard Heathfield wrote:
On 08/08/2025 17:35, olcott wrote:
When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:
And when I tell it (neutrally) to check that assumption, it says the
assumption is bollocks... which it is.
Until you tell it to examine the behavior of DD
correctly simulated by HHH as the only basis for
a correct return value.
On 8/8/2025 1:26 PM, Richard Heathfield wrote:
On 08/08/2025 17:35, olcott wrote:
When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:
And when I tell it (neutrally) to check that assumption, it
says the assumption is bollocks... which it is.
Until you tell it to examine the behavior of DD
correctly simulated by HHH as the only basis for
a correct return value.
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
On 8/8/2025 1:29 PM, Richard Heathfield wrote:
On 08/08/2025 17:40, olcott wrote:
Then it can be directly seen that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state.
And therefore you have derived a contradiction which
demonstrates that your reasoning contains a false assumption,
namely that DD is correctly simulated by HHH.
QED.
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
It is flatly incorrect to disagree with the semantics
of the x86 language.
On 08/08/2025 06:59, Kaz Kylheku wrote:
On 2025-08-07, Richard Heathfield <rjh@cpax.org.uk> wrote:
Clearly not, but HHH doesn't do that. Are you planning a new
version of HHH that uses fopen and fread to access the object
file? That would certainly be possible to do in C, but that isn't
how HHH works, so it's a blind alley.
A numbrer of years ago, Peter had a working system (according to
plausible evidence from detailed execution traces) consisting of a
modified x86 simulator, for which he compiled C code. It was able to do
the introspection and nested simulations you are hinting at.
The only problem is that he believed that to be proving things that it
wasn't proving.
I don't think he's given anyone the materials to run for themselves,
but I analyzed his execution traces in some detail.
From time to time he publishes a link to all the source code. I think
he posted a link today? It's easy enough to compile if you're using MSVC
(on Windows). It shouldn't be hard to port to other environments, but I guess that assumes the programmer already understands the code - PO
doesn't explain anything much. So in practice you'd need to play using
the MSVC toolset to get the basic understanding before starting any
port! [ok, so it won't be so easy...]
If my memory serves me, he endowed the simulator (existing work
from someone else) with logic that tried to detect the looping
behavior of the halting test case (the code that tries to "behave
opposite" to the halting decision).
I'm afraid this line of discussion is blind alley in a different sense.
Peter Olcott "been there and done that" in terms of getting up to the
elbows in a CPU simulating tech stack and trying to make a synthetic CPU
that runs compiled C code and all that.
I remember that one of the issues with this solutions (as far as I
was able to guess from his execution traces) was that he hacked
the x86 simulator to detect, in the nested simulated situation,
when it was simulating its own code. And that was part of where
the reasonign went astray; he thought you can pull a ruse like that,
and still be proving something about halting.
Yes, there are a couple of problems here:
- PO uses global variables to communicate across all emulation levels
[his global trace table], and for emulated code to recognise when it is being emulated and behave differently [his Root variable]. This is obviously a No-No.
- PO has coded a decider H which recognised the emulated computation calling H by comparing the emulated call with its own address.
The first problem breaks the design for his "emulation", since emulated
code by definition MUST match the behaviour of the code being emulated.
This problem could be fixed, but not by PO who can't work out how to fix it. He says he doesn't have a thousand years to make it work
"properly"! [It took me about an hour to fix in my play code, once I'd worked out what it was doing...]
- The second problem [using H's own code address] does present a sort
of puzzle for how this code relates to TMs, since TM states don't have "addresses" that they can access. OTOH this is not really the reason
PO's argument is nonsense, so I don't see this as a problem worth
focussing on. If PO's decider H actually contradicted anything in the
Linz proof, we might start looking for deeper reasons, but given it / doesn't/, arging about fiddly technical details is not worth the bother
IMO.
Note PO has a different decider implementation HHH which does not use
its own address, instead watching for repeated addresses within nested emulations.
What happens in the halting proof is that the rebellious program
that behaves opposite has access to a halting decision about itself,
and that requires it to /embed/ the halting decider. I.e. given
a halting we can build a program /around/ it which reacts to
its decision by infinitely looping when the decision says "halts",
or terminating when it says "doesn't halt".
Olcott's system, however, had built-in detection for when the
instruction pointer entered into the halting decider (I think simply by
comparing the addresses), and it pulled some invalid shennanigans there,
gaming the control flow.
Probably that's the H code address problem (see above). Being
charitable to PO, that's not what leads to his incorrect conclusions
(see below).
I remember seeing impossible events in the
instruction-by-instruction execution traces, like the instruction
pointer jumping somwhere without having executed a branch.
That could be a red herring. PO filters the trace output he presents to only show instructions within DDD() function [the test program input
that decider is analysing], not within the (logically) embedded decider HHH. So when DDD() calls HHH it /looks/ like the IP has jumped not to
HHH, but to DDD, but that is not really the case -
more that PO doesn't
bother to explain what is actually happening because he claims that just confuses people!
[Yeah right - pretty much every poster who comes along
is confused by why the instruction has jumped to DDD when it should have gone to HHH, but PO doesn't count that as confusing people, lol.] And
of course, the filtering /is/ a problem if you reasonably expect to
trace through and inspect all the code (HHH/DDD/+subroutines) to satisfy your concerns.
It is all actually admirable hacking effort, but for the muddled
thinking and wrong conclusions.
Right. The Linz proof shows that if DDD is constructed by wrapping
decider HHH as you've described, and if HHH decides DDD never halts
[like PO's HHH], then in fact DDD must halt [contradiction! so HHH isn't
in fact a halt decider].
So... after PO's years of work creating his
x86utm.exe (runtime environment) and HHH/DDD (halt decider/input code)
what was the result? His HHH decides DDD never halts, and in fact DDD
is quickly demonstrated to actually halt, along with all the traces
backing up these observations. Ie. EXACTLY IN LINE WITH LINZ proof.
Lol, 2 years development work totally wasted... Everyone would have happily agreed in advance that this is the expected behaviour for the
code, provided there was no "cheating" tricks, so developing a
complicated program to "prove" that achieved nothing.
At that point I realized that Peter's conviction is likely unbreakable.
Or, if there is a way, it has to be via the fundamentals. Getting him to
accept the diagnonalizaton argument, and the concepts of pure functions
and all the rest of it.
I'm afraid I think concentrating on concepts is a hopeless approach,
because PO simply /can't/ do any of that, which I put down to
alternative brain wiring: PO's brain is unable to handle abstract
concepts and logical reasoning in the way other people can effortlessly.
On 8/8/2025 12:24 PM, olcott wrote:
On 8/8/2025 1:26 PM, Richard Heathfield wrote:
On 08/08/2025 17:35, olcott wrote:
When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:
And when I tell it (neutrally) to check that assumption, it says the
assumption is bollocks... which it is.
Until you tell it to examine the behavior of DD
correctly simulated by HHH as the only basis for
a correct return value.
Are you trying to force the AI to be a moron?
On 08/08/2025 20:24, olcott wrote:
On 8/8/2025 1:26 PM, Richard Heathfield wrote:
On 08/08/2025 17:35, olcott wrote:
When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:
And when I tell it (neutrally) to check that assumption, it says the
assumption is bollocks... which it is.
Until you tell it to examine the behavior of DD
correctly simulated by HHH as the only basis for
a correct return value.
As we have already established,
HHH cannot correctly simulate DD
sufficiently well to establish its return value. The assumption that it
can is flawed, and your failure to realise this is what has cost you 22 years of bickering.
On 08/08/2025 20:29, olcott wrote:
<snip>
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
How HHH reaches its decision about whether DD halts is irrelevant. What matters is that it reaches a decision that is guaranteed to be wrong.
DD emulated by HHH according to the semantics
of the x86 language cannot possibly reach its
own "ret" instruction final halt state.
On 08/08/2025 20:35, olcott wrote:
On 8/8/2025 1:29 PM, Richard Heathfield wrote:
On 08/08/2025 17:40, olcott wrote:
Then it can be directly seen that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state.
And therefore you have derived a contradiction which demonstrates
that your reasoning contains a false assumption, namely that DD is
correctly simulated by HHH.
QED.
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
How HHH decides is of no consequence. All that matters is /what/ it
decides, because what it decides is wrong.
It is flatly incorrect to disagree with the semantics
of the x86 language.
It is flatly incorrect to think that the semantics of x86 machine code matter a damn. For all I care HHH could get its answer by waving a wand
and saying abracadabra. It's still the wrong answer.
On 08/08/2025 23:17, olcott wrote:
DD emulated by HHH according to the semantics
of the x86 language cannot possibly reach its
own "ret" instruction final halt state.
Let's accept that for a moment, and see where it leads us.
You seem to be saying that HHH establishes that DD can't return.
HHH must therefore return 0 (false means it doesn't halt).
HHH assigns this to Halt_Status:
so... Halt_Status = 0;
if(Halt_Status)
On 8/8/2025 3:57 PM, Richard Heathfield wrote:
On 08/08/2025 20:29, olcott wrote:
<snip>
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
How HHH reaches its decision about whether DD halts is
irrelevant. What matters is that it reaches a decision that is
guaranteed to be wrong.
It only seems that way on the basis of a misconception.
You can't begin to understand that it is a misconception
until after you understand this:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 08/08/2025 23:22, olcott wrote:
On 8/8/2025 3:57 PM, Richard Heathfield wrote:
On 08/08/2025 20:29, olcott wrote:
<snip>
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
How HHH reaches its decision about whether DD halts is irrelevant.
What matters is that it reaches a decision that is guaranteed to be
wrong.
It only seems that way on the basis of a misconception.
The misconception is yours.
This is not a mystical cloud of unknowing; it's simple logic.
You can't begin to understand that it is a misconception
It isn't a misconception.
until after you understand this:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Complete bollocks from the AI:
"This is a classic example of a halting problem scenario where the
analyzer correctly identifies that the input represents non-terminating behavior, even though the actual execution might terminate"
It can't bear to disappoint you, so it finds some wording that will
placate you, but it's self-contradictory nonsense.
How is it self-contradictory? Well, let's take "Answer: HHH(DD) should correctly return 0." like the AI says.
HHH returns 0, so in DD the if()_fails, and DD returns after all.
HHH got it wrong.
Which is exactly what you'd expect, because DD is designed to make HHH
fail.
On 8/8/2025 4:00 PM, Richard Heathfield wrote:
On 08/08/2025 20:35, olcott wrote:
On 8/8/2025 1:29 PM, Richard Heathfield wrote:
On 08/08/2025 17:40, olcott wrote:
Then it can be directly seen that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state.
And therefore you have derived a contradiction which
demonstrates that your reasoning contains a false assumption,
namely that DD is correctly simulated by HHH.
QED.
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
How HHH decides is of no consequence. All that matters is
/what/ it decides, because what it decides is wrong.
It is wrong to assume that any computable function
must report on the behavior of anything besides
the behavior that its actual input actually specifies.
DD emulated by HHH according to the semantics x86
language conclusively proves the behavior that the
input to HHH(DD) actually specifies.
It is flatly incorrect to disagree with the semantics
of the x86 language.
It is flatly incorrect to think that the semantics of x86
machine code matter a damn. For all I care HHH could get its
answer by waving a wand and saying abracadabra. It's still the
wrong answer.
Without the exactingly precise (state transition diagram)
degree of precision that the x86 language specifies we could
go around and around forever on the basis of incorrect measures
of correct simulation.
If you have the opinion that 3 > 5 then you are just wrong.
If you have the opinion about correct simulation
and there
is no absolute measure then there is no closure. The x86
language is *the absolute measure of correct simulation*
On 8/8/2025 5:31 PM, Richard Heathfield wrote:
if(Halt_Status)
*is unreachable from DD correctly simulated by HHH*
You must carefully study the whole page until
you have 100% complete understanding of the
*recursive simulation non-halting behavior pattern*
DD correctly simulated by HHH never reaches the "if".
HHH got it wrong.
Which is exactly what you'd expect, because DD is designed to
make HHH fail.
Termination analyzers in general are only accountable
for the actual behavior that their input actually specifies.
HHH(DD)==0 is correct on the basis of the behavior that
the actual input actually specifies.
That computer scientists did not notice this for 89 years
is not my mistake.
On 08/08/2025 23:31, olcott wrote:[...]
Richard Heathfield <rjh@cpax.org.uk> writes:
On 08/08/2025 23:31, olcott wrote:[...]
I observe that comp.lang.c is now dominated by a discussions of
olcott's claims, and that those discussions now have little or not
C content.
This is not addressed to olcott. He has demonstrated that he will
ignore topicality complaints, and I don't see anything he posts here.
On 08/08/2025 23:31, olcott wrote:
On 8/8/2025 4:00 PM, Richard Heathfield wrote:
On 08/08/2025 20:35, olcott wrote:
On 8/8/2025 1:29 PM, Richard Heathfield wrote:
On 08/08/2025 17:40, olcott wrote:
Then it can be directly seen that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state.
And therefore you have derived a contradiction which demonstrates
that your reasoning contains a false assumption, namely that DD is
correctly simulated by HHH.
QED.
HHH(DD) only verifies whether or not DD emulated by HHH
according to the semantics x86 language reaches its own
emulated "ret" instruction.
How HHH decides is of no consequence. All that matters is /what/ it
decides, because what it decides is wrong.
It is wrong to assume that any computable function
must report on the behavior of anything besides
the behavior that its actual input actually specifies.
For a start, you're assuming that HHH is computable.
Secondly, all I'm assuming is that HHH is giving its best stab at
deciding whether DD halts.
That's its job. If it isn't at least trying to do that job, you don't
have anything.
DD emulated by HHH according to the semantics x86
language conclusively proves the behavior that the
input to HHH(DD) actually specifies.
Yawn. Does DD halt or doesn't it?
If HHH can't find that out by
emulation, then emulation is not up to the job.
It is flatly incorrect to disagree with the semantics
of the x86 language.
It is flatly incorrect to think that the semantics of x86 machine
code matter a damn. For all I care HHH could get its answer by waving
a wand and saying abracadabra. It's still the wrong answer.
Without the exactingly precise (state transition diagram)
degree of precision that the x86 language specifies we could
go around and around forever on the basis of incorrect measures
of correct simulation.
Well, I'll leave you to get on with that, but the exacting whatever is
all sugar on your fluff cake.
ALL THAT MATTERS is the answer. If you get that wrong, you have nothing.
And you do.
If you have the opinion that 3 > 5 then you are just wrong.
That is not an opinion I hold.
If you have the opinion about correct simulation
I don't give a damn whether the simulation is correct.
You do, of
course, but that's not a headache I need to share. All I need is a
number out of HHH - a 0, or a 1.
And whichever I get, it turns out to be the wrong number.
and there
is no absolute measure then there is no closure. The x86
language is *the absolute measure of correct simulation*
I don't care how the simulation works. What number does it spit out, 0
or 1? Give me that number, and I'll show you it's wrong.
On 8/8/2025 12:59 AM, Kaz Kylheku wrote:
I don't think he's given anyone the materials to run for themselves,
but I analyzed his execution traces in some detail.
*The whole system*
https://github.com/plolcott/x86utm/
Richard Heathfield <rjh@cpax.org.uk> writes:
On 08/08/2025 23:31, olcott wrote:[...]
I observe that comp.lang.c is now dominated by a discussions of
olcott's claims, and that those discussions now have little or not
C content.
This is not addressed to olcott. He has demonstrated that he will
ignore topicality complaints, and I don't see anything he posts here.
On 2025-08-08, olcott <polcott333@gmail.com> wrote:
On 8/8/2025 12:59 AM, Kaz Kylheku wrote:
I don't think he's given anyone the materials to run for themselves,
but I analyzed his execution traces in some detail.
*The whole system*
https://github.com/plolcott/x86utm/
Ah, you published it! I think that is great.
Regardless of it not being able to defeat halting, it can be regarded as artistic object, capturing how far someone was willing to go who is
convinced that an unassilable theorem is wrong.
Trying to defeat academia with x86 programming has a kind of
Don Quixote vibe to it, if we consider hacking on code to be
a kind of chivalry.
CS academia has lost a lot of that. Decades ago, you could develop a
system, and publish about it. Much less so today.
When papers mention some code these days, it is nowhere to be found.
"Believe us when we say that we coded all this and these graphs
and tables are real ...".
On 08/08/2025 23:33, olcott wrote:
On 8/8/2025 5:31 PM, Richard Heathfield wrote:
<snip>
if(Halt_Status)
*is unreachable from DD correctly simulated by HHH*
Are you saying HHH never returns to its caller? If so, you have nothing.
On 09/08/2025 00:00, olcott wrote:
<snip>
You must carefully study the whole page until
you have 100% complete understanding of the
*recursive simulation non-halting behavior pattern*
Wrong.
All we need is the code for DD.
DD correctly simulated by HHH never reaches the "if".
So what?
HHH must report to its caller. Its caller is DD. When it eventually
returns to DD, DD continues executing.
HHH got it wrong.
Which is exactly what you'd expect, because DD is designed to make
HHH fail.
Termination analyzers in general are only accountable
for the actual behavior that their input actually specifies.
A termination analyser that doesn't determine whether DD terminates is
not a termination analyser worth the bytes it occupies.
HHH(DD)==0 is correct on the basis of the behavior that
the actual input actually specifies.
So HHH returns 0, so DD returns, making HHH's report incorrect.
That computer scientists did not notice this for 89 years
is not my mistake.
Your mistake is in misunderstanding a simple proof.
On 09/08/2025 00:21, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 08/08/2025 23:31, olcott wrote:[...]
I observe that comp.lang.c is now dominated by a discussions of
olcott's claims, and that those discussions now have little or not
C content.
This is not addressed to olcott. He has demonstrated that he will
ignore topicality complaints, and I don't see anything he posts here.
But you know I'll take you seriously.
And of course I will.
Richard Heathfield <rjh@cpax.org.uk> writes:Things like C language boil down to "what is correct?"
On 08/08/2025 23:31, olcott wrote:[...]
I observe that comp.lang.c is now dominated by a discussions of
olcott's claims, and that those discussions now have little or not
C content.
This is not addressed to olcott. He has demonstrated that he will
ignore topicality complaints, and I don't see anything he posts here.
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable. >>>Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable. >>>>Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless
thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable. >>>>Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless
thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
On 8/9/2025 8:36 AM, Janis Papanagnou wrote:
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable.
Yes, I think that's the key insight with which anyone should arm themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
typedef int (*ptr)();It is not about the C program. It is about correctness.
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
If people would not spend hundreds of hours coming
up with ill-formed rebuttals and instead spent five
minutes actually understanding that
DD correctly simulated by HHH cannot possibly reach
its own simulated "if" statement or its own simulated
"return" statement because DD calls HHH(DD) in recursive
simulation
I would have have been done with the group years ago.
I am not here for any comp.theory aspects of the above
I am only here for the semantics of the C programming
language.
It was Mike that delved into the deep comp.theory aspects
of this on this group. I am only here for the C aspects.
On Sat, 2025-08-09 at 09:13 -0500, olcott wrote:
On 8/9/2025 8:36 AM, Janis Papanagnou wrote:
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable. >>>>>>Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless
thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by
killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
If people would not spend hundreds of hours coming
up with ill-formed rebuttals and instead spent five
minutes actually understanding that
DD correctly simulated by HHH cannot possibly reach
its own simulated "if" statement or its own simulated
"return" statement because DD calls HHH(DD) in recursive
simulation
I would have have been done with the group years ago.
I am not here for any comp.theory aspects of the above
I am only here for the semantics of the C programming
language.
It was Mike that delved into the deep comp.theory aspects
of this on this group. I am only here for the C aspects.
It is not about the C program. It is about correctness.
On 8/9/2025 9:20 AM, wij wrote:
On Sat, 2025-08-09 at 09:13 -0500, olcott wrote:
On 8/9/2025 8:36 AM, Janis Papanagnou wrote:
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable.
Yes, I think that's the key insight with which anyone should arm themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by killfiling his name. - Now there's a zombie band worm of reiterations from another single person... *sigh* - So be it. Have fun!
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
If people would not spend hundreds of hours coming
up with ill-formed rebuttals and instead spent five
minutes actually understanding that
DD correctly simulated by HHH cannot possibly reach
its own simulated "if" statement or its own simulated
"return" statement because DD calls HHH(DD) in recursive
simulation
I would have have been done with the group years ago.
I am not here for any comp.theory aspects of the above
I am only here for the semantics of the C programming
language.
It was Mike that delved into the deep comp.theory aspects
of this on this group. I am only here for the C aspects.
It is not about the C program. It is about correctness.
Does DD() halt? is an incorrect question for HHH yet:--- Synchronet 3.21a-Linux NewsLink 1.2
Does DD correctly simulated by HHH halt? is a correct question.
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
The behavior of DD() is not the behavior that HHH
can possibly see. HHH can only see the behavior that
its actual input actually specifies as measured by
DD correctly simulated by HHH.
Requiring HHH to report on anything besides the behavior
that its actual input actually specifies is the same as
requiring sum(3,2) to report on the sum of 6 + 3.
On Sat, 2025-08-09 at 09:29 -0500, olcott wrote:
On 8/9/2025 9:20 AM, wij wrote:
On Sat, 2025-08-09 at 09:13 -0500, olcott wrote:
On 8/9/2025 8:36 AM, Janis Papanagnou wrote:
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by killfiling his name. - Now there's a zombie band worm of reiterations from another single person... *sigh* - So be it. Have fun!
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
If people would not spend hundreds of hours coming
up with ill-formed rebuttals and instead spent five
minutes actually understanding that
DD correctly simulated by HHH cannot possibly reach
its own simulated "if" statement or its own simulated
"return" statement because DD calls HHH(DD) in recursive
simulation
I would have have been done with the group years ago.
I am not here for any comp.theory aspects of the above
I am only here for the semantics of the C programming
language.
It was Mike that delved into the deep comp.theory aspects
of this on this group. I am only here for the C aspects.
It is not about the C program. It is about correctness.
You erased the question to reply POO philosophy.Next step.
Q1: What time is it, yes or no?
Q2: Jack is a bachelor. Does Jack hit his wife?
What is the correct answer of Q1,Q2 ?
--- Synchronet 3.21a-Linux NewsLink 1.2Does DD() halt? is an incorrect question for HHH yet:
Does DD correctly simulated by HHH halt? is a correct question.
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
The behavior of DD() is not the behavior that HHH
can possibly see. HHH can only see the behavior that
its actual input actually specifies as measured by
DD correctly simulated by HHH.
Requiring HHH to report on anything besides the behavior
that its actual input actually specifies is the same as
requiring sum(3,2) to report on the sum of 6 + 3.
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely unbreakable. >>>>Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless
thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
On 09/08/2025 14:36, Janis Papanagnou wrote:
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely
unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless
thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by
killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
The newsreaders I've used all support a "ignore subthread" action. If
you can use that, you won't see PO's posts or any replies (unless you
use an option to "view ignored posts").
Mike.
On 09/08/2025 14:36, Janis Papanagnou wrote:
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely
unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless
thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by
killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
The newsreaders I've used all support a "ignore subthread" action. If
you can use that, you won't see PO's posts or any replies (unless you
use an option to "view ignored posts").
Mike.
On 09.08.2025 17:16, Mike Terry wrote:
On 09/08/2025 14:36, Janis Papanagnou wrote:
On 08.08.2025 18:24, Richard Heathfield wrote:
On 08/08/2025 15:10, Janis Papanagnou wrote:
On 08.08.2025 08:46, Richard Heathfield wrote:
On 08/08/2025 06:59, Kaz Kylheku wrote:
At that point I realized that Peter's conviction is likely
unbreakable.
Yes, I think that's the key insight with which anyone should arm
themselves before launching into the fray.
But then why continuing to feed him?! - Why engage in the fray in
the first place?!
Ever chewed gum?
About five decades ago. - Does that explain anything WRT this useless
thread? - Are you (still?) chewing gum?
Anyway. - I got rid of Olcott's band worms of OT reiterations only by
killfiling his name. - Now there's a zombie band worm of reiterations
from another single person... *sigh* - So be it. Have fun!
The newsreaders I've used all support a "ignore subthread" action. If
you can use that, you won't see PO's posts or any replies (unless you
use an option to "view ignored posts").
I see also in this thread some responses that I find interesting, so filtering the subthread is not exactly what I am looking for. Also,
he regularly started new independent threads with the same contents
or slightly differing subject lines. - Anyway thanks for your concern.
What I am looking for is to filter posts from pathological characters.
As I've seen, sadly, some offensive pathological people deliberately
decide to bypass personal filter settings by changing nym oder address.
Olcott (olcott <NoOne@NoWhere.com>) has just spent effort to do this,
it seems.
We all know that this person is able to understand technical issues,
yet he has obviously some problems with logical issues. This behavior
is another indication that he either might logically not understand
why we have filters (or again just reveals his pathological behavior,
as he obviously tries to drag me into his lunacy).
Janis
Mike.
We all know that this person is able to understand technical issues,
yet he has obviously some problems with logical issues.
On 09/08/2025 17:05, Janis Papanagnou wrote:>>
I see also in this thread some responses that I find interesting, so
filtering the subthread is not exactly what I am looking for. Also,
he regularly started new independent threads with the same contents
or slightly differing subject lines. - Anyway thanks for your concern.
What I am looking for is to filter posts from pathological characters.
As I've seen, sadly, some offensive pathological people deliberately
decide to bypass personal filter settings by changing nym oder address.
Olcott (olcott <NoOne@NoWhere.com>) has just spent effort to do this,
it seems.
While PO is not without personal faults(!) I wouldn't class him as a nym-shifters. I think he has a couple of posting accounts: a GigaNews account and an Eternal September account. I'm pretty sure he's not actively trying to evade spam filters... Probably it's just changing newsreaders/servers/reinstalling stuff etc..
Mike.
On 8/9/2025 12:00 PM, Mike Terry wrote:
On 09/08/2025 17:05, Janis Papanagnou wrote:>>
I see also in this thread some responses that I find interesting, so
filtering the subthread is not exactly what I am looking for. Also,
he regularly started new independent threads with the same contents
or slightly differing subject lines. - Anyway thanks for your concern.
What I am looking for is to filter posts from pathological characters.
As I've seen, sadly, some offensive pathological people deliberately
decide to bypass personal filter settings by changing nym oder address.
Olcott (olcott <NoOne@NoWhere.com>) has just spent effort to do this,
it seems.
While PO is not without personal faults(!) I wouldn't class him as a nym-shifters. I think he has
a couple of posting accounts: a GigaNews account and an Eternal September account. I'm pretty
sure he's not actively trying to evade spam filters... Probably it's just changing
newsreaders/servers/reinstalling stuff etc..
Mike.
I wanted to make sure that my one reply was seen
by its author. I have switched back to my usual
provider for everything else.
On 09/08/2025 18:05, olcott wrote:
On 8/9/2025 12:00 PM, Mike Terry wrote:
On 09/08/2025 17:05, Janis Papanagnou wrote:>>
I see also in this thread some responses that I find interesting, so
filtering the subthread is not exactly what I am looking for. Also,
he regularly started new independent threads with the same contents
or slightly differing subject lines. - Anyway thanks for your concern. >>>>
What I am looking for is to filter posts from pathological characters. >>>>
As I've seen, sadly, some offensive pathological people deliberately
decide to bypass personal filter settings by changing nym oder address. >>>>
Olcott (olcott <NoOne@NoWhere.com>) has just spent effort to do this,
it seems.
While PO is not without personal faults(!) I wouldn't class him as a
nym-shifters. I think he has a couple of posting accounts: a
GigaNews account and an Eternal September account. I'm pretty sure
he's not actively trying to evade spam filters... Probably it's just
changing newsreaders/servers/reinstalling stuff etc..
Mike.
I wanted to make sure that my one reply was seen
by its author. I have switched back to my usual
provider for everything else.
ok I take it back. That's nym-shifting. :( It's actually in- character for you, but I'd just never spotted you doing it before...
Mike.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 163:53:46 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
9,181 files (2,736M bytes) |
| Messages: | 2,411,516 |