Simulating Termination Analyzer HHH correctly simulates its input
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 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 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: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 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*
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?
How valuable to computer science would it be to understand
that the conventional halting problem proofs do not actually
derive their undecidability conclusion?
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 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 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 8/7/2025 5:59 PM, Kaz Kylheku wrote:
On 2025-08-07, olcott <[email protected]> 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 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
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.
At that point I realized that Peter's conviction is likely unbreakable.
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: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?!
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.
Then it can be directly seen that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state.
On 2025-08-07, Richard Heathfield <[email protected]> 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: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.
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 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 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*
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.
Richard Heathfield <[email protected]> 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 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/
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 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 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 <[email protected]>) 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.
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 <[email protected]>) 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 144:25:36 |
| Calls: | 12,089 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,490 |