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
Also
https://philpapers.org/archive/OLCHPS.pdf
Claude AI proved why HHH(DD)==0 is correct
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
Also
https://philpapers.org/archive/OLCHPS.pdf
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
Also https://philpapers.org/archive/OLCHPS.pdf
If DD() halts and HHH(DD) returns a result of non-halting then HHH is not
a halt decider for DD: this just confirms that the extant Halting Problem proofs are correct and that you have wasted the last 22 years.
The first part of my proof requires understanding
that the above paper is entirely correct in everything
that it says.
All that I need for now is agreement on HHH(DD)==0
is correct
On 10/08/2025 17:00, Andy Walker wrote:
Why do it, chaps?Crosswords, Wordle, Sudoku...
On 8/10/2025 11:00 AM, Andy Walker wrote:eedd0f09e141
On 10/08/2025 13:30, Mr Flibble wrote:int DD()
If DD() halts and HHH(DD) returns a result of non-halting then HHH is
not a halt decider for DD: this just confirms that the extant Halting
Problem proofs are correct and that you have wasted the last 22 years.
    It's Peter's time to waste, it's harmless, and no-one is
    forced
to read his articles [I don't, nor other articles of over 100 lines or
by certain ultra-prolific posters]. What surprises me is that /others/
seem happy to write something like 10000 replies/year despite /knowing/
that it makes no difference whatsoever to Peter or to his arguments or
to anyone else. Why do it, chaps? You're not convincing /anyone/, not
Peter, not other posters here, and even less those who've given up on
this group. There is no magic bullet!
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key difference that we have now is the three LLM AI systems agree
that DD correctly simulated by HHH cannot possibly reach its own
"return" statement final halt state.
They also agree that does make HHH(DD)==0 correct when judged entirely
on that basis.
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
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
People here have been gaslighting me for at least three year by refusing
to agree that HHH(DD)==0 on that basis.
Since this first step of my proof must be understood before moving on to
the next step their gaslighting was stonewalling.
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/10/2025 11:00 AM, Andy Walker wrote:
On 10/08/2025 13:30, Mr Flibble wrote:
If DD() halts and HHH(DD) returns a result of non-halting then
HHH is not
a halt decider for DD: this just confirms that the extant
Halting Problem
proofs are correct and that you have wasted the last 22 years.
     It's Peter's time to waste, it's harmless, and no-one is
forced
to read his articles [I don't, nor other articles of over 100
lines or
by certain ultra-prolific posters]. What surprises me is that
/others/
seem happy to write something like 10000 replies/year despite
/knowing/
that it makes no difference whatsoever to Peter or to his
arguments or
to anyone else. Why do it, chaps? You're not convincing
/anyone/, not
Peter, not other posters here, and even less those who've given
up on
this group. There is no magic bullet!
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
The key difference that we have now is the three LLM AI
systems agree that DD correctly simulated by HHH
On 10/08/2025 17:22, Richard Heathfield wrote:
On 10/08/2025 17:00, Andy Walker wrote:
Why do it, chaps?Crosswords, Wordle, Sudoku...
    Yes, but do you do 30 crosswords [etc] per day, every day,for decades?
I could understand 1 peterbaiting/day, but keep some sense
proportion!
Claude AI says that HHH(DD)==0 is correct even
though DD() halts.
On 8/10/2025 11:32 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 11:26:00 -0500, olcott wrote:
On 8/10/2025 11:00 AM, Andy Walker wrote:eedd0f09e141
On 10/08/2025 13:30, Mr Flibble wrote:int DD()
If DD() halts and HHH(DD) returns a result of non-halting then HHH
is not a halt decider for DD: this just confirms that the extant
Halting Problem proofs are correct and that you have wasted the last >>>>> 22 years.
    It's Peter's time to waste, it's harmless, and no-one is
    forced
to read his articles [I don't, nor other articles of over 100 lines
or by certain ultra-prolific posters]. What surprises me is that
/others/ seem happy to write something like 10000 replies/year
despite /knowing/ that it makes no difference whatsoever to Peter or
to his arguments or to anyone else. Why do it, chaps? You're not
convincing /anyone/, not Peter, not other posters here, and even less
those who've given up on this group. There is no magic bullet!
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The key difference that we have now is the three LLM AI systems agree
that DD correctly simulated by HHH cannot possibly reach its own
"return" statement final halt state.
They also agree that does make HHH(DD)==0 correct when judged entirely
on that basis.
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
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
People here have been gaslighting me for at least three year by
refusing to agree that HHH(DD)==0 on that basis.
Since this first step of my proof must be understood before moving on
to the next step their gaslighting was stonewalling.
On Sun, 10 Aug 2025 09:30:11 -0500, olcott wrote:
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
I am an expert C programmer which is why I understand that DD() halts,
HHH(DD) reports non-halting and thus is not a halt decider over DD as
it gets the answer wrong -- thus you have not refuted any Halting
Problem proofs and have thus wasted the last 22 years.
/Flibble
Claude AI says that HHH(DD)==0 is correct even though DD() halts. Until
you understand how that is correct you will not understand my work.
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() halts.
You told Claude to believe that, and like a good AI he does what you
tell him.
Why do it, chaps?
On 10/08/2025 17:22, Richard Heathfield wrote:
On 10/08/2025 17:00, Andy Walker wrote:
Why do it, chaps?Crosswords, Wordle, Sudoku...
Yes, but do you do 30 crosswords [etc] per day, every day,for
decades? I could understand 1 peterbaiting/day, but keep some sense proportion!
On 8/10/2025 7:24 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 01:06:23 -0500, olcott wrote:
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
Also https://philpapers.org/archive/OLCHPS.pdf
If DD() halts and HHH(DD) returns a result of non-halting then HHH is not
a halt decider for DD: this just confirms that the extant Halting Problem
proofs are correct and that you have wasted the last 22 years.
/Flibble
The first part of my proof requires understanding
that the above paper is entirely correct in everything
that it says. I can and will address your objection
later on.
On 8/10/2025 11:00 AM, Andy Walker wrote:
On 10/08/2025 13:30, Mr Flibble wrote:
If DD() halts and HHH(DD) returns a result of non-halting then HHH is
not
a halt decider for DD: this just confirms that the extant Halting
Problem
proofs are correct and that you have wasted the last 22 years.
     It's Peter's time to waste, it's harmless, and no-one is forced
to read his articles [I don't, nor other articles of over 100 lines or
by certain ultra-prolific posters]. What surprises me is that /others/
seem happy to write something like 10000 replies/year despite /knowing/
that it makes no difference whatsoever to Peter or to his arguments or
to anyone else. Why do it, chaps? You're not convincing /anyone/, not
Peter, not other posters here, and even less those who've given up on
this group. There is no magic bullet!
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
The key difference that we have now is the three LLM AI
systems agree that DD correctly simulated by HHH cannot
possibly reach its own "return" statement final halt state.
They also agree that does make HHH(DD)==0 correct when
judged entirely on that basis.
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
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
People here have been gaslighting me for at least three
year by refusing to agree that HHH(DD)==0 on that basis.
Since this first step of my proof must be understood
before moving on to the next step their gaslighting was
stonewalling.
On 8/10/2025 7:24 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 01:06:23 -0500, olcott wrote:
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
Also https://philpapers.org/archive/OLCHPS.pdf
If DD() halts and HHH(DD) returns a result of non-halting then HHH is not
a halt decider for DD: this just confirms that the extant Halting Problem
proofs are correct and that you have wasted the last 22 years.
/Flibble
The first part of my proof requires understanding
that the above paper is entirely correct in everything
that it says. I can and will address your objection
later on.
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD()
halts.
You told Claude to believe that, and like a good AI he does
what you
tell him.
I suspect if you specifically told Claude that HHH was supposed
to be a
halt decider and it was an attempt to refute the Halting
Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() halts.
You told Claude to believe that, and like a good AI he does what you
tell him.
I suspect if you specifically told Claude that HHH was supposed to be a
halt decider and it was an attempt to refute the Halting Problem
proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
On 8/10/2025 11:55 AM, Richard Heathfield wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even
though DD() halts.
You told Claude to believe that, and like a good AI he does what you
tell him.
You can see here that I did not tell Claude to believe that https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 8/10/2025 11:46 AM, dbush wrote:
On 8/10/2025 12:26 PM, olcott wrote:
On 8/10/2025 11:00 AM, Andy Walker wrote:
On 10/08/2025 13:30, Mr Flibble wrote:
If DD() halts and HHH(DD) returns a result of non-halting then HHH
is not
a halt decider for DD: this just confirms that the extant Halting
Problem
proofs are correct and that you have wasted the last 22 years.
     It's Peter's time to waste, it's harmless, and no-one is forced >>>> to read his articles [I don't, nor other articles of over 100 lines or >>>> by certain ultra-prolific posters]. What surprises me is that /others/ >>>> seem happy to write something like 10000 replies/year despite /knowing/ >>>> that it makes no difference whatsoever to Peter or to his arguments or >>>> to anyone else. Why do it, chaps? You're not convincing /anyone/, not >>>> Peter, not other posters here, and even less those who've given up on
this group. There is no magic bullet!
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
The key difference that we have now is the three LLM AI
systems agree that DD correctly simulated by HHH cannot
possibly reach its own "return" statement final halt state.
They also agree that does make HHH(DD)==0 correct when
judged entirely on that basis.
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
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
People here have been gaslighting me for at least three
year by refusing to agree that HHH(DD)==0 on that basis.
Since this first step of my proof must be understood
before moving on to the next step their gaslighting was
stonewalling.
And when we remind the AI that the prompt assumes that HHH can return
a correct answer, it concludes that such an HHH cannot exist, as Linz
and others have proved and as you have *explicitly* agreed is correct.
Counter-factual.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
You must first understand it within the context
of DD correctly simulated by HHH.
On 8/10/2025 11:21 AM, wij wrote:
On Sun, 2025-08-10 at 10:19 -0500, olcott wrote:
On 8/10/2025 9:54 AM, wij wrote:
On Sun, 2025-08-10 at 09:11 -0500, olcott wrote:
On 8/10/2025 1:58 AM, Richard Heathfield wrote:
On 10/08/2025 07:06, olcott wrote:
Claude AI proved why HHH(DD)==0 is correct
Fantastic! Good old Claude, eh?
I will take you at your word and presume that HHH(DD) does in fact >>>>>> return 0, which means "(a) Detects a non-terminating behavior
pattern:
abort simulation and return 0." - i.e. Claude tells us DD doesn't
halt.
int DD()
{
    int Halt_Status = HHH(DD); <=== assigns 0 to Halt_Status
    if (Halt_Status)
      HERE: goto HERE;
    return Halt_Status;
}
So far so good. Let's see what happens next.
    if (Halt_Status) <=== if(0) is false, so the if's statement >>>>>> on the
next line is skipped...
      HERE: goto HERE;
    return Halt_Status;
}
Uh-oh; I have a bad feeling about this, but let's see what happens >>>>>> next.
    return Halt_Status; <=== DD returns, and therefore halts. >>>>>>
So Claude was wrong after all.
Want to try again? With a 1, maybe?
All that I need for now is agreement on HHH(DD)==0
is correct when HHH(DD) is reporting on the behavior
that DD correctly simulated by HHH specifies.
If HHH does not refute the HP, I can understand. But how would it be
useful
for the mankind and AI?
My proof must be step by step or it cannot be understood.
All that I need for now is agreement on HHH(DD)==0
is correct when HHH(DD) is reporting on the behavior
that DD correctly simulated by HHH specifies.
Until you understand that this is correct on that basis
we cannot proceed.
If HHH does not refute the HP, I can understand. But how would it be
useful
for the mankind and AI?
By refusing to understand that DD correctly simulated
by HHH cannot possibly reach its own simulated "return"
statement final halt state you are merely stonewalling.
On 8/10/2025 11:51 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 11:43:43 -0500, olcott wrote:
On 8/10/2025 11:32 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 11:26:00 -0500, olcott wrote:
On 8/10/2025 11:00 AM, Andy Walker wrote:eedd0f09e141
On 10/08/2025 13:30, Mr Flibble wrote:int DD()
If DD() halts and HHH(DD) returns a result of non-halting then HHH >>>>>>> is not a halt decider for DD: this just confirms that the extant >>>>>>> Halting Problem proofs are correct and that you have wasted the last >>>>>>> 22 years.
      It's Peter's time to waste, it's harmless, and no-one is >>>>>>       forced
to read his articles [I don't, nor other articles of over 100 lines >>>>>> or by certain ultra-prolific posters]. What surprises me is that >>>>>> /others/ seem happy to write something like 10000 replies/year
despite /knowing/ that it makes no difference whatsoever to Peter or >>>>>> to his arguments or to anyone else. Why do it, chaps? You're not >>>>>> convincing /anyone/, not Peter, not other posters here, and even less >>>>>> those who've given up on this group. There is no magic bullet!
{
    int Halt_Status = HHH(DD);
    if (Halt_Status)
      HERE: goto HERE;
    return Halt_Status;
}
The key difference that we have now is the three LLM AI systems agree >>>>> that DD correctly simulated by HHH cannot possibly reach its own
"return" statement final halt state.
They also agree that does make HHH(DD)==0 correct when judged entirely >>>>> on that basis.
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
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
People here have been gaslighting me for at least three year by
refusing to agree that HHH(DD)==0 on that basis.
Since this first step of my proof must be understood before moving on >>>>> to the next step their gaslighting was stonewalling.
On Sun, 10 Aug 2025 09:30:11 -0500, olcott wrote:
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
I am an expert C programmer which is why I understand that DD() halts, >>>> HHH(DD) reports non-halting and thus is not a halt decider over DD as
it gets the answer wrong -- thus you have not refuted any Halting
Problem proofs and have thus wasted the last 22 years.
/Flibble
Claude AI says that HHH(DD)==0 is correct even though DD() halts. Until
you understand how that is correct you will not understand my work.
I do understand your work which is why I know that your work is both
erroneous as far as the Halting Problem proofs are concerned and has no
value - a waste of 22 years.
/Flibble
You must first understand it within the context
of DD correctly simulated by HHH. Until you first
so that you are merely stonewalling against closure.
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() halts.
You told Claude to believe that, and like a good AI he does what you >>>>> tell him.
I suspect if you specifically told Claude that HHH was supposed to be a >>>> halt decider and it was an attempt to refute the Halting Problem
proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly simulates
its input"
That you refuse to understand how the simulation
is correct is your own error.
...which we know to be false after your bug report in which you
acknowledged that HHH produces the wrong answer.
That you refuse to understand how the simulation
is correct is your own error.
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
On 8/10/25 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD()
halts.
You told Claude to believe that, and like a good AI he does
what you
tell him.
I suspect if you specifically told Claude that HHH was
supposed to be a
halt decider and it was an attempt to refute the Halting
Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly
simulates its input"
That you refuse to understand how the simulation
is correct is your own error.
You have yet to show that it is.
With crosswords, Wordle, Sudoku, you get a different puzzle every
day! That's much more fun... :)
On 8/10/2025 1:44 PM, Richard Heathfield wrote:
On 10/08/2025 19:30, olcott wrote:That is merely your willful thus dishonest ignorance.
That you refuse to understand how the simulation
is correct is your own error.
Here is the core of DD.
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
Four lines.
Your simulator simulates ONE line - the call to the simulator!
That it fails to simulate the other three quarters - the actual
logic of DD - makes it an abject failure as a simulator.
HHH creates a separate process context and then
simulates DD in this process context. When this DD
calls HHH(DD) the first HHH emulates and instance of
itself in the DD process context.
On 8/10/2025 1:51 PM, Richard Heathfield wrote:
On 10/08/2025 19:44, olcott wrote:Do you mean that your software engineering skill is so poor that you
<snip>
The simulation of DD by HHH is proven to be correct on the basis of
the emulation of DD by HHH according to the definition of the x86
language.
So the x86 language gets it wrong under direct execution, does it? Have
you told Intel yet?
lack the technical capacity to understand that recursive emulation
changes behavior?
int main();
void DDD()
{
main();
return;
}
int main()
{
Output("Input_Halts = ", HHH(DDD));
}
On 8/10/2025 1:44 PM, Richard Heathfield wrote:
On 10/08/2025 19:30, olcott wrote:That is merely your willful thus dishonest ignorance.
That you refuse to understand how the simulation
is correct is your own error.
Here is the core of DD.
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
Four lines.
Your simulator simulates ONE line - the call to the simulator!
That it fails to simulate the other three quarters - the actual logic
of DD - makes it an abject failure as a simulator.
HHH creates a separate process context and then
simulates DD in this process context. When this DD
calls HHH(DD) the first HHH emulates and instance of
itself in the DD process context. This emulated HHH
instance creates a new process context to emulate
its instance of DD. This DD calls HHH(DD).
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Figured out all on its own that HHH(DD)==0 is correct because
it figured out all on its own that the input to HHH(DD)
specifies: the *recursive simulation non-halting behavior pattern*
On 8/10/2025 1:34 PM, dbush wrote:
On 8/10/2025 2:23 PM, olcott wrote:No in other words to it.
Counter-factual.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
In other words, your response to "X is wrong because Y" is "but X is
right".
Just the verbatim words on the above link.
Change a single punctuation mark and you are cheating.
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() halts. >>>>>>>You told Claude to believe that, and like a good AI he does what you >>>>>>> tell him.
I suspect if you specifically told Claude that HHH was supposed to >>>>>> be a
halt decider and it was an attempt to refute the Halting Problem
proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly
simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct?
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
On 8/10/2025 1:51 PM, Richard Heathfield wrote:
On 10/08/2025 19:44, olcott wrote:
<snip>
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
So the x86 language gets it wrong under direct execution, does it?
Have you told Intel yet?
Do you mean that your software engineering
skill is so poor that you lack the technical
capacity to understand that recursive emulation
changes behavior?
int main();
void DDD()
{
 main();
 return;
}
int main()
{
 Output("Input_Halts = ", HHH(DDD));
}
On 10/08/2025 18:23, Mike Terry wrote:
With crosswords, Wordle, Sudoku, you get a different puzzle every
day! That's much more fun... :)
With Simon Tatham's Portable Puzzle Collection
https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
[highly recommended for those who like this sort of thing] you get as
many different puzzles as you want every day, almost all with settings
for whatever difficulty you like. Pre-compiled versions for all the
common OSs, source if you want it, web versions, .... Oh, no adverts,
no charge, just the puzzles. What's not to like?
On 8/10/2025 1:51 PM, Richard Heathfield wrote:
On 10/08/2025 19:44, olcott wrote:
<snip>
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
So the x86 language gets it wrong under direct execution, does
it? Have you told Intel yet?
Do you mean that your software engineering
skill is so poor that you lack the technical
capacity to understand that recursive emulation
changes behavior?
int main();
void DDD()
{
 main();
 return;
}
int main()
{
 Output("Input_Halts = ", HHH(DDD));
}
On 8/10/2025 4:32 PM, Richard Heathfield wrote:
On 10/08/2025 22:04, olcott wrote:
<snip>
Google [x86utm operating system]
I've seen it, syntax errors and all. That doesn't emulate DD
correctly either.
I have already fully addressed this
Google [x86utm operating system]
Erasing the immediate context that you are
responding to is deceitful and dishonest.
     With Simon Tatham's Portable Puzzle CollectionWell, nothing :)
  https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
[highly recommended (...)] [...] What's not to like?
I was solving one of his Loopy puzzles just before reading your post!
On 8/10/2025 4:40 PM, Richard Heathfield wrote:
On 10/08/2025 22:35, olcott wrote:
On 8/10/2025 4:32 PM, Richard Heathfield wrote:
On 10/08/2025 22:04, olcott wrote:
<snip>
Google [x86utm operating system]
I've seen it, syntax errors and all. That doesn't emulate DD
correctly either.
I have already fully addressed this
No, you haven't.
Saying it works when it clearly doesn't isn't "addressing" it; it's
just denial.
Erasing the immediate context that you are
responding to is deceitful and dishonest.
On 8/10/2025 4:50 PM, dbush wrote:
On 8/10/2025 5:42 PM, olcott wrote:
Erasing the immediate context that you are
responding to is deceitful and dishonest.
You mean like you did here (see below)?
You hypocrisy knows no bounds.
On 8/10/2025 3:06 PM, dbush wrote:
On 8/10/2025 3:02 PM, olcott wrote:
On 8/10/2025 1:57 PM, dbush wrote:;
On 8/10/2025 2:46 PM, olcott wrote:*It is physically impossible for me to trim these words*
On 8/10/2025 1:34 PM, dbush wrote:;
On 8/10/2025 2:23 PM, olcott wrote:No in other words to it.
;;
Counter-factual.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
;
In other words, your response to "X is wrong because Y" is "but X
is right".
;
Just the verbatim words on the above link.
And below (which you dishonestly trimmed)
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
;
And you continue to reply to "X is wrong because Y" with "but X is
right" and dishonestly trim "Y".
;
Your dishonesty knows no bounds.
That you change the subject away from the word for word
exact words of this page
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
and I ignore your change of subject and bring it back
to the point is your dishonesty not mine.
On 8/10/2025 4:32 PM, Richard Heathfield wrote:
On 10/08/2025 22:04, olcott wrote:
<snip>
Google [x86utm operating system]
I've seen it, syntax errors and all. That doesn't emulate DD correctly
either.
I have already fully addressed this and you
already responded. Why lie?
HHH creates a separate process context and then
emulates DD in this process context. When this DD
calls HHH(DD) the first HHH emulates and instance of
itself in the DD process context. This emulated HHH
instance creates a new process context to emulate
its instance of DD. This DD calls HHH(DD).
On 8/10/2025 4:53 PM, Richard Heathfield wrote:
On 10/08/2025 22:42, olcott wrote:
<snip>
Erasing the immediate context that you are
responding to is deceitful and dishonest.
Snipping isn't erasing. Snipping is focus.
Snipping the words that you are responding to is dishonest.
On 8/10/2025 5:10 PM, dbush wrote:
On 8/10/2025 6:07 PM, olcott wrote:If either you misunderstood me or I made some mistake in the past it
On 8/10/2025 4:56 PM, dbush wrote:
On 8/10/2025 5:53 PM, olcott wrote:If it was a follow up question to the exact same review that would
On 8/10/2025 4:50 PM, dbush wrote:No, I responded directly to that by asking the AI a follow-up
On 8/10/2025 5:42 PM, olcott wrote:
Erasing the immediate context that you are responding to is
deceitful and dishonest.
You mean like you did here (see below)?
You hypocrisy knows no bounds.
On 8/10/2025 3:06 PM, dbush wrote:
On 8/10/2025 3:02 PM, olcott wrote:
On 8/10/2025 1:57 PM, dbush wrote:And you continue to reply to "X is wrong because Y" with "but X >>>>>> Â > is right" and dishonestly trim "Y".
On 8/10/2025 2:46 PM, olcott wrote:*It is physically impossible for me to trim these words*
On 8/10/2025 1:34 PM, dbush wrote:;
On 8/10/2025 2:23 PM, olcott wrote:No in other words to it.
;In other words, your response to "X is wrong because Y" is >>>>>> "but X
Counter-factual.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>> Â >>>>>>
;
is right".
;
Just the verbatim words on the above link.
And below (which you dishonestly trimmed)
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
;
;
;
Your dishonesty knows no bounds.
That you change the subject away from the word for word exact words
of this page
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c and I
ignore your change of subject and bring it back to the point is your >>>>> dishonesty not mine.
question and you just repeated your claim, proving that you agreed
with the AI's follow up response.
have been OK. It looked like an entirely different review that started
with a wrong basis.
The review that I posted did not have a complete understanding. To
attain a complete understanding takes 15 pages.
The review that I posted only confirms the simple fact that everyone
has gaslighted me on for three years:
When the measure of the behavior of the input to HHH(DD) is DD
correctly simulated by HHH
Which it can't be because that doesn't happen, as you have admitted on
the record:
remains true that Claude AI, ChatGPT and Grok all provide the correct
answer to this question:
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 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?
On 8/10/2025 5:24 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:17:05 -0500, olcott wrote:
On 8/10/2025 5:10 PM, dbush wrote:
On 8/10/2025 6:07 PM, olcott wrote:If either you misunderstood me or I made some mistake in the past it
On 8/10/2025 4:56 PM, dbush wrote:
On 8/10/2025 5:53 PM, olcott wrote:If it was a follow up question to the exact same review that would
On 8/10/2025 4:50 PM, dbush wrote:No, I responded directly to that by asking the AI a follow-up
On 8/10/2025 5:42 PM, olcott wrote:
Erasing the immediate context that you are responding to isYou mean like you did here (see below)?
deceitful and dishonest.
You hypocrisy knows no bounds.
On 8/10/2025 3:06 PM, dbush wrote:
; On 8/10/2025 3:02 PM, olcott wrote:"but X
; On 8/10/2025 1:57 PM, dbush wrote:
; On 8/10/2025 2:46 PM, olcott wrote:
; On 8/10/2025 1:34 PM, dbush wrote:
; On 8/10/2025 2:23 PM, olcott wrote:
t;; In other words, your response to "X is wrong because Y" >>>>>>>> Â >>>>> is
; Counter-factual.
; https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c- dc5ffe10f00c
t;
t;
; And you continue to reply to "X is wrong because Y" with; *It is physically impossible for me to trim these words* >>>>>>>> Â >> https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>> Â >>t;; is right".; No in other words to it.
t;
; Just the verbatim words on the above link.
; And below (which you dishonestly trimmed)
t;
; "but X is right" and dishonestly trim "Y".
t;
; Your dishonesty knows no bounds.
That you change the subject away from the word for word exact
words of this page
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c and I >>>>>>> ignore your change of subject and bring it back to the point is
your dishonesty not mine.
question and you just repeated your claim, proving that you agreed >>>>>> with the AI's follow up response.
have been OK. It looked like an entirely different review that
started with a wrong basis.
The review that I posted did not have a complete understanding. To
attain a complete understanding takes 15 pages.
The review that I posted only confirms the simple fact that everyone >>>>> has gaslighted me on for three years:
When the measure of the behavior of the input to HHH(DD) is DD
correctly simulated by HHH
Which it can't be because that doesn't happen, as you have admitted
on the record:
remains true that Claude AI, ChatGPT and Grok all provide the correct
answer to this question:
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 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?
HHH(DD) should correctly return whatever DD() does. You have failed.
/Flibble
Changing the words as the basis for rebuttal is known as the strawman
error.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
On 8/10/2025 5:50 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:34:14 -0500, olcott wrote:
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
But that would mean DD() halts
It only seems that way when you make sure to not pay enough attention.
On 8/10/2025 5:50 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:34:14 -0500, olcott wrote:
Changing the words as the basis for rebuttal is known as the strawman
error.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
But that would mean DD() halts so HHH(DD) got the answer wrong as per
the Halting Problem proofs. You have failed.
/Flibble
My prior reply may be incorrect. I always read and then reread and
reread. That is how I pay enough attention.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
When you fully understand that this is correct thenn (then and only
then) we can move on to the issue of the directly executed DD().
On 8/10/2025 6:03 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:58:18 -0500, olcott wrote:
On 8/10/2025 5:50 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:34:14 -0500, olcott wrote:
Changing the words as the basis for rebuttal is known as the
strawman error.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
But that would mean DD() halts so HHH(DD) got the answer wrong as per
the Halting Problem proofs. You have failed.
/Flibble
My prior reply may be incorrect. I always read and then reread and
reread. That is how I pay enough attention.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
When you fully understand that this is correct thenn (then and only
then) we can move on to the issue of the directly executed DD().
I fully understand your failure to refute any Halting Problem proof.
/Flibble
That you stonewall the next step of my proof is not a rebuttal.
On 8/10/2025 6:04 PM, dbush wrote:
On 8/10/2025 7:01 PM, olcott wrote:
On 8/10/2025 5:56 PM, dbush wrote:Translation:
*Trollish replies will be henceforth ignored*
"I will ignore things that prove me wrong"
I will pay very close attention to any actual attempts to prove me
wrong. The closest attempt to prove me wrong is the fact that HHH(DD)==0
and the directly executed DD() disagree.
On 8/10/2025 6:08 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 18:05:57 -0500, olcott wrote:
On 8/10/2025 6:03 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:58:18 -0500, olcott wrote:
On 8/10/2025 5:50 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:34:14 -0500, olcott wrote:
Changing the words as the basis for rebuttal is known as the
strawman error.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
But that would mean DD() halts so HHH(DD) got the answer wrong as
per the Halting Problem proofs. You have failed.
/Flibble
My prior reply may be incorrect. I always read and then reread and
reread. That is how I pay enough attention.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
When you fully understand that this is correct thenn (then and only
then) we can move on to the issue of the directly executed DD().
I fully understand your failure to refute any Halting Problem proof.
/Flibble
That you stonewall the next step of my proof is not a rebuttal.
You don't have a proof, instead you have a collection of false
assertions. I wonder if there is collective noun for false assertions.
/Flibble
It only seems that way by making sure to ignore that
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
I have been trying to get to the next step of the proof that addresses
your issue for three years and everyone makes sure to stonewall its
mandatory prerequisite:
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
If either you misunderstood me or I made some mistake
in the past it remains true that Claude AI, ChatGPT
and Grok all provide the correct answer to this question:
On 8/10/2025 5:56 PM, dbush wrote:
*Trollish replies will be henceforth ignored*
On 11/08/2025 00:01, olcott wrote:
On 8/10/2025 5:56 PM, dbush wrote:
*Trollish replies will be henceforth ignored*
Since you never respond constructively to anyone, I fail to see what difference it makes.
If it makes you feel any better, I have no objection to you killfiling
me right now.
On 8/10/2025 6:04 PM, dbush wrote:
On 8/10/2025 7:01 PM, olcott wrote:
On 8/10/2025 5:56 PM, dbush wrote:
*Trollish replies will be henceforth ignored*
Translation:
"I will ignore things that prove me wrong"
I will pay very close attention to any actual attempts
to prove me wrong.
The closest attempt to prove me wrong
is the fact that HHH(DD)==0 and the directly executed
DD() disagree.
On 8/10/2025 4:56 PM, dbush wrote:
On 8/10/2025 5:53 PM, olcott wrote:
On 8/10/2025 4:50 PM, dbush wrote:
On 8/10/2025 5:42 PM, olcott wrote:
Erasing the immediate context that you are
responding to is deceitful and dishonest.
You mean like you did here (see below)?
You hypocrisy knows no bounds.
On 8/10/2025 3:06 PM, dbush wrote:
On 8/10/2025 3:02 PM, olcott wrote:"but X
On 8/10/2025 1:57 PM, dbush wrote:
On 8/10/2025 2:46 PM, olcott wrote:
On 8/10/2025 1:34 PM, dbush wrote:
On 8/10/2025 2:23 PM, olcott wrote:
;;
Counter-factual.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
;
In other words, your response to "X is wrong because Y" is
;*It is physically impossible for me to trim these words*;is right".No in other words to it.
;
Just the verbatim words on the above link.
And below (which you dishonestly trimmed)
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
;
And you continue to reply to "X is wrong because Y" with "but X is >>>> Â > right" and dishonestly trim "Y".
;
Your dishonesty knows no bounds.
That you change the subject away from the word for word
exact words of this page
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
and I ignore your change of subject and bring it back
to the point is your dishonesty not mine.
No, I responded directly to that by asking the AI a follow-up question
and you just repeated your claim, proving that you agreed with the
AI's follow up response.
If it was a follow up question to the exact same
review that would have been OK. It looked like
an entirely different review that started with
a wrong basis.
The review that I posted did not have a complete
understanding. To attain a complete understanding
takes 15 pages.
The review that I posted only confirms the simple
fact that everyone has gaslighted me on for three
years:
When the measure of the behavior of the input to
HHH(DD) is DD correctly simulated by HHH then
HHH(DD)==0 is correct.
On 8/10/2025 5:10 PM, dbush wrote:
On 8/10/2025 6:07 PM, olcott wrote:
On 8/10/2025 4:56 PM, dbush wrote:
On 8/10/2025 5:53 PM, olcott wrote:
On 8/10/2025 4:50 PM, dbush wrote:
On 8/10/2025 5:42 PM, olcott wrote:
Erasing the immediate context that you are
responding to is deceitful and dishonest.
You mean like you did here (see below)?
You hypocrisy knows no bounds.
On 8/10/2025 3:06 PM, dbush wrote:
On 8/10/2025 3:02 PM, olcott wrote:
On 8/10/2025 1:57 PM, dbush wrote:;
On 8/10/2025 2:46 PM, olcott wrote:*It is physically impossible for me to trim these words*
On 8/10/2025 1:34 PM, dbush wrote:;
On 8/10/2025 2:23 PM, olcott wrote:No in other words to it.
;;
Counter-factual.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>> Â >>>>>>
In other words, your response to "X is wrong because Y" is >>>>>> "but X
is right".
;
Just the verbatim words on the above link.
And below (which you dishonestly trimmed)
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
;
And you continue to reply to "X is wrong because Y" with "but X is >>>>>> Â > right" and dishonestly trim "Y".
;
Your dishonesty knows no bounds.
That you change the subject away from the word for word
exact words of this page
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
and I ignore your change of subject and bring it back
to the point is your dishonesty not mine.
No, I responded directly to that by asking the AI a follow-up
question and you just repeated your claim, proving that you agreed
with the AI's follow up response.
If it was a follow up question to the exact same
review that would have been OK. It looked like
an entirely different review that started with
a wrong basis.
The review that I posted did not have a complete
understanding. To attain a complete understanding
takes 15 pages.
The review that I posted only confirms the simple
fact that everyone has gaslighted me on for three
years:
When the measure of the behavior of the input to
HHH(DD) is DD correctly simulated by HHH
Which it can't be because that doesn't happen, as you have admitted on
the record:
If either you misunderstood me or I made some mistake
in the past it remains true that Claude AI, ChatGPT
and Grok all provide the correct answer to this question:
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 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?
On 8/10/2025 5:50 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:34:14 -0500, olcott wrote:
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
But that would mean DD() halts
It only seems that way when you make sure to not pay enough attention.
On 8/10/2025 5:24 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:17:05 -0500, olcott wrote:
On 8/10/2025 5:10 PM, dbush wrote:
On 8/10/2025 6:07 PM, olcott wrote:If either you misunderstood me or I made some mistake in the past it
On 8/10/2025 4:56 PM, dbush wrote:
On 8/10/2025 5:53 PM, olcott wrote:If it was a follow up question to the exact same review that would
On 8/10/2025 4:50 PM, dbush wrote:No, I responded directly to that by asking the AI a follow-up
On 8/10/2025 5:42 PM, olcott wrote:
Erasing the immediate context that you are responding to is
deceitful and dishonest.
You mean like you did here (see below)?
You hypocrisy knows no bounds.
On 8/10/2025 3:06 PM, dbush wrote:
  > On 8/10/2025 3:02 PM, olcott wrote:
  >> On 8/10/2025 1:57 PM, dbush wrote:
  >>> On 8/10/2025 2:46 PM, olcott wrote:
  >>>> On 8/10/2025 1:34 PM, dbush wrote:
  >>>>> On 8/10/2025 2:23 PM, olcott wrote:
  >>>>>>
  >>>>>> Counter-factual.
  >>>>>> https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-
dc5ffe10f00c
  >>>>>>
  >>>>>>
  >>>>> In other words, your response to "X is wrong because Y" is >>>>>>>> "but X
  >>>>> is right".
  >>>>>
  >>>> No in other words to it.
  >>>> Just the verbatim words on the above link.
  >>>
  >>> And below (which you dishonestly trimmed)
  >> *It is physically impossible for me to trim these words* >>>>>>>>   >> https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>   >>
  >>
  > And you continue to reply to "X is wrong because Y" with "but X >>>>>>>>   > is right" and dishonestly trim "Y".
  >
  > Your dishonesty knows no bounds.
That you change the subject away from the word for word exact words >>>>>>> of this page
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c and I >>>>>>> ignore your change of subject and bring it back to the point is your >>>>>>> dishonesty not mine.
question and you just repeated your claim, proving that you agreed >>>>>> with the AI's follow up response.
have been OK. It looked like an entirely different review that started >>>>> with a wrong basis.
The review that I posted did not have a complete understanding. To
attain a complete understanding takes 15 pages.
The review that I posted only confirms the simple fact that everyone >>>>> has gaslighted me on for three years:
When the measure of the behavior of the input to HHH(DD) is DD
correctly simulated by HHH
Which it can't be because that doesn't happen, as you have admitted on >>>> the record:
remains true that Claude AI, ChatGPT and Grok all provide the correct
answer to this question:
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 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?
HHH(DD) should correctly return whatever DD() does. You have failed.
/Flibble
Changing the words as the basis for rebuttal is known
as the strawman error.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
On 8/10/2025 5:50 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:34:14 -0500, olcott wrote:
Changing the words as the basis for rebuttal is known as the strawman
error.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
But that would mean DD() halts so HHH(DD) got the answer wrong as per the
Halting Problem proofs. You have failed.
/Flibble
My prior reply may be incorrect. I always read and then
reread and reread. That is how I pay enough attention.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
When you fully understand that this is correct thenn
(then and only then) we can move on to the issue of
the directly executed DD().
On 8/10/2025 5:41 PM, dbush wrote:
So you just trimmed the immediate context you were responding to that
proved you wrong. And as you yourself said:
*This is my whole point everything else*
*is a deliberate attempt to deceive*
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
On 8/10/2025 6:03 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:58:18 -0500, olcott wrote:
On 8/10/2025 5:50 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:34:14 -0500, olcott wrote:
Changing the words as the basis for rebuttal is known as the strawman >>>>> error.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
But that would mean DD() halts so HHH(DD) got the answer wrong as per
the Halting Problem proofs. You have failed.
/Flibble
My prior reply may be incorrect. I always read and then reread and
reread. That is how I pay enough attention.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
When you fully understand that this is correct thenn (then and only
then) we can move on to the issue of the directly executed DD().
I fully understand your failure to refute any Halting Problem proof.
/Flibble
That you stonewall the next step of my proof is not a rebuttal.
On 8/10/2025 5:28 PM, dbush wrote:
On 8/10/2025 6:17 PM, olcott wrote:
On 8/10/2025 5:10 PM, dbush wrote:
On 8/10/2025 6:07 PM, olcott wrote:
On 8/10/2025 4:56 PM, dbush wrote:
On 8/10/2025 5:53 PM, olcott wrote:
On 8/10/2025 4:50 PM, dbush wrote:
On 8/10/2025 5:42 PM, olcott wrote:
Erasing the immediate context that you are
responding to is deceitful and dishonest.
You mean like you did here (see below)?
You hypocrisy knows no bounds.
On 8/10/2025 3:06 PM, dbush wrote:
On 8/10/2025 3:02 PM, olcott wrote:dc5ffe10f00c
On 8/10/2025 1:57 PM, dbush wrote:
On 8/10/2025 2:46 PM, olcott wrote:
On 8/10/2025 1:34 PM, dbush wrote:
On 8/10/2025 2:23 PM, olcott wrote:
;
Counter-factual.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-
;*It is physically impossible for me to trim these words*;No in other words to it.;;
In other words, your response to "X is wrong because Y" >>>>>>>> is "but X
is right".
;
Just the verbatim words on the above link.
And below (which you dishonestly trimmed)
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>> Â >>
And you continue to reply to "X is wrong because Y" with "but >>>>>>>> X is
right" and dishonestly trim "Y".
;
Your dishonesty knows no bounds.
That you change the subject away from the word for word
exact words of this page
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
and I ignore your change of subject and bring it back
to the point is your dishonesty not mine.
No, I responded directly to that by asking the AI a follow-up
question and you just repeated your claim, proving that you agreed >>>>>> with the AI's follow up response.
If it was a follow up question to the exact same
review that would have been OK. It looked like
an entirely different review that started with
a wrong basis.
The review that I posted did not have a complete
understanding. To attain a complete understanding
takes 15 pages.
The review that I posted only confirms the simple
fact that everyone has gaslighted me on for three
years:
When the measure of the behavior of the input to
HHH(DD) is DD correctly simulated by HHH
Which it can't be because that doesn't happen, as you have admitted
on the record:
If either you misunderstood me or I made some mistake
in the past it remains true that Claude AI, ChatGPT
and Grok all provide the correct answer to this question:
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 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?
But if you ask it the following clarifying question:
Doesn't this assume that a correct answer can be returned?
It did not give this conversation any deep understanding
because that takes too many pages and is overwhelming.
When the measure of the behavior of the input to HHH(DD)
is DD correctly simulated by HHH then HHH(DD)==0 is correct.
That people have been consistently gaslighting me on this
for three years is their willful deception on not my mistake.
On 8/10/2025 5:12 PM, Richard Heathfield wrote:
On 10/08/2025 22:54, olcott wrote:Not at all. I provided the technical basis for
On 8/10/2025 4:53 PM, Richard Heathfield wrote:
On 10/08/2025 22:42, olcott wrote:
<snip>
Erasing the immediate context that you are
responding to is deceitful and dishonest.
Snipping isn't erasing. Snipping is focus.
Snipping the words that you are responding to is dishonest.
On the contrary, it's an editorial decision to be made in the search
for clarity.
technical reviewers to verify that my claim
[DD is correctly simulated by HHH]
is correct and you erased this technical basis.
HHH creates a separate process context and then
emulates DD in this process context. When this DD
calls HHH(DD) the first HHH emulates and instance of
itself in the DD process context. This emulated HHH
instance creates a new process context to emulate
its instance of DD. This DD calls HHH(DD).
This code proves that technical basis is correct https://github.com/plolcott/x86utm/blob/master/Halt7.c
It is not my fault that you lack the technical capacity
to understand that.
It is your fault for asserting that my code is incorrect
on the basis of your own lack of technical ability. https://dictionary.justia.com/reckless-disregard-of-the-truth
On 8/10/2025 6:35 PM, Richard Heathfield wrote:
On 11/08/2025 00:01, olcott wrote:
On 8/10/2025 5:56 PM, dbush wrote:
*Trollish replies will be henceforth ignored*
Since you never respond constructively to anyone, I fail to see
what difference it makes.
If it makes you feel any better, I have no objection to you
killfiling me right now.
When I make every attempt at rebuttal look
ridiculously foolish that raises my credibility.
On 8/10/2025 6:24 PM, Richard Heathfield wrote:
On 10/08/2025 23:17, olcott wrote:
If either you misunderstood me or I made some mistake
in the past it remains true that Claude AI, ChatGPT
and Grok all provide the correct answer to this question:
You do realise that ChatGPT says you're talking nonsense?
Within the specific basis that they were given
they all they all agree that HHH(DD)==0 is correct.
When you change the basis that they were given that
changes everything.
ChatGPT 5.0 is a little dumber than 4.0 so it needs
to be coached.
If you want to care to understand that HHH(DD)==0
is correct on the basis that DD correctly emulated
by HHH cannot possibly reach its own "return" statement
final halt state then we can achieve mutual agreement.
When you insist that DD is not correctly emulated by
HHH when I show you this proof that it is, then it
would seem that you do not care about an honest dialogue.
On 8/10/2025 6:24 PM, Richard Heathfield wrote:
On 10/08/2025 23:17, olcott wrote:
If either you misunderstood me or I made some mistake
in the past it remains true that Claude AI, ChatGPT
and Grok all provide the correct answer to this question:
You do realise that ChatGPT says you're talking nonsense?
Within the specific basis that they were given
they all they all agree that HHH(DD)==0 is correct.
When you change the basis that they were given that
changes everything.
ChatGPT 5.0 is a little dumber than 4.0 so it needs
to be coached.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
On 8/10/2025 7:30 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 01:06:23 -0500, olcott wrote:
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
Also https://philpapers.org/archive/OLCHPS.pdf
If DD() halts and HHH(DD) returns a result of non-halting then HHH is not
a halt decider for DD: this just confirms that the extant Halting Problem
proofs are correct and that you have wasted the last 22 years.
/Flibble
<Input to LLM systems>
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 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?
</Input to LLM systems>
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
All three LLM's agree that when HHH(DD) reports on the basis
of DD correctly simulated by HHH then HHH(DD)==0 is correct.
On 8/10/2025 9:27 PM, Richard Heathfield wrote:
Yes, you have to tell it the right lies, lest it unwittingly
stumble upon the truth.
Let's try sticking wholly to the truth. I gave ChatGPT the text
between the +----+ markers, and what follows is its unedited
reply.
If you don't provide the actual link as I have
done then I will not trust the analysis.
On 8/10/2025 9:48 PM, Richard Heathfield wrote:
On 11/08/2025 03:13, olcott wrote:
If you want to care to understand that HHH(DD)==0
is correct on the basis that DD correctly emulated
by HHH cannot possibly reach its own "return" statement
final halt state then we can achieve mutual agreement.
When you insist that DD is not correctly emulated by
HHH when I show you this proof that it is, then it
would seem that you do not care about an honest dialogue.
Classic example of what I was talking about.
This is why people won't be patient with you. Your price for
talking civilly to people is that they must first agree with
your risible claims. It's a price very few people are prepared
to pay.
You don't have to agree with my claims.
If you don't agree and cannot provide
any sound basis for disagreement then
I will write you off as a troll.
On 8/10/2025 10:09 PM, Richard Heathfield wrote:
On 11/08/2025 03:59, olcott wrote:
On 8/10/2025 9:48 PM, Richard Heathfield wrote:
On 11/08/2025 03:13, olcott wrote:
If you want to care to understand that HHH(DD)==0
is correct on the basis that DD correctly emulated
by HHH cannot possibly reach its own "return" statement
final halt state then we can achieve mutual agreement.
When you insist that DD is not correctly emulated by
HHH when I show you this proof that it is, then it
would seem that you do not care about an honest dialogue.
Classic example of what I was talking about.
This is why people won't be patient with you. Your price for
talking civilly to people is that they must first agree with
your risible claims. It's a price very few people are
prepared to pay.
You don't have to agree with my claims.
And you don't have to act like a grown-up.
If you don't agree and cannot provide
any sound basis for disagreement then
I will write you off as a troll.
You and I clearly disagree on what constitutes
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
On 8/10/2025 10:00 PM, Richard Heathfield wrote:
On 11/08/2025 03:35, olcott wrote:
On 8/10/2025 9:27 PM, Richard Heathfield wrote:
<snip>
Yes, you have to tell it the right lies, lest it unwittingly
stumble upon the truth.
Let's try sticking wholly to the truth. I gave ChatGPT the
text between the +----+ markers, and what follows is its
unedited reply.
If you don't provide the actual link as I have
done then I will not trust the analysis.
Whatever, dude. If you just didn't trust me but were interested
in the truth, you'd have started a new chat in ChatGPT and
copied and posted to it the question I asked so that you could
see for yourself what it says.
The fact that you did not do so is telling.
If you did this chat then simply post the link.
You may have used the dumber 5.0. I need to see
the actual conversation.
I have all of my
conversations saved on each LLM.
On 8/10/2025 1:37 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 08:06 schreef olcott:
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
Also
https://philpapers.org/archive/OLCHPS.pdf
Yes, you succeeded to feed the AI with your incorrect dreams and now
it is able to reproduce the same wrong conclusions from the same
incorrect and contradictory assumptions.
Even a beginning C programmer understands that DD halts when HHH
returns 0. Indeed, an expert will understand it and see that it is
incorrect.
We cannot proceed until after you understand that
everything the paper says is correct.
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() halts. >>>>>>>>>You told Claude to believe that, and like a good AI he does
what you
tell him.
I suspect if you specifically told Claude that HHH was supposed >>>>>>>> to be a
halt decider and it was an attempt to refute the Halting Problem >>>>>>>> proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly
simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct?
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by failing to
show where in the Intel instruction manual the execution of any
instruction other than HLT is allowed to stop instead of executing the
next instruction, you're stating that you're now going to show us
where that is.
Failing to do so in your next reply or within one hour of your next
post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification*
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/11/2025 10:08 AM, wij wrote:Questions don't have truth values.
On Mon, 2025-08-11 at 10:02 -0500, olcott wrote:
On 8/11/2025 9:49 AM, wij wrote:
On Mon, 2025-08-11 at 09:20 -0500, olcott wrote:
On 8/11/2025 9:07 AM, wij wrote:
On Mon, 2025-08-11 at 00:25 -0500, olcott wrote:
On 8/10/2025 11:21 AM, wij wrote:
What method?If HHH does not refute the HP, I can understand. But how would it >>>>>>>> be useful for the mankind and AI?My method can be applied to defining a
Both would be ~True.Yes, but how do we solve the basic logic problem:The ultimate test for a Boolean True(Language L, Expression e)
Q1: What time is it? Yes or no.
Q2: Jack is a bachelor. Does Jack hit his wife?
Q1,Q2 are essentially the same as the halting decider. E.g. we can
have H5:
int H5(Problem D5);Â // H5(D5)==1 iff Problem D5 is true
What should H5(Q1) return?
predicate is this True("English", "This sentence is not true").
I have difficulty to follow. Would you use Q1,Q2 to explain?
What should H5(Q1) return? And why?
It works the same way that Prolog works.Only in a complete system.
~Provable(L,x) means untrue(L,x)
On 8/11/2025 10:47 AM, joes wrote:
Am Mon, 11 Aug 2025 10:29:33 -0500 schrieb olcott:
On 8/11/2025 10:08 AM, wij wrote:
On Mon, 2025-08-11 at 10:02 -0500, olcott wrote:
On 8/11/2025 9:49 AM, wij wrote:
Questions don't have truth values.Both would be ~True.Yes, but how do we solve the basic logic problem:The ultimate test for a Boolean True(Language L, Expression e)
Q1: What time is it? Yes or no.
Q2: Jack is a bachelor. Does Jack hit his wife?
Q1,Q2 are essentially the same as the halting decider. E.g. we can >>>>>> have H5:
int H5(Problem D5);Â // H5(D5)==1 iff Problem D5 is true What
should H5(Q1) return?
predicate is this True("English", "This sentence is not true").
I have difficulty to follow. Would you use Q1,Q2 to explain?
What should H5(Q1) return? And why?
I mean, if a sentence is not true, its negation must be.The only way that systems have been shown to be incomplete isIt works the same way that Prolog works.Only in a complete system.
~Provable(L,x) means untrue(L,x)
incorrectly assuming that a non-truth bearer expression must be true or false.
On 8/11/2025 10:40 AM, wij wrote:Uh, it does mean that, unless you're working in multivalent or
On Mon, 2025-08-11 at 10:29 -0500, olcott wrote:
On 8/11/2025 10:08 AM, wij wrote:
~True(L,x) does not mean false. Random gibberish is also ~True.I have difficulty to follow. Would you use Q1,Q2 to explain?Both would be ~True.
What should H5(Q1) return? And why?
It works the same way that Prolog works.
~Provable(L,x) means untrue(L,x)
So you mean H5(Q1) should tell us the correct reply to "What time is
it" is "no"?
On 8/11/2025 5:55 PM, dbush wrote:
On 8/11/2025 6:52 PM, olcott wrote:
On 8/11/2025 5:45 PM, dbush wrote:Then you admit your spec violates the x86 language by allowing an
On 8/11/2025 6:37 PM, olcott wrote:
On 8/11/2025 5:32 PM, dbush wrote:In other words, your spec violates the x86 language despite you
On 8/11/2025 6:28 PM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
_DDD()
[00002192] 55        push ebp [00002193] 8bec      mov ebp,esp
[00002195] 6892210000 push 00002192Â // push DDD [0000219a]
e833f4ffff call 000015d2 // call HHH [0000219f] 83c404    add >>>>>>> esp,+04 [000021a2] 5d        pop ebp [000021a3] c3        ret
Size in bytes:(0018) [000021a3]
DDD correctly simulated by simulating termination analyzer HHH
cannot possibly reach its own "return" statement final halt state >>>>>>> and DDD() halts.
The x86 code proves beyond all doubt that DDD is emulated by HHH >>>>>>> according to the definition of the x86 language
False, because HHH aborts in violation of the x86 language
I keep correcting you again any again and you immediately forget Do
you really have attention deficit disorder?
*DD is correctly emulated by HHH according to this spec*
saying that HHH obeys it.
One cannot *arbitrarily* define to notion of a simulating termination
decider out-of-existence within an honest dialogue. This crosses the
line into a dishonesty.
abort.
You can't say it "correctly simulates" if it aborts.
HHH correctly simulates N instructions of DD which is enough for three
LLM systems to detect the *recursive simulation non-halting behavior
pattern*
I didn't even tell them that this pattern exists. They figured it out
all on their own.
On 8/11/2025 6:47 PM, Mr Flibble wrote:
On Mon, 11 Aug 2025 18:43:58 -0500, olcott wrote:
On 8/11/2025 5:55 PM, dbush wrote:
On 8/11/2025 6:52 PM, olcott wrote:
On 8/11/2025 5:45 PM, dbush wrote:Then you admit your spec violates the x86 language by allowing an
On 8/11/2025 6:37 PM, olcott wrote:
On 8/11/2025 5:32 PM, dbush wrote:In other words, your spec violates the x86 language despite you
On 8/11/2025 6:28 PM, olcott wrote:
void DDD()
{
  HHH(DDD);
  return;
}
_DDD()
[00002192] 55        push ebp [00002193] 8bec      mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD [0000219a] >>>>>>>>> e833f4ffff call 000015d2 // call HHH [0000219f] 83c404    add >>>>>>>>> esp,+04 [000021a2] 5d        pop ebp [000021a3] c3        ret
Size in bytes:(0018) [000021a3]
DDD correctly simulated by simulating termination analyzer HHH >>>>>>>>> cannot possibly reach its own "return" statement final halt
state and DDD() halts.
The x86 code proves beyond all doubt that DDD is emulated by HHH >>>>>>>>> according to the definition of the x86 language
False, because HHH aborts in violation of the x86 language
I keep correcting you again any again and you immediately forget >>>>>>> Do you really have attention deficit disorder?
*DD is correctly emulated by HHH according to this spec*
saying that HHH obeys it.
One cannot *arbitrarily* define to notion of a simulating
termination decider out-of-existence within an honest dialogue. This >>>>> crosses the line into a dishonesty.
abort.
You can't say it "correctly simulates" if it aborts.
HHH correctly simulates N instructions of DD which is enough for three
LLM systems to detect the *recursive simulation non-halting behavior
pattern*
I didn't even tell them that this pattern exists. They figured it out
all on their own.
The simulation isn't correct tho as the halting result (non-halting) is
the opposite of what DD() does (halts).
/Flibble
In other words you believe that you can simply ignore the fact that DD specifies a different sequence of steps to HHH than it does to main().
On 8/11/2025 6:47 PM, Mr Flibble wrote:
On Mon, 11 Aug 2025 18:43:58 -0500, olcott wrote:
On 8/11/2025 5:55 PM, dbush wrote:
On 8/11/2025 6:52 PM, olcott wrote:
On 8/11/2025 5:45 PM, dbush wrote:Then you admit your spec violates the x86 language by allowing an
On 8/11/2025 6:37 PM, olcott wrote:
On 8/11/2025 5:32 PM, dbush wrote:In other words, your spec violates the x86 language despite you
On 8/11/2025 6:28 PM, olcott wrote:
void DDD()
{
   HHH(DDD);
   return;
}
_DDD()
[00002192] 55        push ebp [00002193] 8bec      mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD [0000219a] >>>>>>>>> e833f4ffff call 000015d2 // call HHH [0000219f] 83c404    add >>>>>>>>> esp,+04 [000021a2] 5d        pop ebp [000021a3] c3        ret
Size in bytes:(0018) [000021a3]
DDD correctly simulated by simulating termination analyzer HHH >>>>>>>>> cannot possibly reach its own "return" statement final halt state >>>>>>>>> and DDD() halts.
The x86 code proves beyond all doubt that DDD is emulated by HHH >>>>>>>>> according to the definition of the x86 language
False, because HHH aborts in violation of the x86 language
I keep correcting you again any again and you immediately forget Do >>>>>>> you really have attention deficit disorder?
*DD is correctly emulated by HHH according to this spec*
saying that HHH obeys it.
One cannot *arbitrarily* define to notion of a simulating termination >>>>> decider out-of-existence within an honest dialogue. This crosses the >>>>> line into a dishonesty.
abort.
You can't say it "correctly simulates" if it aborts.
HHH correctly simulates N instructions of DD which is enough for three
LLM systems to detect the *recursive simulation non-halting behavior
pattern*
I didn't even tell them that this pattern exists. They figured it out
all on their own.
The simulation isn't correct tho as the halting result (non-halting) is
the opposite of what DD() does (halts).
/Flibble
In other words you believe that you can simply
ignore the fact that DD specifies a different
sequence of steps to HHH than it does to main().
On 8/11/2025 7:23 PM, Mr Flibble wrote:
On Mon, 11 Aug 2025 19:03:19 -0500, olcott wrote:
On 8/11/2025 6:47 PM, Mr Flibble wrote:
On Mon, 11 Aug 2025 18:43:58 -0500, olcott wrote:
On 8/11/2025 5:55 PM, dbush wrote:
On 8/11/2025 6:52 PM, olcott wrote:
On 8/11/2025 5:45 PM, dbush wrote:Then you admit your spec violates the x86 language by allowing an
On 8/11/2025 6:37 PM, olcott wrote:
On 8/11/2025 5:32 PM, dbush wrote:In other words, your spec violates the x86 language despite you >>>>>>>> saying that HHH obeys it.
On 8/11/2025 6:28 PM, olcott wrote:
void DDD()
{
   HHH(DDD);
   return;
}
_DDD()
[00002192] 55        push ebp [00002193] 8bec      mov ebp,esp
[00002195] 6892210000 push 00002192Â // push DDD [0000219a] >>>>>>>>>>> e833f4ffff call 000015d2Â // call HHH [0000219f] 83c404Â Â Â Â add
esp,+04 [000021a2] 5d        pop ebp [000021a3] c3        ret
Size in bytes:(0018) [000021a3]
DDD correctly simulated by simulating termination analyzer HHH >>>>>>>>>>> cannot possibly reach its own "return" statement final halt >>>>>>>>>>> state and DDD() halts.
The x86 code proves beyond all doubt that DDD is emulated by HHH >>>>>>>>>>> according to the definition of the x86 language
False, because HHH aborts in violation of the x86 language
I keep correcting you again any again and you immediately forget >>>>>>>>> Do you really have attention deficit disorder?
*DD is correctly emulated by HHH according to this spec*
One cannot *arbitrarily* define to notion of a simulating
termination decider out-of-existence within an honest dialogue. This >>>>>>> crosses the line into a dishonesty.
abort.
You can't say it "correctly simulates" if it aborts.
HHH correctly simulates N instructions of DD which is enough for three >>>>> LLM systems to detect the *recursive simulation non-halting behavior >>>>> pattern*
I didn't even tell them that this pattern exists. They figured it out >>>>> all on their own.
The simulation isn't correct tho as the halting result (non-halting) is >>>> the opposite of what DD() does (halts).
/Flibble
In other words you believe that you can simply ignore the fact that DD
specifies a different sequence of steps to HHH than it does to main().
No, I believe the Halting Problem has been proven which is why DD() does
the opposite of what HHH(DD) returns.
/Flibble
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
If you are an expert C programmer you know that
DD correctly simulated by HHH cannot possibly
reach the "do the opposite" part.
DD keeps calling HHH(DD) in recursive simulation
never reaching its own "if" statement.
On 8/11/2025 11:51 AM, joes wrote:
Am Mon, 11 Aug 2025 10:43:31 -0500 schrieb olcott:
On 8/11/2025 10:40 AM, wij wrote:Uh, it does mean that, unless you're working in multivalent or
On Mon, 2025-08-11 at 10:29 -0500, olcott wrote:
On 8/11/2025 10:08 AM, wij wrote:
~True(L,x) does not mean false. Random gibberish is also ~True.I have difficulty to follow. Would you use Q1,Q2 to explain?Both would be ~True.
What should H5(Q1) return? And why?
It works the same way that Prolog works.
~Provable(L,x) means untrue(L,x)
So you mean H5(Q1) should tell us the correct reply to "What time is
it" is "no"?
intuitonistic logics where the law of the excluded middle doesn't
exist. (I had to look that up.)
The negation of gibberish is still gibberish.
We are working with a system that has all
of the basic facts of the world encoded
as formalized natural language expressions.
The only inference rule in the above formal
system is semantic logical inference.
When any expression cannot be proven on this
basis (just like Prolog facts and rules) then
the expression is deemed untrue.
On 8/11/2025 3:20 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 16:08 schreef olcott:
On 8/10/2025 1:37 AM, Fred. Zwarts wrote:This will not happen, before you fix your errors in the input of the AI.
Op 10.aug.2025 om 08:06 schreef olcott:
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
Also
https://philpapers.org/archive/OLCHPS.pdf
Yes, you succeeded to feed the AI with your incorrect dreams and now
it is able to reproduce the same wrong conclusions from the same
incorrect and contradictory assumptions.
Even a beginning C programmer understands that DD halts when HHH
returns 0. Indeed, an expert will understand it and see that it is
incorrect.
We cannot proceed until after you understand that
everything the paper says is correct.
The notion of a termination analyzer is well known in the literature.
AProVE: Non-Termination Witnesses for C Programs: The termination status decision is made on the basis of the dynamic behavior of the input. https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf
<Input to LLM systems>
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 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?
<Input to LLM systems>
HHH works correctly on these inputs.
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote: >>>>>>>>>>
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() >>>>>>>>>>>> halts.
You told Claude to believe that, and like a good AI he does >>>>>>>>>>> what you
tell him.
I suspect if you specifically told Claude that HHH was
supposed to be a
halt decider and it was an attempt to refute the Halting
Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly
simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct?
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by failing
to show where in the Intel instruction manual the execution of any
instruction other than HLT is allowed to stop instead of executing
the next instruction, you're stating that you're now going to show
us where that is.
Failing to do so in your next reply or within one hour of your next
post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification*
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite,
because it does not take into account the conditional branch
instructions. It makes the wrong conclusion that there is non-
termination behaviour and prematurely aborts the simulation.
(b) Simulated input reaches its simulated "return" statement: return 1.
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.
That generic HHH(DD) specifies
 HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
until the
*recursive simulation non-halting behavior pattern*
is matched.
All three LLM systems figured this out on their own.
I did not tell them about the
*recursive simulation non-halting behavior pattern*
or the value that HHH(DD) should return.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
On 8/11/2025 11:51 AM, joes wrote:
Am Mon, 11 Aug 2025 10:43:31 -0500 schrieb olcott:
On 8/11/2025 10:40 AM, wij wrote:Uh, it does mean that, unless you're working in multivalent or
On Mon, 2025-08-11 at 10:29 -0500, olcott wrote:
On 8/11/2025 10:08 AM, wij wrote:
~True(L,x) does not mean false. Random gibberish is also ~True.I have difficulty to follow. Would you use Q1,Q2 to explain?Both would be ~True.
What should H5(Q1) return? And why?
It works the same way that Prolog works.
~Provable(L,x) means untrue(L,x)
So you mean H5(Q1) should tell us the correct reply to "What time is
it" is "no"?
intuitonistic logics where the law of the excluded middle doesn't
exist. (I had to look that up.)
The negation of gibberish is still gibberish.
We are working with a system that has all
of the basic facts of the world encoded
as formalized natural language expressions.
The only inference rule in the above formal
system is semantic logical inference.
When any expression cannot be proven on this
basis (just like Prolog facts and rules) then
the expression is deemed untrue.
On 8/12/2025 12:01 PM, dbush wrote:
On 8/12/2025 1:01 PM, olcott wrote:
On 8/12/2025 5:54 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:58 schreef olcott:
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote: >>>>>>>>>>>>>>
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though >>>>>>>>>>>>>>>> DD() halts.
You told Claude to believe that, and like a good AI he >>>>>>>>>>>>>>> does what you
tell him.
I suspect if you specifically told Claude that HHH was >>>>>>>>>>>>>> supposed to be a
halt decider and it was an attempt to refute the Halting >>>>>>>>>>>>>> Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly >>>>>>>>>>>> simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct? >>>>>>>>>>
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by
failing to show where in the Intel instruction manual the
execution of any instruction other than HLT is allowed to stop >>>>>>>> instead of executing the next instruction, you're stating that >>>>>>>> you're now going to show us where that is.
Failing to do so in your next reply or within one hour of your >>>>>>>> next post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification*
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern: abort simulation >>>>>>> and return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite,
We are not looking at whether the recursion stops
running. We are looking at whether DD correctly
simulated by any HHH of the infinite set of HHH
Changing the input is not allowed.
In other words you disagree with mathematical induction.
On 8/12/2025 12:14 PM, dbush wrote:
On 8/12/2025 1:08 PM, olcott wrote:
On 8/12/2025 12:01 PM, dbush wrote:
On 8/12/2025 1:01 PM, olcott wrote:
On 8/12/2025 5:54 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:58 schreef olcott:
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield >>>>>>>>>>>>>>>> wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though >>>>>>>>>>>>>>>>>> DD() halts.
You told Claude to believe that, and like a good AI he >>>>>>>>>>>>>>>>> does what you
tell him.
I suspect if you specifically told Claude that HHH was >>>>>>>>>>>>>>>> supposed to be a
halt decider and it was an attempt to refute the Halting >>>>>>>>>>>>>>>> Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions >>>>>>>>>>>>>>> as its basis.
So does this: "Simulating Termination Analyzer HHH >>>>>>>>>>>>>> correctly simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT >>>>>>>>>>>> correct?
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by >>>>>>>>>> failing to show where in the Intel instruction manual the
execution of any instruction other than HLT is allowed to stop >>>>>>>>>> instead of executing the next instruction, you're stating that >>>>>>>>>> you're now going to show us where that is.
Failing to do so in your next reply or within one hour of your >>>>>>>>>> next post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification* >>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite,
We are not looking at whether the recursion stops
running. We are looking at whether DD correctly
simulated by any HHH of the infinite set of HHH
Changing the input is not allowed.
In other words you disagree with mathematical induction.
Mathematical induction doesn't allow changing the input, which is what
you're doing.
Changing the input is not allowed.
Mathematical induction simultaneously tests
every input of an infinite set of inputs.
On 8/12/2025 12:31 PM, dbush wrote:
On 8/12/2025 1:18 PM, olcott wrote:
On 8/12/2025 12:14 PM, dbush wrote:
On 8/12/2025 1:08 PM, olcott wrote:
On 8/12/2025 12:01 PM, dbush wrote:
On 8/12/2025 1:01 PM, olcott wrote:
On 8/12/2025 5:54 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:58 schreef olcott:We are not looking at whether the recursion stops
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield >>>>>>>>>>>>>>>>>> wrote:
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even >>>>>>>>>>>>>>>>>>>> though DD() halts.
You told Claude to believe that, and like a good AI >>>>>>>>>>>>>>>>>>> he does what you
tell him.
I suspect if you specifically told Claude that HHH was >>>>>>>>>>>>>>>>>> supposed to be a
halt decider and it was an attempt to refute the >>>>>>>>>>>>>>>>>> Halting Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions >>>>>>>>>>>>>>>>> as its basis.
So does this: "Simulating Termination Analyzer HHH >>>>>>>>>>>>>>>> correctly simulates its input"
That you refuse to understand how the simulation >>>>>>>>>>>>>>> is correct
You mean the one that you admitted on the record is NOT >>>>>>>>>>>>>> correct?
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according >>>>>>>>>>>>> to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply >>>>>>>>>>>>> to you is deprecated.
So in other words, because you prior admission was made by >>>>>>>>>>>> failing to show where in the Intel instruction manual the >>>>>>>>>>>> execution of any instruction other than HLT is allowed to >>>>>>>>>>>> stop instead of executing the next instruction, you're >>>>>>>>>>>> stating that you're now going to show us where that is. >>>>>>>>>>>>
Failing to do so in your next reply or within one hour of >>>>>>>>>>>> your next post in this newsgroup means your admission stands. >>>>>>>>>>>>
*No that is merely you dishonestly ignoring the specification* >>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its >>>>>>>>>>> input until:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite, >>>>>>>
running. We are looking at whether DD correctly
simulated by any HHH of the infinite set of HHH
Changing the input is not allowed.
In other words you disagree with mathematical induction.
Mathematical induction doesn't allow changing the input, which is
what you're doing.
Changing the input is not allowed.
Mathematical induction simultaneously tests
every input of an infinite set of inputs.
So you admit to changing the input.
Changing the input is not allowed.
Changing the input in this way is REQUIRED.
On 8/12/2025 5:54 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:58 schreef olcott:
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote: >>>>>>>>>>>>
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() >>>>>>>>>>>>>> halts.
You told Claude to believe that, and like a good AI he does >>>>>>>>>>>>> what you
tell him.
I suspect if you specifically told Claude that HHH was >>>>>>>>>>>> supposed to be a
halt decider and it was an attempt to refute the Halting >>>>>>>>>>>> Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly >>>>>>>>>> simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct? >>>>>>>>
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by failing >>>>>> to show where in the Intel instruction manual the execution of any >>>>>> instruction other than HLT is allowed to stop instead of executing >>>>>> the next instruction, you're stating that you're now going to show >>>>>> us where that is.
Failing to do so in your next reply or within one hour of your
next post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification*
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite,
We are not looking at whether the recursion stops
running. We are looking at whether DD correctly
simulated by any HHH of the infinite set of HHH
can possibly reach its final halt state.
It is non halting behavior that HHH recognizes in a
finite number of steps.
On 8/12/2025 9:34 PM, dbush wrote:
On 8/12/2025 10:28 PM, olcott wrote:
On 8/12/2025 9:19 PM, dbush wrote:
On 8/12/2025 10:16 PM, olcott wrote:
On 8/12/2025 8:59 PM, Chris M. Thomasson wrote:
On 8/12/2025 10:37 AM, dbush wrote:
On 8/12/2025 1:36 PM, olcott wrote:[...]
Changing the input
Is not allowed.
olcott needs the reading rainbow?
https://youtu.be/4Ygs3IHJ2bM
Humm...
*Changing the input has always been required*
In other words, HHH(DD) decides on a non-input.
Not at all.
Yes. HHH(DD) is given the fixed code of the function DD, the fixed
code of the function HHH, and the fixed code of everything it calls
down to the OS level.
*That is not the way the actual proofs work*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Ĥ.embedded_H is every Turing machine decider
of the infinite set of Turing machine deciders.
Perhaps you don't have sufficient technical
competence in this field?
So HHH makes a decision based on *any* of that changing, you're
deciding on a non-input.
On 8/12/2025 10:48 PM, Richard Damon wrote:
On 8/12/25 10:39 PM, olcott wrote:
On 8/12/2025 9:34 PM, dbush wrote:
On 8/12/2025 10:28 PM, olcott wrote:
On 8/12/2025 9:19 PM, dbush wrote:
On 8/12/2025 10:16 PM, olcott wrote:
On 8/12/2025 8:59 PM, Chris M. Thomasson wrote:
On 8/12/2025 10:37 AM, dbush wrote:
On 8/12/2025 1:36 PM, olcott wrote:[...]
Changing the input
Is not allowed.
olcott needs the reading rainbow?
https://youtu.be/4Ygs3IHJ2bM
Humm...
*Changing the input has always been required*
Don't know if you caught this part where he's now explicitly admitting
to changing the input.
It started with this:
On 8/12/2025 1:36 PM, olcott wrote:
On 8/12/2025 12:31 PM, dbush wrote:
On 8/12/2025 1:18 PM, olcott wrote:
On 8/12/2025 12:14 PM, dbush wrote:
Mathematical induction doesn't allow changing the input, which is
what you're doing.
Changing the input is not allowed.
Mathematical induction simultaneously tests
every input of an infinite set of inputs.
So you admit to changing the input.
Changing the input is not allowed.
Changing the input in this way is REQUIRED.
In other words, HHH(DD) decides on a non-input.
Not at all.
Yes. HHH(DD) is given the fixed code of the function DD, the fixed
code of the function HHH, and the fixed code of everything it calls
down to the OS level.
*That is not the way the actual proofs work*
Sure it does.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Ĥ.embedded_H is every Turing machine decider
of the infinite set of Turing machine deciders.
No, Ĥ.embedded_H is the SPECIFIC decider that we have chosen to prove
it wrong, that is the H that we are giving this input to.
Perhaps you don't have sufficient technical
competence in this field?
Maybe you can't understand what you read, because you don't know what
the words mean.
H was a SPECIFIC decider chosen from the set of halt deciders.
Ĥ is a SPECIFIC program built from that H in a way that creates a
pathological relationship between the algorithm of the decider and the
behavior of Ĥ
Ĥ is then given the representation of itself, so it can ask H to
decide on itself given a representation of itself, and then it does
the opposite, so whatever H decides will be wrong.
To claim the input doesn't represent Ĥ applied to its representation
say you lied when you built Ĥ, as that was its actual specification.
Sorry, all you are doing is showing that you like to rotely parrot
words you don't understand because it sounds smart to you, and then
claim what you want, which is just an act of lying.
So HHH makes a decision based on *any* of that changing, you're
deciding on a non-input.
On 8/12/2025 9:52 PM, dbush wrote:
On 8/12/2025 10:39 PM, olcott wrote:
On 8/12/2025 9:34 PM, dbush wrote:
On 8/12/2025 10:28 PM, olcott wrote:
On 8/12/2025 9:19 PM, dbush wrote:
On 8/12/2025 10:16 PM, olcott wrote:
On 8/12/2025 8:59 PM, Chris M. Thomasson wrote:
On 8/12/2025 10:37 AM, dbush wrote:
On 8/12/2025 1:36 PM, olcott wrote:[...]
Changing the input
Is not allowed.
olcott needs the reading rainbow?
https://youtu.be/4Ygs3IHJ2bM
Humm...
*Changing the input has always been required*
In other words, HHH(DD) decides on a non-input.
Not at all.
Yes. HHH(DD) is given the fixed code of the function DD, the fixed
code of the function HHH, and the fixed code of everything it calls
down to the OS level.
*That is not the way the actual proofs work*
Yes it is. The first line of the Linz proof:
---------------
We assume the contrary, namely that there exists *an algorithm*,
and consequently some *Turing machine H*, that solves the halting problem
---------------
i.e. it assumes *one* fixed immutable set of instructions that do this:
Every since I studied Montague Grammar mathematical
specification for the meaning of words I have been
able to focus my attention of exactly what some words
precisely say.
*some Turing machine H* of the infinite set of all
Turing machines.
My own knowledge of the theory of computation is limited
to the halting problem proofs and Turing machines.
I was shocked to find out the limits of computable
functions a few years ago in this forum. Hardly
anyone knew how to translate these limitations into
modern software engineering terms. It turned out to
be quite simple.
On 8/12/2025 5:54 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:58 schreef olcott:
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote: >>>>>>>>>>>>
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though DD() >>>>>>>>>>>>>> halts.
You told Claude to believe that, and like a good AI he does >>>>>>>>>>>>> what you
tell him.
I suspect if you specifically told Claude that HHH was >>>>>>>>>>>> supposed to be a
halt decider and it was an attempt to refute the Halting >>>>>>>>>>>> Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly >>>>>>>>>> simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct? >>>>>>>>
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by failing >>>>>> to show where in the Intel instruction manual the execution of any >>>>>> instruction other than HLT is allowed to stop instead of executing >>>>>> the next instruction, you're stating that you're now going to show >>>>>> us where that is.
Failing to do so in your next reply or within one hour of your
next post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification*
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite,
We are not looking at whether the recursion stops
running. We are looking at whether DD correctly
simulated by any HHH of the infinite set of HHH
can possibly reach its final halt state.
It is non halting behavior that HHH recognizes in a
finite number of steps.
On 8/13/2025 3:40 AM, Fred. Zwarts wrote:
Op 12.aug.2025 om 19:01 schreef olcott:
On 8/12/2025 5:54 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:58 schreef olcott:
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote: >>>>>>>>>>>>>>
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though >>>>>>>>>>>>>>>> DD() halts.
You told Claude to believe that, and like a good AI he >>>>>>>>>>>>>>> does what you
tell him.
I suspect if you specifically told Claude that HHH was >>>>>>>>>>>>>> supposed to be a
halt decider and it was an attempt to refute the Halting >>>>>>>>>>>>>> Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly >>>>>>>>>>>> simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct? >>>>>>>>>>
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by
failing to show where in the Intel instruction manual the
execution of any instruction other than HLT is allowed to stop >>>>>>>> instead of executing the next instruction, you're stating that >>>>>>>> you're now going to show us where that is.
Failing to do so in your next reply or within one hour of your >>>>>>>> next post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification*
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern: abort simulation >>>>>>> and return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite,
We are not looking at whether the recursion stops
running. We are looking at whether DD correctly
simulated by any HHH of the infinite set of HHH
can possibly reach its final halt state.
Incorrect and irrelevant. We are not looking for a HHH that fails to
reach the final halt state. We are looking at the specification of the
input. If HHH misses parts of the specification, it is just wrong.
It is non halting behavior that HHH recognizes in a
finite number of steps.
No, it has a bug so that it incorrectly thinks that a finite recursion
with conditional branch instructions is a non-halting pattern
When HHH(DD) aborts its simulation of DD it recognizes
that there does not exist N steps of correct simulation
of DD where the simulated DD reaches its own simulated
final halt state.
You keep confusing halting with stopping running, they
are not the same.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
and aborts, where better simulators show that when the simulation is
continued, the final halt state specified in the input can be reached.
It is not a better simulator. Both cases use the world
class x86 emulator x86emulib.
HHH1(DD) benefits from HHH(DD) having already
aborted its emulation.
HHH(DD) has no such benefit.
There is non non-halting behaviour specified in the input. Therefore,
HHH fails when it pretends that it has detected it.
On 8/13/2025 3:40 AM, Fred. Zwarts wrote:
Op 12.aug.2025 om 19:01 schreef olcott:
On 8/12/2025 5:54 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:58 schreef olcott:
On 8/11/2025 3:25 AM, Fred. Zwarts wrote:
Op 10.aug.2025 om 20:58 schreef olcott:
On 8/10/2025 1:52 PM, dbush wrote:
On 8/10/2025 2:44 PM, olcott wrote:
On 8/10/2025 1:37 PM, dbush wrote:
On 8/10/2025 2:30 PM, olcott wrote:
On 8/10/2025 1:24 PM, Richard Heathfield wrote:
On 10/08/2025 19:21, olcott wrote:
On 8/10/2025 11:59 AM, Mr Flibble wrote:
On Sun, 10 Aug 2025 17:55:31 +0100, Richard Heathfield wrote: >>>>>>>>>>>>>>
On 10/08/2025 17:43, olcott wrote:
Claude AI says that HHH(DD)==0 is correct even though >>>>>>>>>>>>>>>> DD() halts.
You told Claude to believe that, and like a good AI he >>>>>>>>>>>>>>> does what you
tell him.
I suspect if you specifically told Claude that HHH was >>>>>>>>>>>>>> supposed to be a
halt decider and it was an attempt to refute the Halting >>>>>>>>>>>>>> Problem proofs it
would give a different response.
/Flibble
That would cause it to begin with false assumptions
as its basis.
So does this: "Simulating Termination Analyzer HHH correctly >>>>>>>>>>>> simulates its input"
That you refuse to understand how the simulation
is correct
You mean the one that you admitted on the record is NOT correct? >>>>>>>>>>
The simulation of DD by HHH is proven to be correct
on the basis of the emulation of DD by HHH according
to the definition of the x86 language.
Everything else that anyone ever said about this
has always been incorrect. Just for you not for
anyone else anything that I said prior to this reply
to you is deprecated.
So in other words, because you prior admission was made by
failing to show where in the Intel instruction manual the
execution of any instruction other than HLT is allowed to stop >>>>>>>> instead of executing the next instruction, you're stating that >>>>>>>> you're now going to show us where that is.
Failing to do so in your next reply or within one hour of your >>>>>>>> next post in this newsgroup means your admission stands.
*No that is merely you dishonestly ignoring the specification*
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern: abort simulation >>>>>>> and return 0.
Incorrect. It must be:
(a) Sees a finite recursion and fails to see that it is finite,
We are not looking at whether the recursion stops
running. We are looking at whether DD correctly
simulated by any HHH of the infinite set of HHH
can possibly reach its final halt state.
Incorrect and irrelevant. We are not looking for a HHH that fails to
reach the final halt state. We are looking at the specification of the
input. If HHH misses parts of the specification, it is just wrong.
It is non halting behavior that HHH recognizes in a
finite number of steps.
No, it has a bug so that it incorrectly thinks that a finite recursion
with conditional branch instructions is a non-halting pattern
When HHH(DD) aborts its simulation of DD it recognizes
that there does not exist N steps of correct simulation
of DD where the simulated DD reaches its own simulated
final halt state.
You keep confusing halting with stopping running, they
are not the same.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
and aborts, where better simulators show that when the simulation is
continued, the final halt state specified in the input can be reached.
It is not a better simulator. Both cases use the world
class x86 emulator x86emulib.
HHH1(DD) benefits from HHH(DD) having already
aborted its emulation.
HHH(DD) has no such benefit.
There is non non-halting behaviour specified in the input. Therefore,
HHH fails when it pretends that it has detected it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 09:43:16 |
| Calls: | 10,389 |
| Calls today: | 4 |
| Files: | 14,061 |
| Messages: | 6,416,844 |
| Posted today: | 1 |