On 13/08/2025 06:30, olcott wrote:

You ask: How is this answer not self-evident ?

Simulating Termination Analyzer HHH correctly simulates its input

To you, the above is self-evident. To me (and to several others
here), it is not. Your attempts to explain it with x86 traces are
unconvincing because they lack explanatory power.

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?

Well, it can't return a correct value, because no matter what it
reports DD will turn on its head. And *that* is self-evident.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Feel free to explain how it *is* self-evident.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 07:05, olcott wrote:

On 8/13/2025 12:56 AM, Lawrence D'Oliveiro wrote:

Feel free to explain how it *is* self-evident.

typedef int (*ptr)();
int HHH(ptr P);

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

I can directly see that that when HHH(DD) is executed
that this begins simulating DD that calls HHH(DD) that
begins simulating DD that calls HHH(DD) again.

...and when HHH eventually reports?

But of course that's self-evident.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 06:59, olcott wrote:

On 8/13/2025 12:43 AM, Richard Heathfield wrote:

On 13/08/2025 06:30, olcott wrote:

You ask: How is this answer not self-evident ?

Simulating Termination Analyzer HHH correctly simulates its input

To you, the above is self-evident. To me (and to several others
here), it is not. Your attempts to explain it with x86 traces
are unconvincing because they lack explanatory power.

So you cannot see that when HHH(DD) is executed that
this begins simulating DD that calls HHH(DD) that
begins simulating DD that calls HHH(DD) again ???

You are skipping lightly over the word "correctly".

To you, clearly, your work is flawless. I realise that that's
never going to change no matter what anyone says, but there are
those of us who disagree with you.

We have explained why until we're blue in the face. I see no
value in going for magenta.


<snip>

What value should HHH(DD) correctly return?

Well, it can't return a correct value, because no matter what
it reports DD will turn on its head. And *that* is self-evident.

Can you see how DD correctly simulated by HHH never
reaches its "if" statement?

No, and I can't see how it's relevant even if your claim of
correctness were true.

(a) "correctly" is subject to debate, at the very least;
(b) DD correctly executed directly on its host platform CAN reach
its "if" statement as soon as HHH reports. If HHH fails to
report, it's not a decider.
(c) as soon as DD correctly executed directly on its host
platform DOES reach its "if" statement, you're screwed because DD
turns HHH's report upside down.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-13 05:30:56 +0000, olcott said:

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?

A question is never self-evident. A claim can be self-evident
but the above is not a claim.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 1:59 AM, olcott wrote:

On 8/13/2025 12:43 AM, Richard Heathfield wrote:

On 13/08/2025 06:30, olcott wrote:

You ask: How is this answer not self-evident ?

Simulating Termination Analyzer HHH correctly simulates its input

To you, the above is self-evident. To me (and to several others here),
it is not. Your attempts to explain it with x86 traces are
unconvincing because they lack explanatory power.

So you cannot see that when HHH(DD) is executed that
this begins simulating DD that calls HHH(DD) that
begins simulating DD that calls HHH(DD) again ???

Right, so if HHH doesn't abort, it will be non-haltig.

But if it does abort and return 0, so will the HHH that DD calls, and
thus it will halt.

Thus, there is no finite pattern that can be detected, and the false
assumption that there is a finite patter to detect is just incorrect.

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?

Well, it can't return a correct value, because no matter what it
reports DD will turn on its head. And *that* is self-evident.

Can you see how DD correctly simulated by HHH never
reaches its "if" statement?

But, any HHH that meetes the requirements to be a decider, must let DD
get to that if.

Your imagined HHH just fails to meet the requirements, so the program
that meets your requirements (which don't allow it to run forever)
doesn't exist.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 2:05 AM, olcott wrote:

On 8/13/2025 12:56 AM, Lawrence D'Oliveiro wrote:

Feel free to explain how it *is* self-evident.

typedef int (*ptr)();
int HHH(ptr P);

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

I can directly see that that when HHH(DD) is executed
that this begins simulating DD that calls HHH(DD) that
begins simulating DD that calls HHH(DD) again.

But seem to be too stupid to be able to look forward and see that if HHH
does abort, and thus doesn't do a correct simulation, that the correct simulation of the input will do the same and return 0, and DD will halt.

Part of your problem is you beleived your own lie that it needs to be
HHH to do the correct simulation, when that is just a falsehood, related
to you confusions about truth and knowledge.

Things can be true that are unknown, or unknowable, or unprovable.

That concept seems to be beyond your head, and make you think that means
that nothing is knowable, which is just a false dichotomy,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 1:30 AM, olcott wrote:

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.

or keeps running if it never finds a finite pattern that accurately
detects non-halting or reaches the end.>

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?

Which assumes that there is one.


Your problem is that fallacy of the presumed condition.

IT is just like, Have you stopped beating your wife?

or, for your

Have you stopped owning and watching illegal kiddie porn?

(Only that one isn't so much based on a false assumption).

The problem is there is not pattern that HHH can detect in its
simulation of DD, to abort on, that still leaves DD non-halting, because
DD uses the exact same code in its call to HHH, so if HHH thinks the
input is non-halting, it will be haltig.

All you are doing is forgetting one step of the logic.

An program actually built on that rule would be non-halting on this
input, as it turns out that there is no pattern that can be detected,
which still leaves the resultant DD non-halting.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <107h7ug$3ms6e$1@dont-email.me>,
olcott <polcott333@gmail.com> wrote:

What value should HHH(DD) correctly return?

It really depends. Did you let it cool _before_ applying it to
the wire brush?

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 15:42, olcott wrote:

On 8/13/2025 1:45 AM, Richard Heathfield wrote:

On 13/08/2025 06:59, olcott wrote:

On 8/13/2025 12:43 AM, Richard Heathfield wrote:

On 13/08/2025 06:30, olcott wrote:

You ask: How is this answer not self-evident ?

Simulating Termination Analyzer HHH correctly simulates its
input

To you, the above is self-evident. To me (and to several
others here), it is not. Your attempts to explain it with x86
traces are unconvincing because they lack explanatory power.

So you cannot see that when HHH(DD) is executed that
this begins simulating DD that calls HHH(DD) that
begins simulating DD that calls HHH(DD) again ???

You are skipping lightly over the word "correctly".

Because when I delve deeper into this it seems
to exceed your technical capacity.

To you, clearly, this is a very simple matter, and no doubt
anyone who disagrees with you is an incompetent buffoon who knows
nothing about programming. Sir, I do not seek to convince you of
any knowledge or experience or 'technical capacity' I may have
because I seriously doubt whether you would even consider
believing me, and neither do I expect to convince you that you
are mistaken because I am not sure it is even possible for you to
entertain the notion.

Nevertheless, you asked the question "how is this answer not
self-evident?" and I am endeavouring to answer it for you.

How, then, is it not self-evident that it is correct for HHH(DD)
to return 0? Because to do so would mean that HHH is reporting
that DD does not halt, but, on receiving that return value from
HHH, DD will immediately halt.

Conversely, if HHH instead returns 1 to reflect this, DD will
instead enter into its loop, again giving the lie to HHH's return
code.

It seems to me, then, that HHH cannot return either value
correctly, and must (to avoid incorrectness) instead refuse to
return, in which case it cannot complete its task, which is to
report on whether DD halts.

The x86 language
is the ultimate measure of correct simulation.

Again, this is not self-evident. It's not true on ARM, it's not
true on RISC-V, it's not true in IBM-Z... none of which use x86
but on all of which simulation is not only possible but no doubt
performed. The claim is self-evidently false.

Neither is the x86 language the ultimate measure of correct
simulation on the x86, if by that you mean that any simulator
written in x86 assembly language is bound to be correct. If that
were true, developers would only have to re-specify their problem
as a simulator to guarantee that it would be free of bugs.
Nonsense, clearly.

No, the x86 language is the ultimate measure of one thing and one
thing only - ie what happens when you execute x86 instructions on
an x86 platforms. It makes no guarantee that what happens is what
you intended to happen or what you think is happening. It just
does exactly what you tell it to do, which is by no means
necessarily the same as what you intended to tell it.

To you, clearly, your work is flawless. I realise that that's
never going to change no matter what anyone says, but there are
those of us who disagree with you.

If you would merely understand the x86 code and understand
that the x86 language is the ultimate measure of correct
simulation then you would agree with me.

Just as you are assured that you are self-evidently correct, so I
am sure that you self-evidently are mistaken. The x86 language
has NOTHING to say on the correctness of your code; all it does
is carry out your opcodes, no matter where they lead, and it
makes no judgement on whether it is executing your intent.

Three different LLM systems could see the recursive
emulation on their own without prompting on the basis
of the semantics of the C code.

Great! You have convinced three AIs that you are correct. I hope
that makes you very happy. But AIs are notoriously gullible and
are quick to hallucinate things that are not true, so their
support doesn't offer you as much backing as you might hope. As
you have discovered over the last 20-odd years, humans are less
easily convinced.

That three different systems see that actual execution
trace and no one can point to any specific error in this
execution trace seems to prove that I am correct.

That is not self-evident. It lacks rigour.

Dogmatically saying that I am wrong without being able
to show exactly which instruction was simulated incorrectly
does not seem to count as any actual rebuttal.

Finding your bug is your job, and nobody else's. That there is a
bug is self-evident. Here's why:

(a) HHH(DD) returns 0 to report looping, but DD then halts.
(b) HHH(DD) returns 1 to report halting, but DD then loops.
(c) HHH(DD) refuses to return.

In (a) and (b) HHH gives the wrong answer, and in (c) HHH fails
to answer the question it is asked.

There are no other possibilities, so HHH necessarily screws up.
Ergo, there is a bug. Finding it is nobody's job but yours.

Since you're such a clever and all-knowing programmer it probably
won't take you more than five minutes to find and fix it.

But when you do, you'll be right back where you are now.

Because the one thing your HHH cannot tell you, no matter how
perfectly it simulates what it can reach, is what DD will do when
it reclaims control.

Do you have many years as a C/C++ programmer?

I could answer that and we could have a pissing match, but even
if I had no programming experience whatsoever, you would still be self-evidently wrong, your code would still self-evidently fail
to stay within the bounds of what the C language guarantees, and
your logic would still be up the creek.

<snip>

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 15:55, olcott wrote:

<snip>

The above execution trace seems self-evident to me.

Yes, I know.

Do you see this now that it has been pointed out?

It's self-evident...that HHH must either fail to report or report
the wrong answer.

Three different LLM systems did figure out that
execution trace on their own.

You see? AIs can be wrong too. But that's also self-evident.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() will do the
f**king opposite thus confirming the extant Halting Problem proofs are
correct.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() will do the
f**king opposite thus confirming the extant Halting Problem proofs are
correct.

/Flibble

That you are an expert C programmer should prove to you that the input
to simulating termination analyzer cannot possibly reach its own "do the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a halt
decider: halt deciders answer in finite time with a halting result.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() will do
the f**king opposite thus confirming the extant Halting Problem
proofs are correct.

/Flibble

That you are an expert C programmer should prove to you that the input
to simulating termination analyzer cannot possibly reach its own "do
the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a halt
decider: halt deciders answer in finite time with a halting result.

/Flibble

I am only referring to your expertise in C to see this:

When HHH(DD) is executed that this begins simulating DD that calls
HHH(DD) that begins simulating DD that calls HHH(DD) again.

Again: if HHH(DD) does not return a halting result to DD() then HHH is not
a halt decider.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 12:23:47 -0500, olcott wrote:

On 8/13/2025 12:30 AM, olcott wrote:

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?

Dozens and dozens of reviewers across many different forums in the last
three years refuse to acknowledge what every expert C programmer can see
in less than a minute: *The execution trace of DD simulated by HHH*

What would explain this?

The only thing needing an explanation is your willful obtuseness.

Again:

It doesn't f**king matter what HHH(DD) returns because DD() will do the
f**king opposite thus confirming the extant Halting Problem proofs are
correct.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 12:26:24 -0500, olcott wrote:

On 8/13/2025 12:13 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() will do >>>>>> the f**king opposite thus confirming the extant Halting Problem
proofs are correct.

/Flibble

That you are an expert C programmer should prove to you that the
input to simulating termination analyzer cannot possibly reach its
own "do the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a halt
decider: halt deciders answer in finite time with a halting result.

/Flibble

I am only referring to your expertise in C to see this:

When HHH(DD) is executed that this begins simulating DD that calls
HHH(DD) that begins simulating DD that calls HHH(DD) again.

Again: if HHH(DD) does not return a halting result to DD() then HHH is
not a halt decider.

/Flibble

As an expert C programmer what is the execution trace of DD simulated by
DD?

We can't cover the computer science of this until you answer that
question.

DD() is not simulating anything, it is calling HHH(DD), if HHH then starts
a simulation resulting in infinite recursion then HHH isn't a halt decider
as halt deciders return a halting result to their caller in finite time.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 12:29:03 -0500, olcott wrote:

On 8/13/2025 12:26 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:23:47 -0500, olcott wrote:

On 8/13/2025 12:30 AM, olcott wrote:

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?

Dozens and dozens of reviewers across many different forums in the
last three years refuse to acknowledge what every expert C programmer
can see in less than a minute: *The execution trace of DD simulated by
HHH*

What would explain this?

The only thing needing an explanation is your willful obtuseness.

Again:

It doesn't f**king matter what HHH(DD) returns because DD() will do the
f**king opposite thus confirming the extant Halting Problem proofs are
correct.

/Flibble

We cannot address the computer science of this until after you first understand the actual execution trace of DD simulated by HHH.

We can go through this a billion times and that will never change.

A billion times? As I said, your willful obtuseness requires an
explanation.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-13, olcott <polcott333@gmail.com> wrote:

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?

The thing is that the procedure DD /integrates/ the deciding
function HHH.

If we have not yet committed to a behavior and return value for HHH(DD),
then it means we have not yet committed to the design of DD itself!

You have to commit to a definition of HHH.

If you then make a different definition, that is a new version of HHH.

You have to separate these; you can't refer to all of them as HHH.

As you try different ways of creating the halting decider, you
have have HHH1, HHH2, HHH3.

The author of DD studies each of these and replicates its logic,
embedding it into DD.

This activity gives rise to DD1, DD2, DD3, ...

DD1 proves that HH1 is not a universal halting decider.
DD2 proves that HH2 is not a universal halting decider.
DD3 proves that HH3 is not a universal halting decider.

And so on. For every halting decider design that you finalize and commit
to, a test case is easily produced which shows that it does not decide
the halting of all computations.

That creates a simple and convincing inductive argument that there
doesn't exist a univeral halting decider.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 13:03:33 -0500, olcott wrote:

On 8/13/2025 12:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:26:24 -0500, olcott wrote:

On 8/13/2025 12:13 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() will >>>>>>>> do the f**king opposite thus confirming the extant Halting
Problem proofs are correct.

/Flibble

That you are an expert C programmer should prove to you that the >>>>>>> input to simulating termination analyzer cannot possibly reach its >>>>>>> own "do the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a halt >>>>>> decider: halt deciders answer in finite time with a halting result. >>>>>>
/Flibble

I am only referring to your expertise in C to see this:

When HHH(DD) is executed that this begins simulating DD that calls
HHH(DD) that begins simulating DD that calls HHH(DD) again.

Again: if HHH(DD) does not return a halting result to DD() then HHH
is not a halt decider.

/Flibble

As an expert C programmer what is the execution trace of DD simulated
by DD?

We can't cover the computer science of this until you answer that
question.

DD() is not simulating anything, it is calling HHH(DD), if HHH then
starts a simulation resulting in infinite recursion then HHH isn't a
halt decider as halt deciders return a halting result to their caller
in finite time.

/Flibble

Three different LLM systems figured out that the execution trace of DD correctly simulated by HHH does match the *recursive simulation
non-halting behavior pattern*
on their own without prompting that such a pattern even exists.

The simulation shows DD calling HHH(DD) repeatedly
This creates an infinite recursive loop in the simulation No
simulated execution path leads to DD's return statement being
reached
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

In other words, simulating DD() requires simulating HHH(DD), which
requires simulating DD() again… recursive simulation.

This creates an infinite regress — HHH cannot finish simulating DD()
because to simulate it, it must simulate itself again, and again,
and again… https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c

When HHH simulates DD, it must model DD's execution, including the
call to HHH(DD) within DD.
This introduces a recursive simulation: HHH simulating DD involves
simulating DD's call to HHH(DD), which requires HHH to simulate DD
again, and so on. https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-

eedd0f09e141

The inner workings of HHH is of little consequence (so your call traces
are just smoke and mirrors), what matters is what result HHH(DD) returns
to DD(); if HHH(DD) doesn't return a result to DD() then HHH is not a halt decider.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 18:04, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

<snip>

What value should HHH(DD) correctly return?

It doesn't f**king matter what HHH(DD) returns because DD()
will do the
f**king opposite thus confirming the extant Halting Problem
proofs are
correct.

/Flibble

That you are an expert C programmer should prove to you
that the input to simulating termination analyzer cannot
possibly reach its own "do the opposite" code.

That you claim to know C should be enough to tell you that the
only way you can stop DD screwing you up is by not returning from
HHH. HHH is required to inform its caller of its conclusion.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 13:14:48 -0500, olcott wrote:

On 8/13/2025 1:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:03:33 -0500, olcott wrote:

On 8/13/2025 12:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:26:24 -0500, olcott wrote:

On 8/13/2025 12:13 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() >>>>>>>>>> will do the f**king opposite thus confirming the extant Halting >>>>>>>>>> Problem proofs are correct.

/Flibble

That you are an expert C programmer should prove to you that the >>>>>>>>> input to simulating termination analyzer cannot possibly reach >>>>>>>>> its own "do the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a
halt decider: halt deciders answer in finite time with a halting >>>>>>>> result.

/Flibble

I am only referring to your expertise in C to see this:

When HHH(DD) is executed that this begins simulating DD that calls >>>>>>> HHH(DD) that begins simulating DD that calls HHH(DD) again.

Again: if HHH(DD) does not return a halting result to DD() then HHH >>>>>> is not a halt decider.

/Flibble

As an expert C programmer what is the execution trace of DD
simulated by DD?

We can't cover the computer science of this until you answer that
question.

DD() is not simulating anything, it is calling HHH(DD), if HHH then
starts a simulation resulting in infinite recursion then HHH isn't a
halt decider as halt deciders return a halting result to their caller
in finite time.

/Flibble

Three different LLM systems figured out that the execution trace of DD
correctly simulated by HHH does match the *recursive simulation
non-halting behavior pattern*
on their own without prompting that such a pattern even exists.

The simulation shows DD calling HHH(DD) repeatedly
This creates an infinite recursive loop in the simulation No
simulated execution path leads to DD's return statement being
reached
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

In other words, simulating DD() requires simulating HHH(DD),
which requires simulating DD() again… recursive simulation.

This creates an infinite regress — HHH cannot finish simulating
DD()
because to simulate it, it must simulate itself again, and again,
and again…
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c

When HHH simulates DD, it must model DD's execution, including
the call to HHH(DD) within DD.
This introduces a recursive simulation: HHH simulating DD
involves simulating DD's call to HHH(DD), which requires HHH to
simulate DD again, and so on.
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-

eedd0f09e141

The inner workings of HHH is of little consequence (so your call traces
are just smoke and mirrors), what matters is what result HHH(DD)
returns to DD(); if HHH(DD) doesn't return a result to DD() then HHH is
not a halt decider.

/Flibble

When HHH(DD) does return the result to its caller. it is never reporting
on the behavior of its caller.

That a halt decider is supposed to report on the behavior of its caller
has always been incorrect.

What is incorrect is your understanding of the Halting Problem and your so called "refutation" of extant Halting Problem proofs.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 13:27:37 -0500, olcott wrote:

On 8/13/2025 1:19 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:14:48 -0500, olcott wrote:

On 8/13/2025 1:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:03:33 -0500, olcott wrote:

On 8/13/2025 12:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:26:24 -0500, olcott wrote:

On 8/13/2025 12:13 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() >>>>>>>>>>>> will do the f**king opposite thus confirming the extant >>>>>>>>>>>> Halting Problem proofs are correct.

/Flibble

That you are an expert C programmer should prove to you that >>>>>>>>>>> the input to simulating termination analyzer cannot possibly >>>>>>>>>>> reach its own "do the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a >>>>>>>>>> halt decider: halt deciders answer in finite time with a
halting result.

/Flibble

I am only referring to your expertise in C to see this:

When HHH(DD) is executed that this begins simulating DD that >>>>>>>>> calls HHH(DD) that begins simulating DD that calls HHH(DD)
again.

Again: if HHH(DD) does not return a halting result to DD() then >>>>>>>> HHH is not a halt decider.

/Flibble

As an expert C programmer what is the execution trace of DD
simulated by DD?

We can't cover the computer science of this until you answer that >>>>>>> question.

DD() is not simulating anything, it is calling HHH(DD), if HHH then >>>>>> starts a simulation resulting in infinite recursion then HHH isn't >>>>>> a halt decider as halt deciders return a halting result to their
caller in finite time.

/Flibble

Three different LLM systems figured out that the execution trace of
DD correctly simulated by HHH does match the *recursive simulation
non-halting behavior pattern*
on their own without prompting that such a pattern even exists.

The simulation shows DD calling HHH(DD) repeatedly
This creates an infinite recursive loop in the simulation No
simulated execution path leads to DD's return statement being
reached
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

In other words, simulating DD() requires simulating HHH(DD),
which requires simulating DD() again… recursive simulation.

This creates an infinite regress — HHH cannot finish
simulating DD()
because to simulate it, it must simulate itself again, and
again,
and again…
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c

When HHH simulates DD, it must model DD's execution, including >>>>> the call to HHH(DD) within DD.
This introduces a recursive simulation: HHH simulating DD
involves simulating DD's call to HHH(DD), which requires HHH
to simulate DD again, and so on.
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-

eedd0f09e141

The inner workings of HHH is of little consequence (so your call
traces are just smoke and mirrors), what matters is what result
HHH(DD) returns to DD(); if HHH(DD) doesn't return a result to DD()
then HHH is not a halt decider.

/Flibble

When HHH(DD) does return the result to its caller. it is never
reporting on the behavior of its caller.

That a halt decider is supposed to report on the behavior of its
caller has always been incorrect.

What is incorrect is your understanding of the Halting Problem and your
so called "refutation" of extant Halting Problem proofs.

/Flibble

Although is may seem that my understanding is incorrect a deeper understanding of the fundamental nature of Turing machines and
computable functions proves that it is incorrect to expect a TM to
report on the behavior of its caller.

HHH has to return a result to its caller or it isn't a halt decider.
That's it. So what does HHH(DD) return to DD()?

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 18:23, olcott wrote:

On 8/13/2025 12:30 AM, olcott wrote:

<snip>

What value should HHH(DD) correctly return?

Dozens and dozens of reviewers across many different
forums in the last three years refuse to acknowledge
what every expert C programmer can see in less than
a minute: *The execution trace of DD simulated by HHH*

What would explain this?

That HHH must eventually return or fail to return. Either way
causes you a problem. Dozens and dozens of reviewers have told
you this, yet you refuse to address the point.

What would explain this?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 18:12, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD()
will do the
f**king opposite thus confirming the extant Halting Problem
proofs are
correct.

/Flibble

That you are an expert C programmer should prove to you that
the input
to simulating termination analyzer cannot possibly reach its
own "do the
opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a halt
decider: halt deciders answer in finite time with a halting
result.

/Flibble

I am only referring to your expertise in C to see this:

When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.

...and it all eventually unwinds to report. Or is it your claim
that after all that effort HHH isn't going to report to its caller?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 18:01, olcott wrote:

On 8/13/2025 10:54 AM, Richard Heathfield wrote:

On 13/08/2025 15:42, olcott wrote:

On 8/13/2025 1:45 AM, Richard Heathfield wrote:

On 13/08/2025 06:59, olcott wrote:

On 8/13/2025 12:43 AM, Richard Heathfield wrote:

On 13/08/2025 06:30, olcott wrote:

You ask: How is this answer not self-evident ?

Simulating Termination Analyzer HHH correctly simulates
its input

<snip>

To you, clearly, this is a very simple matter, and no doubt
anyone who disagrees with you is an incompetent buffoon who
knows nothing about programming.

No it is much more specific that that.

What happens after HHH returns?

When on claims that an emulation is incorrect
yet zero instructions were emulated incorrectly
then the claim is proved to be incorrect.

Here is an emulator that emulates zero instructions incorrectly:

int BugfreeEmulator(ptr P)
{
(void)P; /* suppress irritating warning about
doing bugger all with P. */
return 0;
}

Emulating zero instructions incorrectly is not sufficient for you
to have a correct emulator. You must finish the job you started.
But you don't.

Point out the instruction that was emulated
incorrectly or acknowledge that you cannot.

Why should I?

(a) It's your bug to find.
(b) Even if you find it, it won't matter, for reasons I outlined
(again!) in my last reply.

You don't read too well.

Nevertheless, you asked the question "how is this answer not
self- evident?" and I am endeavouring to answer it for you.

Yes, you seem to be doing well at that.
I am surprised to find that seeing this execution trace
is too difficult for everyone here:

Why should anyone even bother to look? No matter what your trace
says, you still have only three choices - return halt (wrong!),
return loop (wrong!) or don't return (wrong!). Whichever you
choose, it's the wrong solution, even if your trace is flawless.

When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.

You keep saying that, but you never stop to think what happens
when HHH /stops/ executing.

How, then, is it not self-evident that it is correct for
HHH(DD) to return 0? Because to do so would mean that HHH is
reporting that DD does not halt, but, on receiving that return
value from HHH, DD will immediately halt.

That only requires seeing the above execution trace.

Your trace fails to show the stack unwinding after HHH has
reached its decision, all simulation is concluded, and DD regains
control at last.

You did point out the C by itself needs some additional
infrastructure. I had presumed that people would simply
assume that HHH uses some C language interpreter.

It doesn't matter. What matters is not what happens inside HHH
(which is apparently so trivial you don't even bother to show the
source) but what happens after HHH returns.

Conversely, if HHH instead returns 1 to reflect this, DD will
instead enter into its loop, again giving the lie to HHH's
return code.

That is not the behavior of the input.

How do you know? You don't simulate that far.

It seems to me, then, that HHH cannot return either value
correctly, and must (to avoid incorrectness) instead refuse to
return, in which case it cannot complete its task, which is to
report on whether DD halts.

It does seem that way when you expect an embedded
halt decider to report on its own behavior.

I'm not asking HHH to tell me anything but whether DD halts.

The nature of Turing machines does not allow them to
directly report on their own behavior because this
requires Turing machines to take other Turing machines
as inputs.

You don't have a Turing machine. You have an x86 program.

The x86 language
is the ultimate measure of correct simulation.

Again, this is not self-evident. It's not true on ARM,  it's
not true on RISC-V, it's not true in IBM-Z... none of which use
x86 but on all of which simulation is not only possible but no
doubt performed. The claim is self-evidently false.

Disagreeing with the fact that the DD code
was written in the x86 language does not help.

Here is the DD code:

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

That's C syntax, not x86 syntax.

Disagreeing with facts never helps.

Talking bollocks doesn't help either.

Neither is the x86 language the ultimate measure of correct
simulation on the x86, if by that you mean that any simulator
written in x86 assembly language is bound to be correct. If
that were true, developers would only have to re-specify their
problem as a simulator to guarantee that it would be free of
bugs. Nonsense, clearly.

No, the x86 language is the ultimate measure of one thing and
one thing only - ie what happens when you execute x86
instructions on an x86 platforms.

Unless you can find an instruction of DD that was
emulated incorrectly your claim that DD was emulated
incorrectly remains insufficiently grounded.

I've already dealt with that several times. Here is my most
recent effort, re-posted in the way you like so much:

Finding your bug is your job, and nobody else's. That there is a
bug is self-evident. Here's why:

(a) HHH(DD) returns 0 to report looping, but DD then halts.
(b) HHH(DD) returns 1 to report halting, but DD then loops.
(c) HHH(DD) refuses to return.

In (a) and (b) HHH gives the wrong answer, and in (c) HHH fails
to answer the question it is asked.

There are no other possibilities, so HHH necessarily screws up.
Ergo, there is a bug. Finding it is nobody's job but yours.

Since you're such a clever and all-knowing programmer it probably
won't take you more than five minutes to find and fix it.

But when you do, you'll be right back where you are now.

Because the one thing your HHH cannot tell you, no matter how
perfectly it simulates what it can reach, is what DD will do when
it reclaims control.

_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]

We can determine from the above code that DDD correctly
emulated by HHH would include HHH emulating an instance
of itself emulating an instance of DD. **

Irrelevant. What matters is what happens when HHH eventually
unwinds the stack and returns.

** As long as HHH has access to an x86 emulator that
provides the cooperative multi-taking infrastructure
required to implement this.

It doesn't matter. What happens when HHH returns?

To you, clearly, your work is flawless. I realise that that's
never going to change no matter what anyone says, but there
are those of us who disagree with you.

If you would merely understand the x86 code and understand
that the x86 language is the ultimate measure of correct
simulation then you would agree with me.

Just as you are assured that you are self-evidently correct, so
I am sure that you self-evidently are mistaken. The x86
language has NOTHING to say on the correctness of your code;

It has everything to say about the correctness of DD
emulated by HHH.

Then you can save yourself a lot of clocks with this hack

int HHH(ptr P)
{
return 0;
}

If the question before us is whether HHH observes DD to halt, you
can save yourself 1300-odd lines of code.

Three different LLM systems did not need to even see
the x86 code.

Neither did I. return 0; works nicely.

They figured out the recursive simulation
execution trace all on their own on the basis of the C code.

So what? How HHH works doesn't matter a jot. What matters is
*whether* it works, and I have already explained *that* it
doesn't and *why* it doesn't.

I was surprised that C itself does not permit
outputting the actual machine address of a function
even though it does use this address itself internally.

How C implementations manage function pointers is an
implementation detail. There's more than one way to skin a cat,
and C does not unnecessarily limit the implementors by telling
them which blade to use.

Three different LLM systems could see the recursive
emulation on their own without prompting on the basis
of the semantics of the C code.

Great! You have convinced three AIs that you are correct.

I am shocked that everyone here thinks that recursive
emulation is incomprehensibly more difficult to understand
than ordinary recursion.

It isn't hard to understand. It's just irrelevant to the question
of whether HHH returns the correct value (which it doesn't, by
the way).

I hope that makes you very happy. But AIs are notoriously
gullible and are quick to hallucinate things that are not true,
so their support doesn't offer you as much backing as you might
hope. As you have discovered over the last 20-odd years, humans
are less easily convinced.

Unless someone actually bothers to see if they
can find an actual error in what they said.

Finding your bug is your job, and nobody else's. That there is a
bug is self-evident. Here's why:

(a) HHH(DD) returns 0 to report looping, but DD then halts.
(b) HHH(DD) returns 1 to report halting, but DD then loops.
(c) HHH(DD) refuses to return.

In (a) and (b) HHH gives the wrong answer, and in (c) HHH fails
to answer the question it is asked.

There are no other possibilities, so HHH necessarily screws up.
Ergo, there is a bug. Finding it is nobody's job but yours.

Since you're such a clever and all-knowing programmer it probably
won't take you more than five minutes to find and fix it.

But when you do, you'll be right back where you are now.

Because the one thing your HHH cannot tell you, no matter how
perfectly it simulates what it can reach, is what DD will do when
it reclaims control.

That three different systems see that actual execution
trace and no one can point to any specific error in this
execution trace seems to prove that I am correct.

That is not self-evident. It lacks rigour.

It is not self-evident when you don't bother to
look at what they say.

We know what they say, because you wouldn't have told us about
them if they'd said anything else.

It is self-evident when you see that they all
provide this same execution trace:

What is self-evident is that they don't explain what happens in
DD after HHH returns.

When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.

...and when it stops?

  The simulation shows DD calling HHH(DD) repeatedly
  This creates an infinite recursive loop in the simulation

So HHH never reports? Bug.

  No simulated execution path leads to DD's return statement
  being reached

So the simulator fails to emulate DD in its entirety.

https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

   In other words, simulating DD() requires simulating
   HHH(DD), which requires simulating DD() again… recursive
   simulation.

   This creates an infinite regress — HHH cannot finish
   simulating DD() because to simulate it, it must simulate
   itself again, and again, and again…

So it can't report. Bug.

https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c

   When HHH simulates DD, it must model DD's execution,
   including the call to HHH(DD) within DD.
   This introduces a recursive simulation: HHH simulating
   DD involves simulating DD's call to HHH(DD), which
   requires HHH to simulate DD again, and so on. https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-eedd0f09e141

This fails to explain what happens in DD after HHH reports.

Dogmatically saying that I am wrong without being able
to show exactly which instruction was simulated incorrectly
does not seem to count as any actual rebuttal.

Finding your bug is your job, and nobody else's. That there is
a bug is self-evident. Here's why:

(a) HHH(DD) returns 0 to report looping, but DD then halts.
(b) HHH(DD) returns 1 to report halting, but DD then loops.
(c) HHH(DD) refuses to return.

In (a) and (b) HHH gives the wrong answer, and in (c) HHH fails
to answer the question it is asked.

There are no other possibilities, so HHH necessarily screws up.
Ergo, there is a bug. Finding it is nobody's job but yours.

HHH1(DD) and DD() benefit from the fact that HHH(DD)
has aborted its simulation of DD.

HHH(DD) cannot benefit from the fact that HHH(DD)
has aborted its simulation of DD because HHH has
not done this yet.

We'll wait.

If HHH never reports, that's a bug.

Since you're such a clever and all-knowing programmer it
probably won't take you more than five minutes to find and fix it.

But when you do, you'll be right back where you are now.

Because the one thing your HHH cannot tell you, no matter how
perfectly it simulates what it can reach, is what DD will do
when it reclaims control.

Do you have many years as a C/C++ programmer?

I could answer that and we could have a pissing match, but even
if I had no programming experience whatsoever, you would still
be self-evidently wrong, your code would still self-evidently
fail to stay within the bounds of what the C language
guarantees, and your logic would still be up the creek.

<snip>

Most "rebuttals" make sure to ignore my corrections
to their provably false assumptions.

Your provable false assumption is that HHH "correctly" simulates
its input.

Here's the proof:

Finding your bug is your job, and nobody else's. That there is a
bug is self-evident. Here's why:

(a) HHH(DD) returns 0 to report looping, but DD then halts.
(b) HHH(DD) returns 1 to report halting, but DD then loops.
(c) HHH(DD) refuses to return.

In (a) and (b) HHH gives the wrong answer, and in (c) HHH fails
to answer the question it is asked.

There are no other possibilities, so HHH necessarily screws up.
Ergo, there is a bug. Finding it is nobody's job but yours.

Since you're such a clever and all-knowing programmer it probably
won't take you more than five minutes to find and fix it.

But when you do, you'll be right back where you are now.

Because the one thing your HHH cannot tell you, no matter how
perfectly it simulates what it can reach, is what DD will do when
it reclaims control.




--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 14:07:13 -0500, olcott wrote:

The DD stack cannot possibly unwind because there is nothing driving the behavior of DD after HHH aborts its simulation of DD.

False, main() is calling DD().

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 14:10:37 -0500, olcott wrote:

On 8/13/2025 1:29 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:27:37 -0500, olcott wrote:

On 8/13/2025 1:19 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:14:48 -0500, olcott wrote:

On 8/13/2025 1:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:03:33 -0500, olcott wrote:

On 8/13/2025 12:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:26:24 -0500, olcott wrote:

On 8/13/2025 12:13 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote:

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?

It doesn't f**king matter what HHH(DD) returns because DD() >>>>>>>>>>>>>> will do the f**king opposite thus confirming the extant >>>>>>>>>>>>>> Halting Problem proofs are correct.

/Flibble

That you are an expert C programmer should prove to you that >>>>>>>>>>>>> the input to simulating termination analyzer cannot possibly >>>>>>>>>>>>> reach its own "do the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not a >>>>>>>>>>>> halt decider: halt deciders answer in finite time with a >>>>>>>>>>>> halting result.

/Flibble

I am only referring to your expertise in C to see this:

When HHH(DD) is executed that this begins simulating DD that >>>>>>>>>>> calls HHH(DD) that begins simulating DD that calls HHH(DD) >>>>>>>>>>> again.

Again: if HHH(DD) does not return a halting result to DD() then >>>>>>>>>> HHH is not a halt decider.

/Flibble

As an expert C programmer what is the execution trace of DD
simulated by DD?

We can't cover the computer science of this until you answer >>>>>>>>> that question.

DD() is not simulating anything, it is calling HHH(DD), if HHH >>>>>>>> then starts a simulation resulting in infinite recursion then HHH >>>>>>>> isn't a halt decider as halt deciders return a halting result to >>>>>>>> their caller in finite time.

/Flibble

Three different LLM systems figured out that the execution trace >>>>>>> of DD correctly simulated by HHH does match the *recursive
simulation non-halting behavior pattern*
on their own without prompting that such a pattern even exists.

The simulation shows DD calling HHH(DD) repeatedly
This creates an infinite recursive loop in the simulation >>>>>>> No simulated execution path leads to DD's return statement >>>>>>> being reached
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

In other words, simulating DD() requires simulating
HHH(DD), which requires simulating DD() again… recursive >>>>>>> simulation.

This creates an infinite regress — HHH cannot finish
simulating DD()
because to simulate it, it must simulate itself again, and >>>>>>> again,
and again…
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c

When HHH simulates DD, it must model DD's execution,
including the call to HHH(DD) within DD.
This introduces a recursive simulation: HHH simulating DD >>>>>>> involves simulating DD's call to HHH(DD), which requires
HHH to simulate DD again, and so on.
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-

eedd0f09e141

The inner workings of HHH is of little consequence (so your call
traces are just smoke and mirrors), what matters is what result
HHH(DD) returns to DD(); if HHH(DD) doesn't return a result to DD() >>>>>> then HHH is not a halt decider.

/Flibble

When HHH(DD) does return the result to its caller. it is never
reporting on the behavior of its caller.

That a halt decider is supposed to report on the behavior of its
caller has always been incorrect.

What is incorrect is your understanding of the Halting Problem and
your so called "refutation" of extant Halting Problem proofs.

/Flibble

Although is may seem that my understanding is incorrect a deeper
understanding of the fundamental nature of Turing machines and
computable functions proves that it is incorrect to expect a TM to
report on the behavior of its caller.

HHH has to return a result to its caller or it isn't a halt decider.
That's it. So what does HHH(DD) return to DD()?

/Flibble

When DD() is executed in main HHH(DD) reports that its own different
instance of DD cannot possibly reach its own final halt state.

No termination analyzer or halt decider ever reports on the behavior of itself or it caller.
That would be like baking a cake in your washing machine.

You say HHH(DD) "reports": it reports what and to whom? If it "reports" non-halting to DD() then DD() will do the opposite and the extant Halting Problem proofs are proven to be correct!

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 14:27:48 -0500, olcott wrote:

On 8/13/2025 2:14 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:07:13 -0500, olcott wrote:

The DD stack cannot possibly unwind because there is nothing driving
the behavior of DD after HHH aborts its simulation of DD.

False, main() is calling DD().

/Flibble

More precisely there is nothing driving the behavior of DD correctly simulated by HHH after HHH quits simulating DD.

Also the directly executed DD (caller of HHH) has always been invisible
to this HHH, hence not in the scope of this HHH.

The directly executed DD doesn't have to be visible to HHH, HHH just needs
to be passed a *description* of DD and it must return a result to DD() to
be a halt decider. The problem here is your fundamental misunderstanding
of the extant Halting Problem diagonalization proofs.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 14:30:40 -0500, olcott wrote:

On 8/13/2025 2:19 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:10:37 -0500, olcott wrote:

On 8/13/2025 1:29 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:27:37 -0500, olcott wrote:

On 8/13/2025 1:19 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:14:48 -0500, olcott wrote:

On 8/13/2025 1:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:03:33 -0500, olcott wrote:

On 8/13/2025 12:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:26:24 -0500, olcott wrote:

On 8/13/2025 12:13 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote:

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote: >>>>>>>>>>>>>>>>

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?

It doesn't f**king matter what HHH(DD) returns because >>>>>>>>>>>>>>>> DD()
will do the f**king opposite thus confirming the extant >>>>>>>>>>>>>>>> Halting Problem proofs are correct.

/Flibble

That you are an expert C programmer should prove to you >>>>>>>>>>>>>>> that the input to simulating termination analyzer cannot >>>>>>>>>>>>>>> possibly reach its own "do the opposite" code.

If HHH(DD) does not return a result to DD() then HHH is not >>>>>>>>>>>>>> a halt decider: halt deciders answer in finite time with a >>>>>>>>>>>>>> halting result.

/Flibble

I am only referring to your expertise in C to see this: >>>>>>>>>>>>>
When HHH(DD) is executed that this begins simulating DD that >>>>>>>>>>>>> calls HHH(DD) that begins simulating DD that calls HHH(DD) >>>>>>>>>>>>> again.

Again: if HHH(DD) does not return a halting result to DD() >>>>>>>>>>>> then HHH is not a halt decider.

/Flibble

As an expert C programmer what is the execution trace of DD >>>>>>>>>>> simulated by DD?

We can't cover the computer science of this until you answer >>>>>>>>>>> that question.

DD() is not simulating anything, it is calling HHH(DD), if HHH >>>>>>>>>> then starts a simulation resulting in infinite recursion then >>>>>>>>>> HHH isn't a halt decider as halt deciders return a halting >>>>>>>>>> result to their caller in finite time.

/Flibble

Three different LLM systems figured out that the execution trace >>>>>>>>> of DD correctly simulated by HHH does match the *recursive
simulation non-halting behavior pattern*
on their own without prompting that such a pattern even exists. >>>>>>>>>
The simulation shows DD calling HHH(DD) repeatedly
This creates an infinite recursive loop in the
simulation No simulated execution path leads to DD's >>>>>>>>> return statement being reached
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>
In other words, simulating DD() requires simulating
HHH(DD), which requires simulating DD() again… recursive >>>>>>>>> simulation.

This creates an infinite regress — HHH cannot finish >>>>>>>>> simulating DD()
because to simulate it, it must simulate itself again, >>>>>>>>> and again,
and again…
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c >>>>>>>>>
When HHH simulates DD, it must model DD's execution, >>>>>>>>> including the call to HHH(DD) within DD.
This introduces a recursive simulation: HHH simulating >>>>>>>>> DD involves simulating DD's call to HHH(DD), which
requires HHH to simulate DD again, and so on.
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21- >>>>>>>> eedd0f09e141

The inner workings of HHH is of little consequence (so your call >>>>>>>> traces are just smoke and mirrors), what matters is what result >>>>>>>> HHH(DD) returns to DD(); if HHH(DD) doesn't return a result to >>>>>>>> DD()
then HHH is not a halt decider.

/Flibble

When HHH(DD) does return the result to its caller. it is never
reporting on the behavior of its caller.

That a halt decider is supposed to report on the behavior of its >>>>>>> caller has always been incorrect.

What is incorrect is your understanding of the Halting Problem and >>>>>> your so called "refutation" of extant Halting Problem proofs.

/Flibble

Although is may seem that my understanding is incorrect a deeper
understanding of the fundamental nature of Turing machines and
computable functions proves that it is incorrect to expect a TM to
report on the behavior of its caller.

HHH has to return a result to its caller or it isn't a halt decider.
That's it. So what does HHH(DD) return to DD()?

/Flibble

When DD() is executed in main HHH(DD) reports that its own different
instance of DD cannot possibly reach its own final halt state.

No termination analyzer or halt decider ever reports on the behavior
of itself or it caller.
That would be like baking a cake in your washing machine.

You say HHH(DD) "reports": it reports what and to whom?

The directly executed HHH(DD) always reports to its caller yet never
reports on the behavior of this caller.

If it "reports"
non-halting to DD() then DD() will do the opposite and the extant
Halting Problem proofs are proven to be correct!

/Flibble

It does not matter to HHH(DD) what the Hell its caller does. The
behavior of its caller has never been any of the damn business of HHH.

In the diagonalization proofs HHH(DD) needs to report on a *description*
of its caller which is the ONLY business of HHH.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 19:14, olcott wrote:

When HHH(DD) does return the result to its caller.
it is never reporting on the behavior of its caller.

Some C for you.

A function definition includes the function body.

The identifier declared in a function definition (which is the
name of the function) shall have a function type, as specified by
the declarator portion of the function definition.

A function designator is an expression that has function type.
Except when it is the operand of the sizeof operator or the unary
& operator, a function designator with type ‘‘function returning
type’’ is converted to an expression that has type ‘‘pointer to function returning type’’.

HHH(DD) specifies a function designator whose termination status
is to be investigated. That designator is (as outlined above)
converted to a pointer. It's how you tell which function to emulate.

HHH is reporting on DD, because you ask it to. And the function
that does the asking is DD. The DD in HHH(DD) and the DD in int
DD() are one and the same DD. Not because I say so, but because C
says so.

Don't take my word for it. Ask any C expert. Kaz, for example, or
Keith.

There is only one DD.

Recursion can let you have multiple instances of a function, and
each even has its own locals, but they are the same function, and
it is the *function*, not a mere instance, that HHH has been
asked to assess.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 14:39:27 -0500, olcott wrote:

On 8/13/2025 2:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:27:48 -0500, olcott wrote:

On 8/13/2025 2:14 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:07:13 -0500, olcott wrote:

The DD stack cannot possibly unwind because there is nothing driving >>>>> the behavior of DD after HHH aborts its simulation of DD.

False, main() is calling DD().

/Flibble

More precisely there is nothing driving the behavior of DD correctly
simulated by HHH after HHH quits simulating DD.

Also the directly executed DD (caller of HHH) has always been
invisible to this HHH, hence not in the scope of this HHH.

The directly executed DD doesn't have to be visible to HHH,

So you expect HHH to have psychic ability?

HHH just needs to be passed a *description* of DD

Yet I proved (and everyone consistently makes sure to totally ignore
every single day for three years) DD correctly simulated by HHH has
different behavior than DD().

And that different behaviour confirms the extant Halting Problem proofs
are correct!

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 19:27, olcott wrote:

<snip>

Although is may seem that my understanding is incorrect
a deeper understanding of the fundamental nature of Turing
machines and computable functions proves that it is
incorrect to expect a TM to report on the behavior of
its caller.

Trying hard not to laugh, let's pretend that we buy this "deeper
understanding" bollocks... but I don't think you've thought it
through.

DD calls HHH, so your claim is tantamount to saying that it is
incorrect for DD to pass DD to HHH.

int Halt_Status = HHH(DD);
^^
In which case, there's your bug right there.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 14:55:46 -0500, olcott wrote:

On 8/13/2025 2:40 PM, Richard Heathfield wrote:

On 13/08/2025 19:14, olcott wrote:

When HHH(DD) does return the result to its caller. it is never
reporting on the behavior of its caller.

Some C for you.

A function definition includes the function body.

The identifier declared in a function definition (which is the name of
the function) shall have a function type, as specified by the
declarator portion of the function definition.

A function designator is an expression that has function type.
Except when it is the operand of the sizeof operator or the unary &
operator, a function designator with type ‘‘function returning type’’
is converted to an expression that has type ‘‘pointer to function
returning type’’.

HHH(DD) specifies a function designator whose termination status is to
be investigated. That designator is (as outlined above) converted to a
pointer. It's how you tell which function to emulate.

HHH is reporting on DD, because you ask it to. And the function that
does the asking is DD. The DD in HHH(DD) and the DD in int DD() are one
and the same DD. Not because I say so, but because C says so.

Don't take my word for it. Ask any C expert. Kaz, for example, or
Keith.

There is only one DD.

Recursion can let you have multiple instances of a function, and each
even has its own locals, but they are the same function, and it is the
*function*, not a mere instance, that HHH has been asked to assess.

Yes and when HHH(DD) does report on the actual behavior that its actual
input actually specifies as measured by DD correctly simulated by HHH
that includes that HHH does simulate an instance of itself simulating an instance of DD that does call yet another instance of HHH(DD) then
HHH(DD)=0 is proven to be correct.

If HHH(DD)=0 then DD() will halt so HHH is proven to be incorrect.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 15:06:06 -0500, olcott wrote:

If you ignore that a million times you will be wrong a million times.

A classic case of psychological projection.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 14:58:58 -0500, olcott wrote:

On 8/13/2025 2:47 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:39:27 -0500, olcott wrote:

On 8/13/2025 2:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:27:48 -0500, olcott wrote:

On 8/13/2025 2:14 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:07:13 -0500, olcott wrote:

The DD stack cannot possibly unwind because there is nothing
driving the behavior of DD after HHH aborts its simulation of DD. >>>>>>

False, main() is calling DD().

/Flibble

More precisely there is nothing driving the behavior of DD correctly >>>>> simulated by HHH after HHH quits simulating DD.

Also the directly executed DD (caller of HHH) has always been
invisible to this HHH, hence not in the scope of this HHH.

The directly executed DD doesn't have to be visible to HHH,

So you expect HHH to have psychic ability?

HHH just needs to be passed a *description* of DD

Yet I proved (and everyone consistently makes sure to totally ignore
every single day for three years) DD correctly simulated by HHH has
different behavior than DD().

And that different behaviour confirms the extant Halting Problem proofs
are correct!

/Flibble

Not when the halting problem is corrected to be consistent with the way
that Turing machines actually work.

When we assume that Turing machines do not have the psychic ability to
see the behavior of their caller, then HHH(DD)==0 is correct.

A Halting Problem proof does not have to be predicated on Turing Machines.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <107iqq2$2lnd$9@dont-email.me>,
olcott <polcott333@gmail.com> wrote:

Not when the halting problem is corrected to be
consistent with the way that Turing machines actually
work.

When we assume that Turing machines do not have the
psychic ability to see the behavior of their caller,
then HHH(DD)==0 is correct.

Well, the REAL question is whether the State of California has
determined if HHH(DD) has chemicals that may be harmful to
children or pregnant people.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <107ir7e$2lnd$11@dont-email.me>,
olcott <polcott333@gmail.com> wrote:

On 8/13/2025 3:01 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:55:46 -0500, olcott wrote:

On 8/13/2025 2:40 PM, Richard Heathfield wrote:

On 13/08/2025 19:14, olcott wrote:

When HHH(DD) does return the result to its caller. it is never
reporting on the behavior of its caller.

Some C for you.

A function definition includes the function body.

The identifier declared in a function definition (which is the name of >>>> the function) shall have a function type, as specified by the
declarator portion of the function definition.

A function designator is an expression that has function type.
Except when it is the operand of the sizeof operator or the unary &
operator, a function designator with type ‘‘function returning type’’
is converted to an expression that has type ‘‘pointer to function
returning type’’.

HHH(DD) specifies a function designator whose termination status is to >>>> be investigated. That designator is (as outlined above) converted to a >>>> pointer. It's how you tell which function to emulate.

HHH is reporting on DD, because you ask it to. And the function that
does the asking is DD. The DD in HHH(DD) and the DD in int DD() are one >>>> and the same DD. Not because I say so, but because C says so.

Don't take my word for it. Ask any C expert. Kaz, for example, or
Keith.

There is only one DD.

Recursion can let you have multiple instances of a function, and each
even has its own locals, but they are the same function, and it is the >>>> *function*, not a mere instance, that HHH has been asked to assess.

Yes and when HHH(DD) does report on the actual behavior that its actual
input actually specifies as measured by DD correctly simulated by HHH
that includes that HHH does simulate an instance of itself simulating an >>> instance of DD that does call yet another instance of HHH(DD) then
HHH(DD)=0 is proven to be correct.

If HHH(DD)=0 then DD() will halt so HHH is proven to be incorrect.

/Flibble

Ignoring my corrections to your misconceptions is not
actually any rebuttal at all.

These corrections...Are they in the room with us, now?

No halt decider or termination analyzer can possibly
correctly report on anything other than the behavior
that is finite string input specifies.

If you ignore that a million times you will be wrong
a million times.

If a tree falls in the woods, does DD(HHH) hear it?

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 15:16:51 -0500, olcott wrote:

On 8/13/2025 3:08 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:58:58 -0500, olcott wrote:

On 8/13/2025 2:47 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:39:27 -0500, olcott wrote:

On 8/13/2025 2:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:27:48 -0500, olcott wrote:

On 8/13/2025 2:14 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:07:13 -0500, olcott wrote:

The DD stack cannot possibly unwind because there is nothing >>>>>>>>> driving the behavior of DD after HHH aborts its simulation of >>>>>>>>> DD.

False, main() is calling DD().

/Flibble

More precisely there is nothing driving the behavior of DD
correctly simulated by HHH after HHH quits simulating DD.

Also the directly executed DD (caller of HHH) has always been
invisible to this HHH, hence not in the scope of this HHH.

The directly executed DD doesn't have to be visible to HHH,

So you expect HHH to have psychic ability?

HHH just needs to be passed a *description* of DD

Yet I proved (and everyone consistently makes sure to totally ignore >>>>> every single day for three years) DD correctly simulated by HHH has
different behavior than DD().

And that different behaviour confirms the extant Halting Problem
proofs are correct!

/Flibble

Not when the halting problem is corrected to be consistent with the
way that Turing machines actually work.

When we assume that Turing machines do not have the psychic ability to
see the behavior of their caller, then HHH(DD)==0 is correct.

A Halting Problem proof does not have to be predicated on Turing
Machines.

/Flibble

Hence the reason why I specified this in the 100% concrete form of C functions. This is specific enough to prove that misconceptions are
false. Without this degree of concrete specificity misconceptions
forever remain as unresolved differences of opinion.

That Heathfield does not want to bother going through the effort to
prove to himself that he is wrong does not prove that he is right.

No, it means there are proofs proving the Halting Problem is undecidable without reference to Turing Machines.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Blimey, olcott - 413 lines! Learn to snip, why don't you?

On 13/08/2025 20:07, olcott wrote:

On 8/13/2025 1:20 PM, Richard Heathfield wrote:

<snip - count chevrons for attribs>

Point out the instruction that was emulated
incorrectly or acknowledge that you cannot.

Why should I?

(a) It's your bug to find.

You will not accept that there is no bug until
you look for this yourself and find none.

You assume the bug, if any, is in the code. It isn't. Well, it
might be; I'd be very surprised if it were bug-free. But the real
bug is in the design. Hence (b) below.

(b) Even if you find it, it won't matter, for reasons I
outlined (again!) in my last reply.
Why should anyone even bother to look?

Because it proves that the counter-example input
to the halting problem is decidable when one uses
a different criterion measure.

But that's not your choice to make. Either it halts or it
doesn't. That is the only criterion, and the only measure
available is halts vs doesn't halt.

Until this is understood it cannot be understood
the the original criterion measure is incorrect.

That's not your call. The original question was whether a program
can be written that is capable of determining for any given
arbitrary program whether it halts. And we already know the
answer: no.

That is what Turing proved. If you want to attack his proof,
that's the question you have to tackle. Calling it "incorrect" is
just weaseling out, but it's just your word against a remarkably
clear and simple proof.

No matter what your trace says, you still have only three
choices - return halt (wrong!), return loop (wrong!) or don't
return (wrong!). Whichever you choose, it's the wrong solution,
even if your trace is flawless.

Or return a value corresponding to the actual behavior
that the input actually specifies as measured by DD
correctly simulated by HHH.

No, HHH must report on the behaviour of the function it's asked
about - DD. Inspection shows that whatever HHH returns is wrong,
so HHH fails in its task.

When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.

You keep saying that, but you never stop to think what happens
when HHH /stops/ executing.

Nothing happens because all of the recursive simulations
were entirely driven by HHH simulating its own DD.

No, DD kicks it off. Here's the code, in case you forgot what it
looks like:

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

I can plug this into a main() easily enough:

int main(void)
{
int status = DD();
printf("DD returns %d\n", status);
return 0;
}

Since we know what HHH returns, we can even supply that:

int HHH(ptr P)
{
return 0;
}

It doesn't take much more work to knock those into an executable,
which will demonstrate beyond doubt that HH got it wrong.

How far can a car drive up a hill after it runs out of gas?

What's the difference between a wrong answer?

Your trace fails to show the stack unwinding after HHH has
reached its decision, all simulation is concluded, and DD
regains control at last.

Yes it does because the DD stack cannot possibly
unwind when HHH aborts its simulation of DD.

Then HHH fails to report, and fails to be a decider.

Conversely, if HHH instead returns 1 to reflect this, DD will
instead enter into its loop, again giving the lie to HHH's
return code.

That is not the behavior of the input.

How do you know? You don't simulate that far.

Yet another person that believes a simulation of a non-terminating
input is only correct when it reaches its non-existent end.

No, I'm yet another person who believes a "simulation" that gets
the wrong answer can hardly qualify as a simulation.

Maybe the problem is (as you have hinted) that you
don't have any actual programming experience?

It's a thought.

I'm not asking HHH to tell me anything but whether DD halts.

Then you cannot be talking about the directly executed
DD() in main that calls HHH(DD) because no termination
analyzer can possibly see its own caller.

So you concede that no termination analyser can analyse every
possible program, QED.

The DD stack cannot possibly unwind because there
is nothing driving the behavior of DD after HHH
aborts its simulation of DD.

You aborted the simulation, not the program.

int main(void)
{
int status = DD();
printf("DD returns %d\n", status);
return 0;
}

** As long as HHH has access to an x86 emulator that
provides the cooperative multi-taking infrastructure
required to implement this.

It doesn't matter. What happens when HHH returns?

int main()
{
  Output("Input_Halts = ", HHH(DD));

printf("DD reports "); fflush(stdout);
printf("%d\n", DD());
return 0;
}

Just as you are assured that you are self-evidently correct,
so I am sure that you self-evidently are mistaken. The x86
language has NOTHING to say on the correctness of your code;

It has everything to say about the correctness of DD
emulated by HHH.

Then you can save yourself a lot of clocks with this hack

int HHH(ptr P)
{
   return 0;
}

HHH works correctly with an infinite set of
inputs, Your suggestion would break that.

I've only seen it tried on one, and it gets that wrong.

I am shocked that everyone here thinks that recursive
emulation is incomprehensibly more difficult to understand
than ordinary recursion.

It isn't hard to understand. It's just irrelevant to the
question of whether HHH returns the correct value (which it
doesn't, by the way).

Unless you understand that
a termination analyzer only reports on the actual
behavior actually specified by its input and

HHH's input is DD. The actual behaviour it exhibits is to
confound HHH.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 15:20:58 -0500, olcott wrote:

On 8/13/2025 3:12 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 15:06:06 -0500, olcott wrote:

If you ignore that a million times you will be wrong a million times.

A classic case of psychological projection.

/Flibble

Until people find a 100% completely specific error in what I have been
saying about HHH(DD)==0 they will lack a sufficient basis to show that I
am not entirely correct.

Your 100% completely specific error is that if HHH(DD)==0 then DD() will
halt thus confirming that the extant Halting Problem proofs are correct
which runs contrary to your claim.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 21:02, olcott wrote:

On 8/13/2025 2:49 PM, Richard Heathfield wrote:

On 13/08/2025 19:27, olcott wrote:

<snip>

Although is may seem that my understanding is incorrect
a deeper understanding of the fundamental nature of Turing
machines and computable functions proves that it is
incorrect to expect a TM to report on the behavior of
its caller.

Trying hard not to laugh, let's pretend that we buy this
"deeper understanding" bollocks... but I don't think you've
thought it through.

DD calls HHH, so your claim is tantamount to saying that it is
incorrect for DD to pass DD to HHH.

It is not passing a pointer to its executing process
table within the operating system it is passing a
pointer to a static finite string of its machine code.

Wrong. It's passing an int(*)(void).

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 21:49, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

<snip>

You assume the bug, if any, is in the code. It isn't. Well, it
might be; I'd be very surprised if it were bug-free. But the
real bug is in the design. Hence (b) below.

<restoring for context>
(b) Even if you find it, it won't matter, for reasons I outlined
(again!) in my last reply.

You are the one trying to get away with saying
that DD is not correctly simulated by HHH.

By returning 0 as you say it should, HHH claims that DD never halts.
On receiving 0 from HHH, DD promptly halts.

It's astonishing that you can view this behaviour as correct and
still expect to be treated seriously.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 22:13:24 +0100, Richard Heathfield wrote:

On 13/08/2025 21:49, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

<snip>

You assume the bug, if any, is in the code. It isn't. Well, it might
be; I'd be very surprised if it were bug-free. But the real bug is in
the design. Hence (b) below.

<restoring for context>
(b) Even if you find it, it won't matter, for reasons I outlined
(again!) in my last reply.

You are the one trying to get away with saying that DD is not correctly
simulated by HHH.

By returning 0 as you say it should, HHH claims that DD never halts.
On receiving 0 from HHH, DD promptly halts.

It's astonishing that you can view this behaviour as correct and still
expect to be treated seriously.

The point at which people might treat Olcott seriously has long since
passed.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <107inp3$2lnd$1@dont-email.me>,
olcott <polcott333@gmail.com> wrote:

How far can a car drive up a hill after it runs out of gas?

Depends. Can HHH be safely used as a solvent in industrial
applications?

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 22:13, dbush wrote:

<snip>

Let the record show that Peter Olcott has admitted that HHH
violates the semantics of the x86 language by aborting is
simulation, and that DD is therefore NOT correctly simulated by HHH.

Let the record further show that this is self-evident from DD's
source code.

Clearly, whatever HHH returns is wrong. Why has it taken Olcott
22 years not to notice this?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 17:22:56 -0500, olcott wrote:

On 8/13/2025 4:13 PM, dbush wrote:

On 8/13/2025 5:09 PM, olcott wrote:

On 8/13/2025 4:08 PM, dbush wrote:

On 8/13/2025 5:06 PM, olcott wrote:

On 8/13/2025 3:51 PM, dbush wrote:

On 8/13/2025 4:49 PM, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

Blimey, olcott - 413 lines! Learn to snip, why don't you?

On 13/08/2025 20:07, olcott wrote:

On 8/13/2025 1:20 PM, Richard Heathfield wrote:

<snip - count chevrons for attribs>

Point out the instruction that was emulated incorrectly or >>>>>>>>>>> acknowledge that you cannot.

Why should I?

(a) It's your bug to find.

You will not accept that there is no bug until you look for this >>>>>>>>> yourself and find none.

You assume the bug, if any, is in the code. It isn't. Well, it >>>>>>>> might be; I'd be very surprised if it were bug-free. But the real >>>>>>>> bug is in the design. Hence (b) below.

You are the one trying to get away with saying that DD is not
correctly simulated by HHH.

As long as HHH emulates the instructions of DD according to the
semantics of the x86 language then there is no bug in the code or >>>>>>> anywhere else with the emulation of DD by HHH.

Which it doesn't because it aborts in violation of semantics of the >>>>>> x86 language.  So the last instruction that was emulated was not
emulated correctly.

When HHH(DD) does report on the actual behavior that its actual
input actually specifies as measured by DD correctly simulated by
HHH

Then you don't have a measure because DD is not correctly simulated
by HHH because it aborts in violation of semantics of the x86
language.

<< irrelevant copy-paste response >>

A copy-paste response that is unrelated to what you responded to is
less that no rebuttal, and is in fact you admission that what was
responded to is correct.  So...

Let the record show that Peter Olcott has admitted that HHH violates
the semantics of the x86 language by aborting is simulation, and that
DD is therefore NOT correctly simulated by HHH.

HHH correctly simulates N instructions of DD.

So it can return the associated halting result to DD() and DD() can go on
to do the opposite thus confirming extant Halting Problem proofs to be
correct.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 18:28:52 -0500, olcott wrote:

On 8/13/2025 6:21 PM, wij wrote:

On Wed, 2025-08-13 at 18:14 -0500, olcott wrote:

On 8/13/2025 6:08 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 17:22:56 -0500, olcott wrote:

On 8/13/2025 4:13 PM, dbush wrote:

On 8/13/2025 5:09 PM, olcott wrote:

On 8/13/2025 4:08 PM, dbush wrote:

On 8/13/2025 5:06 PM, olcott wrote:

On 8/13/2025 3:51 PM, dbush wrote:

On 8/13/2025 4:49 PM, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

Blimey, olcott - 413 lines! Learn to snip, why don't you? >>>>>>>>>>>>
On 13/08/2025 20:07, olcott wrote:

On 8/13/2025 1:20 PM, Richard Heathfield wrote:

<snip - count chevrons for attribs>

Point out the instruction that was emulated incorrectly or >>>>>>>>>>>>>>> acknowledge that you cannot.

Why should I?

(a) It's your bug to find.

You will not accept that there is no bug until you look for >>>>>>>>>>>>> this yourself and find none.

You assume the bug, if any, is in the code. It isn't. Well, >>>>>>>>>>>> it might be; I'd be very surprised if it were bug-free. But >>>>>>>>>>>> the real bug is in the design. Hence (b) below.

You are the one trying to get away with saying that DD is not >>>>>>>>>>> correctly simulated by HHH.

As long as HHH emulates the instructions of DD according to >>>>>>>>>>> the semantics of the x86 language then there is no bug in the >>>>>>>>>>> code or anywhere else with the emulation of DD by HHH.

Which it doesn't because it aborts in violation of semantics of >>>>>>>>>> the x86 language.  So the last instruction that was emulated >>>>>>>>>> was not emulated correctly.

When HHH(DD) does report on the actual behavior that its actual >>>>>>>>> input actually specifies as measured by DD correctly simulated >>>>>>>>> by HHH

Then you don't have a measure because DD is not correctly
simulated by HHH because it aborts in violation of semantics of >>>>>>>> the x86 language.

<< irrelevant copy-paste response >>

A copy-paste response that is unrelated to what you responded to is >>>>>> less that no rebuttal, and is in fact you admission that what was
responded to is correct.  So...

Let the record show that Peter Olcott has admitted that HHH
violates the semantics of the x86 language by aborting is
simulation, and that DD is therefore NOT correctly simulated by
HHH.

HHH correctly simulates N instructions of DD.

So it can return the associated halting result to DD() and DD() can
go on to do the opposite thus confirming extant Halting Problem
proofs to be correct.

/Flibble

How many times do I have to tell you that HHH is not accountable for
the behavior of its caller because it cannot see the behavior of its
caller before you stop ignoring this?

So, you are not talking about The Halting Problem:

H(D)=1 iff D() halts.

The halting problem requires a halt decider to have psychic ability that Turing machines do not have.

Ah but there's the rub: as a hypothetical lets assume a halt decider did
have psychic ability: even then it would get the answer wrong because DD() would still do the opposite, as proven by the extant Halting Problem
proofs.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 18:47:14 -0500, olcott wrote:

On 8/13/2025 6:43 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 18:28:52 -0500, olcott wrote:

On 8/13/2025 6:21 PM, wij wrote:

On Wed, 2025-08-13 at 18:14 -0500, olcott wrote:

On 8/13/2025 6:08 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 17:22:56 -0500, olcott wrote:

On 8/13/2025 4:13 PM, dbush wrote:

On 8/13/2025 5:09 PM, olcott wrote:

On 8/13/2025 4:08 PM, dbush wrote:

On 8/13/2025 5:06 PM, olcott wrote:

On 8/13/2025 3:51 PM, dbush wrote:

On 8/13/2025 4:49 PM, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

Blimey, olcott - 413 lines! Learn to snip, why don't you? >>>>>>>>>>>>>>
On 13/08/2025 20:07, olcott wrote:

On 8/13/2025 1:20 PM, Richard Heathfield wrote:

<snip - count chevrons for attribs>

Point out the instruction that was emulated incorrectly >>>>>>>>>>>>>>>>> or acknowledge that you cannot.

Why should I?

(a) It's your bug to find.

You will not accept that there is no bug until you look >>>>>>>>>>>>>>> for this yourself and find none.

You assume the bug, if any, is in the code. It isn't. Well, >>>>>>>>>>>>>> it might be; I'd be very surprised if it were bug-free. But >>>>>>>>>>>>>> the real bug is in the design. Hence (b) below.

You are the one trying to get away with saying that DD is >>>>>>>>>>>>> not correctly simulated by HHH.

As long as HHH emulates the instructions of DD according to >>>>>>>>>>>>> the semantics of the x86 language then there is no bug in >>>>>>>>>>>>> the code or anywhere else with the emulation of DD by HHH. >>>>>>>>>>>>

Which it doesn't because it aborts in violation of semantics >>>>>>>>>>>> of the x86 language.  So the last instruction that was >>>>>>>>>>>> emulated was not emulated correctly.

When HHH(DD) does report on the actual behavior that its >>>>>>>>>>> actual input actually specifies as measured by DD correctly >>>>>>>>>>> simulated by HHH

Then you don't have a measure because DD is not correctly
simulated by HHH because it aborts in violation of semantics of >>>>>>>>>> the x86 language.

<< irrelevant copy-paste response >>

A copy-paste response that is unrelated to what you responded to >>>>>>>> is less that no rebuttal, and is in fact you admission that what >>>>>>>> was responded to is correct.  So...

Let the record show that Peter Olcott has admitted that HHH
violates the semantics of the x86 language by aborting is
simulation, and that DD is therefore NOT correctly simulated by >>>>>>>> HHH.

HHH correctly simulates N instructions of DD.

So it can return the associated halting result to DD() and DD() can >>>>>> go on to do the opposite thus confirming extant Halting Problem
proofs to be correct.

/Flibble

How many times do I have to tell you that HHH is not accountable for >>>>> the behavior of its caller because it cannot see the behavior of its >>>>> caller before you stop ignoring this?

So, you are not talking about The Halting Problem:

H(D)=1 iff D() halts.

The halting problem requires a halt decider to have psychic ability
that Turing machines do not have.

Ah but there's the rub: as a hypothetical lets assume a halt decider
did have psychic ability: even then it would get the answer wrong
because DD()
would still do the opposite, as proven by the extant Halting Problem
proofs.

/Flibble

You said that you are an expert on C.
I believe you.
An expert on C would understand that DD correctly simulated by HHH
cannot possibly reach its "do the opposite" code.
Are you really an expert on C?

If HHH(DD) does not return a halting result to its caller (DD() in this
case) then it is not a halt decider.

You said in an earlier reply that HHH(DD) does eventually "report", I
asked you what it reported and to whom but you failed to give a
satisfactory response, would you like another opportunity to give an
honest response with no smoke and mirrors?

Yes, I am an expert on C -- I have been coding C++ since 1993.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 19:03:32 -0500, olcott wrote:

On 8/13/2025 6:55 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 18:47:14 -0500, olcott wrote:

On 8/13/2025 6:43 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 18:28:52 -0500, olcott wrote:

On 8/13/2025 6:21 PM, wij wrote:

On Wed, 2025-08-13 at 18:14 -0500, olcott wrote:

On 8/13/2025 6:08 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 17:22:56 -0500, olcott wrote:

On 8/13/2025 4:13 PM, dbush wrote:

On 8/13/2025 5:09 PM, olcott wrote:

On 8/13/2025 4:08 PM, dbush wrote:

On 8/13/2025 5:06 PM, olcott wrote:

On 8/13/2025 3:51 PM, dbush wrote:

On 8/13/2025 4:49 PM, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> Blimey, olcott - 413 lines! Learn to snip, why don't you? >>>>>>>>>>>>>>>>

On 13/08/2025 20:07, olcott wrote:

On 8/13/2025 1:20 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>>

<snip - count chevrons for attribs>

Point out the instruction that was emulated >>>>>>>>>>>>>>>>>>> incorrectly or acknowledge that you cannot. >>>>>>>>>>>>>>>>>>

Why should I?

(a) It's your bug to find.

You will not accept that there is no bug until you look >>>>>>>>>>>>>>>>> for this yourself and find none.

You assume the bug, if any, is in the code. It isn't. >>>>>>>>>>>>>>>> Well,
it might be; I'd be very surprised if it were bug-free. >>>>>>>>>>>>>>>> But the real bug is in the design. Hence (b) below. >>>>>>>>>>>>>>>>

You are the one trying to get away with saying that DD is >>>>>>>>>>>>>>> not correctly simulated by HHH.

As long as HHH emulates the instructions of DD according >>>>>>>>>>>>>>> to the semantics of the x86 language then there is no bug >>>>>>>>>>>>>>> in the code or anywhere else with the emulation of DD by >>>>>>>>>>>>>>> HHH.

Which it doesn't because it aborts in violation of >>>>>>>>>>>>>> semantics of the x86 language.  So the last instruction >>>>>>>>>>>>>> that was emulated was not emulated correctly.

When HHH(DD) does report on the actual behavior that its >>>>>>>>>>>>> actual input actually specifies as measured by DD correctly >>>>>>>>>>>>> simulated by HHH

Then you don't have a measure because DD is not correctly >>>>>>>>>>>> simulated by HHH because it aborts in violation of semantics >>>>>>>>>>>> of the x86 language.

<< irrelevant copy-paste response >>

A copy-paste response that is unrelated to what you responded >>>>>>>>>> to is less that no rebuttal, and is in fact you admission that >>>>>>>>>> what was responded to is correct.  So...

Let the record show that Peter Olcott has admitted that HHH >>>>>>>>>> violates the semantics of the x86 language by aborting is
simulation, and that DD is therefore NOT correctly simulated by >>>>>>>>>> HHH.

HHH correctly simulates N instructions of DD.

So it can return the associated halting result to DD() and DD() >>>>>>>> can go on to do the opposite thus confirming extant Halting
Problem proofs to be correct.

/Flibble

How many times do I have to tell you that HHH is not accountable >>>>>>> for the behavior of its caller because it cannot see the behavior >>>>>>> of its caller before you stop ignoring this?

So, you are not talking about The Halting Problem:

H(D)=1 iff D() halts.

The halting problem requires a halt decider to have psychic ability
that Turing machines do not have.

Ah but there's the rub: as a hypothetical lets assume a halt decider
did have psychic ability: even then it would get the answer wrong
because DD()
would still do the opposite, as proven by the extant Halting Problem
proofs.

/Flibble

You said that you are an expert on C.
I believe you.
An expert on C would understand that DD correctly simulated by HHH
cannot possibly reach its "do the opposite" code.
Are you really an expert on C?

If HHH(DD) does not return a halting result to its caller (DD() in this
case) then it is not a halt decider.

Yes. On the other hand no Turing machine has ever been able to report on
the behavior *OF ITS CALLER*.

You said in an earlier reply that HHH(DD) does eventually "report", I
asked you what it reported and to whom but you failed to give a
satisfactory response, would you like another opportunity to give an
honest response with no smoke and mirrors?

Yes, I am an expert on C -- I have been coding C++ since 1993.

/Flibble

I go all the way back to when K&R was the only standard.
I met Bjarne Stroustrup came to my university to promote is brand new programming language: C++.

You ignored my question so I will ask it again: what does HHH(DD) report
and to whom?

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Aug 2025 19:08:47 -0500, olcott wrote:

On 8/13/2025 7:05 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 19:03:32 -0500, olcott wrote:

On 8/13/2025 6:55 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 18:47:14 -0500, olcott wrote:

On 8/13/2025 6:43 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 18:28:52 -0500, olcott wrote:

On 8/13/2025 6:21 PM, wij wrote:

On Wed, 2025-08-13 at 18:14 -0500, olcott wrote:

On 8/13/2025 6:08 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 17:22:56 -0500, olcott wrote:

On 8/13/2025 4:13 PM, dbush wrote:

On 8/13/2025 5:09 PM, olcott wrote:

On 8/13/2025 4:08 PM, dbush wrote:

On 8/13/2025 5:06 PM, olcott wrote:

On 8/13/2025 3:51 PM, dbush wrote:

On 8/13/2025 4:49 PM, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>>>> Blimey, olcott - 413 lines! Learn to snip, why don't >>>>>>>>>>>>>>>>>> you?

On 13/08/2025 20:07, olcott wrote:

On 8/13/2025 1:20 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>>>>

<snip - count chevrons for attribs>

Point out the instruction that was emulated >>>>>>>>>>>>>>>>>>>>> incorrectly or acknowledge that you cannot. >>>>>>>>>>>>>>>>>>>>

Why should I?

(a) It's your bug to find.

You will not accept that there is no bug until you >>>>>>>>>>>>>>>>>>> look for this yourself and find none.

You assume the bug, if any, is in the code. It isn't. >>>>>>>>>>>>>>>>>> Well,
it might be; I'd be very surprised if it were bug-free. >>>>>>>>>>>>>>>>>> But the real bug is in the design. Hence (b) below. >>>>>>>>>>>>>>>>>>

You are the one trying to get away with saying that DD >>>>>>>>>>>>>>>>> is not correctly simulated by HHH.

As long as HHH emulates the instructions of DD according >>>>>>>>>>>>>>>>> to the semantics of the x86 language then there is no >>>>>>>>>>>>>>>>> bug in the code or anywhere else with the emulation of >>>>>>>>>>>>>>>>> DD by HHH.

Which it doesn't because it aborts in violation of >>>>>>>>>>>>>>>> semantics of the x86 language.  So the last instruction >>>>>>>>>>>>>>>> that was emulated was not emulated correctly.

When HHH(DD) does report on the actual behavior that its >>>>>>>>>>>>>>> actual input actually specifies as measured by DD >>>>>>>>>>>>>>> correctly simulated by HHH

Then you don't have a measure because DD is not correctly >>>>>>>>>>>>>> simulated by HHH because it aborts in violation of >>>>>>>>>>>>>> semantics of the x86 language.

<< irrelevant copy-paste response >>

A copy-paste response that is unrelated to what you responded >>>>>>>>>>>> to is less that no rebuttal, and is in fact you admission >>>>>>>>>>>> that what was responded to is correct.  So...

Let the record show that Peter Olcott has admitted that HHH >>>>>>>>>>>> violates the semantics of the x86 language by aborting is >>>>>>>>>>>> simulation, and that DD is therefore NOT correctly simulated >>>>>>>>>>>> by HHH.

HHH correctly simulates N instructions of DD.

So it can return the associated halting result to DD() and DD() >>>>>>>>>> can go on to do the opposite thus confirming extant Halting >>>>>>>>>> Problem proofs to be correct.

/Flibble

How many times do I have to tell you that HHH is not accountable >>>>>>>>> for the behavior of its caller because it cannot see the
behavior of its caller before you stop ignoring this?

So, you are not talking about The Halting Problem:

H(D)=1 iff D() halts.

The halting problem requires a halt decider to have psychic
ability that Turing machines do not have.

Ah but there's the rub: as a hypothetical lets assume a halt
decider did have psychic ability: even then it would get the answer >>>>>> wrong because DD()
would still do the opposite, as proven by the extant Halting
Problem proofs.

/Flibble

You said that you are an expert on C.
I believe you.
An expert on C would understand that DD correctly simulated by HHH
cannot possibly reach its "do the opposite" code.
Are you really an expert on C?

If HHH(DD) does not return a halting result to its caller (DD() in
this case) then it is not a halt decider.

Yes. On the other hand no Turing machine has ever been able to report
on the behavior *OF ITS CALLER*.

You said in an earlier reply that HHH(DD) does eventually "report", I
asked you what it reported and to whom but you failed to give a
satisfactory response, would you like another opportunity to give an
honest response with no smoke and mirrors?

Yes, I am an expert on C -- I have been coding C++ since 1993.

/Flibble

I go all the way back to when K&R was the only standard.
I met Bjarne Stroustrup came to my university to promote is brand new
programming language: C++.

You ignored my question so I will ask it again: what does HHH(DD)
report and to whom?

/Flibble

The outermost HHH(DD) reports to its caller.

And if its caller is DD() then DD() will do the opposite thus confirming
the extant Halting Problem proofs are correct.

More importantly, the key point that every computer scientist in the
world failed to notice for 89 years is that HHH NEVER REPORTS ON THE
BEHAVIOR OF ITS CALLER

No, it is REPORTING *TO ITS CALLER* WHICH IS DD().

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/08/2025 23:20, olcott wrote:

On 8/13/2025 4:13 PM, Richard Heathfield wrote:

On 13/08/2025 21:49, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

<snip>

You assume the bug, if any, is in the code. It isn't. Well,
it might be; I'd be very surprised if it were bug-free. But
the real bug is in the design. Hence (b) below.

<restoring for context>
(b) Even if you find it, it won't matter, for reasons I
outlined (again!) in my last reply.

You are the one trying to get away with saying
that DD is not correctly simulated by HHH.

By returning 0 as you say it should, HHH claims that DD never
halts.

No as I have told you 100 times HHH is not claiming
one damn thing about the behavior of its own caller.

Your weary tone is noted. I'm not surprised you're sick and tired
of telling me you haven't screwed up... but you have, all the same.

If HHH(DD) fails to report a value *to* DD *about* DD, it fails
in its task, confirming that HHH is not 'correct'... because if
it doesn't do its job it's not anything.

That I have told you this 100 times and you still
don't get it is no error on my part.

If you think you can distinguish between the DD that invokes
HHH(DD) and the DD that is passed to DD, it is indeed an error on
your part. Both DDs indicate the same function. C guarantees it.

On receiving 0 from HHH, DD promptly halts.

It's astonishing that you can view this behaviour as correct
and still expect to be treated seriously.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 00:03, olcott wrote:

Within the assumption that HHH must have psychic
ability to report on behavior that it cannot see.

Nobody expects that. What they do expect is for HHH to fail to do
its job correctly, because it Just Can't report on behaviour it
can't see, behaviour that it *needs* to know about in order to do
its job.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 00:14, olcott wrote:

<snip>

How many times do I have to tell you that HHH is
not accountable for the behavior of its caller
because it cannot see the behavior of its caller
before you stop ignoring this?

How many times do you have to be told that HHH is not granted
licence to get the wrong answer just because getting the right
answer is impossible?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 00:28, olcott wrote:

On 8/13/2025 6:21 PM, wij wrote:

On Wed, 2025-08-13 at 18:14 -0500, olcott wrote:

<snip>

How many times do I have to tell you that HHH is
not accountable for the behavior of its caller
because it cannot see the behavior of its caller
before you stop ignoring this?

So, you are not talking about The Halting Problem:

   H(D)=1 iff D() halts.

The halting problem requires a halt decider to
have psychic ability that Turing machines do not have.

Is that a concession that no universal halt decider can be
written? About bloody time.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 00:42, olcott wrote:

<snip>

The halting function is computable when one
does not require it to have psychic ability
to report on something that it cannot see.

There is *nothing* stopping you from showing HHH the whole of DD.

All you have to do is pass it another parameter stating the
filename of the source code, thus removing the need to guess and
eliminating any requirement for psychic ability.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 10:42 AM, olcott wrote:

On 8/13/2025 1:45 AM, Richard Heathfield wrote:

On 13/08/2025 06:59, olcott wrote:

On 8/13/2025 12:43 AM, Richard Heathfield wrote:

On 13/08/2025 06:30, olcott wrote:

You ask: How is this answer not self-evident ?

Simulating Termination Analyzer HHH correctly simulates its input

To you, the above is self-evident. To me (and to several others
here), it is not. Your attempts to explain it with x86 traces are
unconvincing because they lack explanatory power.

So you cannot see that when HHH(DD) is executed that
this begins simulating DD that calls HHH(DD) that
begins simulating DD that calls HHH(DD) again ???

You are skipping lightly over the word "correctly".

Because when I delve deeper into this it seems
to exceed your technical capacity. The x86 language
is the ultimate measure of correct simulation.

In plainer words, you are just showing that you can't go into more
detail, as that makes your lies clear, so you need to use approximations
to hide your errors that the more precise discussion makes clear.

Sorry, that is just one of the classic techniques of liars.

To you, clearly, your work is flawless. I realise that that's never
going to change no matter what anyone says, but there are those of us
who disagree with you.

If you would merely understand the x86 code and understand
that the x86 language is the ultimate measure of correct
simulation then you would agree with me.

You mean like the fact that the correct emulaiton of code doesn't depend
on the context of the emulator?

Three different LLM systems could see the recursive
emulation on their own without prompting on the basis
of the semantics of the C code.

Which is meaningless, as you feed them all the same biased description,
that when fixed lets them give the answer you reject.

SO, are LLMs reliable? if so, then you need to accept that they say you
are wrong.

If they aren't, you are just showing you logic is baseless as it is
based on something unreliable.

That three different systems see that actual execution
trace and no one can point to any specific error in this
execution trace seems to prove that I am correct.

Dogmatically saying that I am wrong without being able
to show exactly which instruction was simulated incorrectly
does not seem to count as any actual rebuttal.

But we HAVE, and you haven't shown how it was.

Sorry, you are just and proven LIAR.

Do you have many years as a C/C++ programmer?

I have more than you.

We have explained why until we're blue in the face. I see no value in
going for magenta.


<snip>

What value should HHH(DD) correctly return?

Well, it can't return a correct value, because no matter what it
reports DD will turn on its head. And *that* is self-evident.

Can you see how DD correctly simulated by HHH never
reaches its "if" statement?

No, and I can't see how it's relevant even if your claim of
correctness were true.

(a) "correctly" is subject to debate, at the very least;
(b) DD correctly executed directly on its host platform CAN reach its
"if" statement as soon as HHH reports. If HHH fails to report, it's
not a decider.
(c) as soon as DD correctly executed directly on its host platform
DOES reach its "if" statement, you're screwed because DD turns HHH's
report upside down.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 01:39, dbush wrote:

On 8/13/2025 8:26 PM, olcott wrote:

On 8/13/2025 7:19 PM, dbush wrote:

On 8/13/2025 7:58 PM, olcott wrote:

On 8/13/2025 6:43 PM, dbush wrote:

On 8/13/2025 7:42 PM, olcott wrote:

On 8/13/2025 6:38 PM, dbush wrote:

On 8/13/2025 7:03 PM, olcott wrote:

On 8/13/2025 5:43 PM, wij wrote:

On Wed, 2025-08-13 at 22:19 +0100, Richard Heathfield
wrote:

On 13/08/2025 22:13, dbush wrote:

<snip>

Let the record show that Peter Olcott has admitted
that HHH
violates the semantics of the x86 language by aborting is >>>>>>>>>>> simulation, and that DD is therefore NOT correctly
simulated by HHH.

Let the record further show that this is self-evident
from DD's
source code.

Clearly, whatever HHH returns is wrong.

Within the assumption that HHH must have psychic
ability to report on behavior that it cannot see.

When we come back to reality then we see that Turing
machine deciders only report on EXACTLY (not approximately)
what their finite string inputs tell them, exactly as
HHH reports that the actual behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES* is non halting.

In other words, the HHH you implemented is a partial halt
decider which computes *some* computable function which
overlaps with the halting function for some inputs and not
for others such as DD.

It does not compute the halting function because the
halting function is not computable, as Linz and others
have proved and as you have *explicitly* agreed is correct.

The halting function is computable when one
does not require it to have psychic ability
to report on something that it cannot see.

So again, you agree with Linz and Turning.

No one else in the world understood that there
never has been any actual input that does the
opposite of whatever its halt decider decides.

That's because what you're referring to as "halt decider" is
actually a partial halt decider, i.e. an actual Turing machine
that computes some computable function that overlaps with the
halting function for some inputs and not others.

The point is that no actual Turing machine can compute the
halting function.

No one notice that the halting problem is incorrect
for 89 years. It is wrong in the same way that the
math problem of computing the radius of a square
circle on the basis of the length of one of its equally
length four sides is wrong.

False.  The problem of computing the radius of a square circle
assumes such a thing exists.

Which it does. (As Randall Munroe would say: *Of course* there
is.) They're called octorads, they're well-defined, the ratio
between their area and their two key length properties is known,
and they look about as square as you could hope a circle to look
(or as circular as a square).

Olcott needs a new metaphor.

In contrast, whether or not an
arbitrary algorithm with a given input will halt has an answer in
all cases, and the follow-up question is asking IF a Turning
machine exists that can do this, and the answer is no.

Agreed.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 01:48, olcott wrote:

On 8/13/2025 7:39 PM, dbush wrote:

On 8/13/2025 8:26 PM, olcott wrote:

<snip>

No one notice that the halting problem is incorrect
for 89 years. It is wrong in the same way that the
math problem of computing the radius of a square
circle on the basis of the length of one of its equally
length four sides is wrong.

False.  The problem of computing the radius of a square circle
assumes such a thing exists.  In contrast, whether or not an
arbitrary algorithm with a given input will halt has an answer
in all cases, and the follow- up question is asking IF a
Turning machine exists that can do this, and the answer is no.

You must not know very much about programming.
No program can ever report on something that it cannot see.

You must not know very much about programming. You can show the
program *everything* by telling it where to find the subject's
source code. This is precisely what a UTM does when analysing a
TM - it reads the source code, because to a UTM the TM *is* the
source code.

What Turing showed is that even if your decider *can* see the
source code, there is at least one case it can't decide.

But failing to give HHH the information you say it needs to do
its job is your problem, not ours or Turing's.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 01:59, dbush wrote:

On 8/13/2025 8:48 PM, olcott wrote:

<snip>

You must not know very much about programming.
No program can ever report on something that it cannot see.

So again, you agree with Linz and Turning that the answer is no.

It seems a strange point at which to throw in the towel after 22
years, wouldn't you say? After all, UTMs are assumed to have
access to the whole TM they're analysing.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 03:32, olcott wrote:

On 8/13/2025 9:28 PM, Richard Heathfield wrote:

<snip>

If HHH(DD) fails to report a value *to* DD *about* DD,

When HHH(DD) does return to directly executed DD()
it is not reporting on the behavior of its caller.

It is reporting on the behaviour of DD. The clue is in the
argument. DD the argument refers to the same DD the caller. Ergo,
HHH is reporting on its caller.

Do I have to repeat that 10,000 times before
you notice that I said that at least once?

Why? Do you see any value in being wrong 10,000 times?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 03:37, olcott wrote:

On 8/13/2025 9:35 PM, Richard Heathfield wrote:

On 14/08/2025 00:03, olcott wrote:

Within the assumption that HHH must have psychic
ability to report on behavior that it cannot see.

Nobody expects that. What they do expect is for HHH to fail to
do its job correctly, because it Just Can't report on behaviour
it can't see, behaviour that it *needs* to know about in order
to do its job.

HHH(DD) does correctly report on the behavior
that it does see

And yet still it fails to untwist Turing's Tail. "Almost" doesn't
cut it.

even if you don't want to
bother to prove to yourself that HHH does
emulate DD correctly.

Don't you mean "emulate a subset of DD correctly"? Or are you now
claiming that HHH correctly emulates the parts of DD that HHH
cannot reach?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 03:48, olcott wrote:

<snip>

On that basis we can say that math is incomplete
because math cannot correctly compute the square
root of a dead cat.

Can we?

Shouldn't we wait for peer review?


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 03:50, olcott wrote:

On 8/13/2025 9:39 PM, Richard Heathfield wrote:

On 14/08/2025 00:28, olcott wrote:

<snip>

The halting problem requires a halt decider to
have psychic ability that Turing machines do not have.

Is that a concession that no universal halt decider can be
written? About bloody time.

Likewise math is incomplete because math cannot
correctly compute the square root of a dead cat.

Go tell it to JAMS.


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 04:01, olcott wrote:

On 8/13/2025 9:46 PM, Richard Heathfield wrote:

<snip>

There is *nothing* stopping you from showing HHH the whole of DD.

The whole of DD has different behavior when it
is an input to its own simulating halt decider.

It's already an input into its own halt decider.

HHH(DD) does correctly report on the behavior
that it was provided.

That is no excuse for failing to provide all pertinent facts to HHH.

You have complete information about DD; even /we/ have complete
information about DD. So why don't you give complete information
about DD to HHH? You have ALL relevant information at your
disposal, so you cannot use lack of information as an excuse for
getting the answer wrong.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 04:12, olcott wrote:

On 8/13/2025 9:57 PM, Richard Heathfield wrote:

On 14/08/2025 01:39, dbush wrote:

On 8/13/2025 8:26 PM, olcott wrote:

On 8/13/2025 7:19 PM, dbush wrote:

On 8/13/2025 7:58 PM, olcott wrote:

On 8/13/2025 6:43 PM, dbush wrote:

On 8/13/2025 7:42 PM, olcott wrote:

On 8/13/2025 6:38 PM, dbush wrote:

On 8/13/2025 7:03 PM, olcott wrote:

On 8/13/2025 5:43 PM, wij wrote:

On Wed, 2025-08-13 at 22:19 +0100, Richard Heathfield
wrote:

On 13/08/2025 22:13, dbush wrote:

<snip>

Let the record show that Peter Olcott has admitted
that HHH
violates the semantics of the x86 language by
aborting is
simulation, and that DD is therefore NOT correctly
simulated by HHH.

Let the record further show that this is self-evident
from DD's
source code.

Clearly, whatever HHH returns is wrong.

Within the assumption that HHH must have psychic
ability to report on behavior that it cannot see.

When we come back to reality then we see that Turing
machine deciders only report on EXACTLY (not
approximately)
what their finite string inputs tell them, exactly as
HHH reports that the actual behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES* is non halting.

In other words, the HHH you implemented is a partial
halt decider which computes *some* computable function
which overlaps with the halting function for some inputs
and not for others such as DD.

It does not compute the halting function because the
halting function is not computable, as Linz and others
have proved and as you have *explicitly* agreed is correct.

The halting function is computable when one
does not require it to have psychic ability
to report on something that it cannot see.

So again, you agree with Linz and Turning.

No one else in the world understood that there
never has been any actual input that does the
opposite of whatever its halt decider decides.

That's because what you're referring to as "halt decider" is
actually a partial halt decider, i.e. an actual Turing
machine that computes some computable function that overlaps
with the halting function for some inputs and not others.

The point is that no actual Turing machine can compute the
halting function.

No one notice that the halting problem is incorrect
for 89 years. It is wrong in the same way that the
math problem of computing the radius of a square
circle on the basis of the length of one of its equally
length four sides is wrong.

False.  The problem of computing the radius of a square circle
assumes such a thing exists.

Which it does.

No thing requiring simultaneous mutually exclusive
properties exists as anything but a misconception.

Suit yourself. Shut them eyes good n' tight.

The halting problem proof also exists yet only as
a misconception.

On the contrary, it exists as a problem in CS, one that is easy
to state, easy to understand, and easy to reason about.

It assumes a non-existent *INPUT* that does the
opposite of whatever its halt decider decides.

On the contrary, it assumes a universal halt decider can exist,
and then proves that the assumption is false.

After 22 years, you really ought to have figured that out by now.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 05:30, olcott wrote:

On 8/13/2025 10:33 PM, dbush wrote:

<snip>

On 5/5/2025 4:31 PM, dbush wrote:
 Strawman.  The square root of a dead
rabbit does not exist, but the question
of whether any arbitrary algorithm X
with input Y halts when executed directly.
has a correct answer in all cases.

Good point, yet an actual input that can do the opposite of
whatever its decider decides never existed, thus all the proofs
fall completely apart.

Such inputs are trivial to construct. You wrote one yourself.
That a function does not (yet) exist does not imply that it
cannot exist.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 06:01, olcott wrote:

<snip>

There exists no actual input that does the opposite
of its halt decider.

You are assuming that such a halt decider exists.

But if it does, we can construct a case that it can't handle.

This is a result known as the Halting Problem, and it was proved
decades ago. Do feel free to look it up.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 06:31, olcott wrote:

On 8/14/2025 12:26 AM, Richard Heathfield wrote:

On 14/08/2025 06:01, olcott wrote:

<snip>

There exists no actual input that does the opposite
of its halt decider.

You are assuming that such a halt decider exists.

No I am assuming that a proof of the undecidability
of the halting problem exists and finding that it does not.

https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf

There never has been any actual *INPUT* that does the opposite
of its decider.

First catch your decider.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 06:42, olcott wrote:

On 8/14/2025 12:36 AM, Richard Heathfield wrote:

On 14/08/2025 06:31, olcott wrote:

On 8/14/2025 12:26 AM, Richard Heathfield wrote:

On 14/08/2025 06:01, olcott wrote:

<snip>

There exists no actual input that does the opposite
of its halt decider.

You are assuming that such a halt decider exists.

No I am assuming that a proof of the undecidability
of the halting problem exists and finding that it does not.

https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf

There never has been any actual *INPUT* that does the opposite
of its decider.

First catch your decider.

M applied to ⟨M⟩ does the opposite
of what M.H ⟨M⟩ ⟨M⟩ says it does.

So not a decider, then.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 13.aug.2025 om 16:32 schreef olcott:

On 8/13/2025 8:33 AM, wij wrote:

On Wed, 2025-08-13 at 00:30 -0500, olcott wrote:

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.

(a),(b) are desired spec (or wishes), not fact.

They are premises that have been proved true on
some inputs.

There were no proofs, only your dreams.
The fact is that your published HHH fails, because it incorrectly
*assumes* non-termination, not detects non-termination.
The other fact is that both (a) and (b) lead to a contradiction,
proving that they are incorrect.
You can correct that by replacing (a):
(a) Assumes a non-termination pattern, where it does not exist: abort simulation and return 0.

Try that and the AI will show correct answers.
You cannot prove that HHH is correct by assuming in the premise that it
is correct.

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?

As you have encountered, HHH->DD->HHH->DD.... HHH and DD both will not
return

HHH(DD) should return 1 or 0 according to its desired spec.
But, HHH(DD) does not return. HHH does meet the desired spec.

You ignored the first premise, LLM
systems don't make that mistake.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 13 Aug 2025 15:49:25 -0500 schrieb olcott:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

Blimey, olcott - 413 lines! Learn to snip, why don't you?

On 13/08/2025 20:07, olcott wrote:

On 8/13/2025 1:20 PM, Richard Heathfield wrote:

Point out the instruction that was emulated incorrectly or
acknowledge that you cannot.

Why should I?
(a) It's your bug to find.

You will not accept that there is no bug until you look for this
yourself and find none.

You assume the bug, if any, is in the code. It isn't. Well, it might
be; I'd be very surprised if it were bug-free. But the real bug
is in the design. Hence (b) below.

As long as HHH emulates the instructions of DD according to the
semantics of the x86 language then there is no bug in the code or
anywhere else with the emulation of DD by HHH.

As long as. But it stops simulating them.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 13.aug.2025 om 19:23 schreef olcott:

On 8/13/2025 12:30 AM, olcott wrote:

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?

Dozens and dozens of reviewers across many different
forums in the last three years refuse to acknowledge
what every expert C programmer can see in less than
a minute: *The execution trace of DD simulated by HHH*

What would explain this?

As usual incorrect claims without evidence.

Olcott cannot find any expert C programmer to support his claim.
All experts up to now claim he is wrong.
(Because even beginners see that if HHH returns 0, it fails to predict
the halt status of DD.)
Still he keeps saying that all expert C programmers would see it.

What can explain such blindness?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 13.aug.2025 om 21:48 schreef olcott:

On 8/13/2025 2:37 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:30:40 -0500, olcott wrote:

On 8/13/2025 2:19 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:10:37 -0500, olcott wrote:

On 8/13/2025 1:29 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:27:37 -0500, olcott wrote:

On 8/13/2025 1:19 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:14:48 -0500, olcott wrote:

On 8/13/2025 1:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 13:03:33 -0500, olcott wrote:

On 8/13/2025 12:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:26:24 -0500, olcott wrote:

On 8/13/2025 12:13 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:12:03 -0500, olcott wrote:

On 8/13/2025 12:09 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 12:04:09 -0500, olcott wrote: >>>>>>>>>>>>>>>>

On 8/13/2025 11:59 AM, Mr Flibble wrote:

On Wed, 13 Aug 2025 00:30:56 -0500, olcott wrote: >>>>>>>>>>>>>>>>>>

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? >>>>>>>>>>>>>>>>>>

It doesn't f**king matter what HHH(DD) returns because >>>>>>>>>>>>>>>>>> DD()
will do the f**king opposite thus confirming the extant >>>>>>>>>>>>>>>>>> Halting Problem proofs are correct.

/Flibble

That you are an expert C programmer should prove to you >>>>>>>>>>>>>>>>> that the input to simulating termination analyzer cannot >>>>>>>>>>>>>>>>> possibly reach its own "do the opposite" code. >>>>>>>>>>>>>>>>

If HHH(DD) does not return a result to DD() then HHH is not >>>>>>>>>>>>>>>> a halt decider: halt deciders answer in finite time with a >>>>>>>>>>>>>>>> halting result.

/Flibble

I am only referring to your expertise in C to see this: >>>>>>>>>>>>>>>
When HHH(DD) is executed that this begins simulating DD that >>>>>>>>>>>>>>> calls HHH(DD) that begins simulating DD that calls HHH(DD) >>>>>>>>>>>>>>> again.

Again: if HHH(DD) does not return a halting result to DD() >>>>>>>>>>>>>> then HHH is not a halt decider.

/Flibble

As an expert C programmer what is the execution trace of DD >>>>>>>>>>>>> simulated by DD?

We can't cover the computer science of this until you answer >>>>>>>>>>>>> that question.

DD() is not simulating anything, it is calling HHH(DD), if HHH >>>>>>>>>>>> then starts a simulation resulting in infinite recursion then >>>>>>>>>>>> HHH isn't a halt decider as halt deciders return a halting >>>>>>>>>>>> result to their caller in finite time.

/Flibble

Three different LLM systems figured out that the execution trace >>>>>>>>>>> of DD correctly simulated by HHH does match the *recursive >>>>>>>>>>> simulation non-halting behavior pattern*
on their own without prompting that such a pattern even exists. >>>>>>>>>>>
The simulation shows DD calling HHH(DD) repeatedly
         This creates an infinite recursive loop in the >>>>>>>>>>>          simulation No simulated execution path leads to DD's
         return statement being reached
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>>
         In other words, simulating DD() requires simulating
         HHH(DD), which requires simulating DD() again… >>>>>>>>>>> recursive
         simulation.

         This creates an infinite regress — HHH cannot finish
         simulating DD()
         because to simulate it, it must simulate itself again,
         and again,
         and again…
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c >>>>>>>>>>>
         When HHH simulates DD, it must model DD's execution,
         including the call to HHH(DD) within DD. >>>>>>>>>>>          This introduces a recursive simulation: HHH simulating
         DD involves simulating DD's call to HHH(DD), which >>>>>>>>>>>          requires HHH to simulate DD again, and so on. >>>>>>>>>>> https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21- >>>>>>>>>> eedd0f09e141

The inner workings of HHH is of little consequence (so your call >>>>>>>>>> traces are just smoke and mirrors), what matters is what result >>>>>>>>>> HHH(DD) returns to DD(); if HHH(DD) doesn't return a result to >>>>>>>>>> DD()
then HHH is not a halt decider.

/Flibble

When HHH(DD) does return the result to its caller. it is never >>>>>>>>> reporting on the behavior of its caller.

That a halt decider is supposed to report on the behavior of its >>>>>>>>> caller has always been incorrect.

What is incorrect is your understanding of the Halting Problem and >>>>>>>> your so called "refutation" of extant Halting Problem proofs.

/Flibble

Although is may seem that my understanding is incorrect a deeper >>>>>>> understanding of the fundamental nature of Turing machines and
computable functions proves that it is incorrect to expect a TM to >>>>>>> report on the behavior of its caller.

HHH has to return a result to its caller or it isn't a halt decider. >>>>>> That's it. So what does HHH(DD) return to DD()?

/Flibble

When DD() is executed in main HHH(DD) reports that its own different >>>>> instance of DD cannot possibly reach its own final halt state.

No termination analyzer or halt decider ever reports on the behavior >>>>> of itself or it caller.
That would be like baking a cake in your washing machine.

You say HHH(DD) "reports": it reports what and to whom?

The directly executed HHH(DD) always reports to its caller yet never
reports on the behavior of this caller.

If it "reports"
non-halting to DD() then DD() will do the opposite and the extant
Halting Problem proofs are proven to be correct!

/Flibble

It does not matter to HHH(DD) what the Hell its caller does. The
behavior of its caller has never been any of the damn business of HHH.

In the diagonalization proofs HHH(DD) needs to report on a *description*
of its caller which is the ONLY business of HHH.

/Flibble

Yes and when HHH(DD) does report on the actual behavior
that its actual input actually specifies as measured by
DD correctly simulated by HHH that includes that HHH
does simulate an instance of itself simulating an instance
of DD that does call yet another instance of HHH(DD) then
HHH(DD)=0 is proven to be correct.

As usual incorrect claims without evidence.
HHH fails to reach the final halt state, that is in no way evidence that
there is non-termination behaviour.
The fact that HHH ignores the conditional branch instructions during the recursion, when we know that one cycle later another branch would be
followed, is a proof that HHH is incorrect.
HHH cannot prove that the other branch is never followed, because other simulations prove that the other branch *is* followed one cycle later.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 13 Aug 2025 15:39:56 -0500 schrieb olcott:

On 8/13/2025 3:28 PM, dbush wrote:

On 8/13/2025 3:39 PM, olcott wrote:

On 8/13/2025 2:32 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:27:48 -0500, olcott wrote:

On 8/13/2025 2:14 PM, Mr Flibble wrote:

On Wed, 13 Aug 2025 14:07:13 -0500, olcott wrote:

The DD stack cannot possibly unwind because there is nothing
driving the behavior of DD after HHH aborts its simulation of DD. >>>>>> False, main() is calling DD().

More precisely there is nothing driving the behavior of DD correctly >>>>> simulated by HHH after HHH quits simulating DD.
Also the directly executed DD (caller of HHH) has always been
invisible to this HHH, hence not in the scope of this HHH.

The directly executed DD doesn't have to be visible to HHH,
HHH just needs to be passed a *description* of DD

Yet I proved DD correctly simulated by HHH

Is not what anyone cares about.  We care about DD correctly simulated
by UTM.

If HHH was a UTM then HHH(DD) would never return.

Yes, but HHH is not an UTM. DD does not call an UTM. An UTM simulating
DD, which calls a partial simulator HHH, will halt, in line with
direct execution. You keep modifying what DD calls.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 13.aug.2025 om 23:03 schreef olcott:

On 8/13/2025 3:55 PM, Richard Heathfield wrote:

On 13/08/2025 21:02, olcott wrote:

On 8/13/2025 2:49 PM, Richard Heathfield wrote:

On 13/08/2025 19:27, olcott wrote:

<snip>

Although is may seem that my understanding is incorrect
a deeper understanding of the fundamental nature of Turing
machines and computable functions proves that it is
incorrect to expect a TM to report on the behavior of
its caller.

Trying hard not to laugh, let's pretend that we buy this "deeper
understanding" bollocks... but I don't think you've thought it through. >>>>
DD calls HHH, so your claim is tantamount to saying that it is
incorrect for DD to pass DD to HHH.

It is not passing a pointer to its executing process
table within the operating system it is passing a
pointer to a static finite string of its machine code.

Wrong. It's passing an int(*)(void).

That at the x86 level proves to be a pointer to
the static finite string of x86 machine code.

As usual an incorrect claim without evidence.

That is not a pointer to a finite string.
A finite string would need a beginning and an end, or size.

It is a pointer to the start of a function.
The behaviour of a function is not determined by the code of only that function, but it includes all other functions called by it directly or indirectly. All that information is available and belongs to the input, including the code to abort and halt.
If HHH does not use the full specification, that is a failure of HHH,
not something missing in the specification.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 13.aug.2025 om 20:01 schreef olcott:

On 8/13/2025 12:39 PM, Kaz Kylheku wrote:

On 2025-08-13, olcott <polcott333@gmail.com> wrote:

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?

The thing is that the procedure DD /integrates/ the deciding
function HHH.

If we have not yet committed to a behavior and return value for HHH(DD),
then it means we have not yet committed to the design of DD itself!

You have to commit to a definition of HHH.

I did in (a) and (b) above and three LLM systems were
able to figure out that the input to HHH(DD) does specify
the recursive simulation non-halting behavior pattern
on their own without prompting.

But HHH does not meet (a). It does not detect a non-termination pattern, because such a pattern is not present. It incorrectly assumes
non-termination without evidence. It ignores the conditional branch instructions that one cycle later would lead to a final halt state.
Therefore, your HHH is not a candidate for the HHH that is correct.
In fact, no such HHH exists, which makes the results of the AI a vacuous result.

If you then make a different definition, that is a new version of HHH.

You have to separate these; you can't refer to all of them as HHH.

As you try different ways of creating the halting decider, you
have have HHH1, HHH2, HHH3.

The author of DD studies each of these and replicates its logic,
embedding it into DD.

This activity gives rise to DD1, DD2, DD3, ...

DD1 proves that HH1 is not a universal halting decider.
DD2 proves that HH2 is not a universal halting decider.
DD3 proves that HH3 is not a universal halting decider.

And so on. For every halting decider design that you finalize and commit
to, a test case is easily produced which shows that it does not decide
the halting of all computations.

That creates a simple and convincing inductive argument that there
doesn't exist a univeral halting decider.

When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.

But it does not continue the recursion far enough to see that the
simulated HHH aborts and halts.

Three different LLM systems figured out that the execution
trace of DD correctly simulated by HHH does match the
*recursive simulation non-halting behavior pattern*
on their own without prompting that such a pattern even exists.

The simulation shows DD calling HHH(DD) repeatedly
   This creates an infinite recursive loop in the simulation
   No simulated execution path leads to DD's return statement
   being reached https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

   In other words, simulating DD() requires simulating
   HHH(DD), which requires simulating DD() again… recursive
   simulation.

   This creates an infinite regress — HHH cannot finish
   simulating DD() because to simulate it, it must simulate
   itself again, and again, and again… https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c

   When HHH simulates DD, it must model DD's execution,
   including the call to HHH(DD) within DD.
   This introduces a recursive simulation: HHH simulating
   DD involves simulating DD's call to HHH(DD), which
   requires HHH to simulate DD again, and so on. https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141

But since no such HHH exists, it is a vacuous result.

If I feed the AI with the premise that the moon is made of cheese, it
might acknowledge that there is more cheese on the moon than on earth,
but that will be a vacuous result.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-13 14:59:23 +0000, olcott said:

On 8/13/2025 3:31 AM, Mikko wrote:

On 2025-08-13 05:30:56 +0000, olcott said:

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?

A question is never self-evident. A claim can be self-evident
but the above is not a claim.

*You changed my words and then rebutted those changed words*

Not intentionally. What in the above quoted text is different
from the text you posted?

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 13 Aug 2025 14:07:13 -0500 schrieb olcott:

On 8/13/2025 1:20 PM, Richard Heathfield wrote:

On 13/08/2025 18:01, olcott wrote:

On 8/13/2025 10:54 AM, Richard Heathfield wrote:

What happens after HHH returns?

As can be seen below, olcott doesn’t even understand this question.

When one claims that an emulation is incorrect yet zero instructions
were emulated incorrectly then the claim is proved to be incorrect.

That also applies to simulating no instructions at all.

I am surprised to find that seeing this execution trace is too
difficult for everyone here:

Why should anyone even bother to look?

Because it proves that the counter-example input to the halting problem
is decidable when one uses a different criterion measure.

Ah, you’re not working on the HP.

You keep saying that, but you never stop to think what happens when HHH
/stops/ executing.

Nothing happens because all of the recursive simulations were entirely
driven by HHH simulating its own DD.

HHH also aborts itself?
No, it returns to DD.

Your trace fails to show the stack unwinding after HHH has reached its
decision, all simulation is concluded, and DD regains control at last.

Yes it does because the DD stack cannot possibly unwind when HHH aborts
its simulation of DD.

But HHH’s stack unwinds.

*The source has never mattered all that matters is this essence*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.

That pattern seems to be essential to me.

Conversely, if HHH instead returns 1 to reflect this, DD will instead
enter into its loop, again giving the lie to HHH's return code.

That is not the behavior of the input.

How do you know? You don't simulate that far.

Yet another person that believes a simulation of a non-terminating input
is only correct when it reaches its non-existent end.

I mean, yes, the only correct simulation of an infinite loop is infinite.

I also have the Linz Turing machine template yet because TM's are abstractions that cannot be easily made concrete they prevent false assumptions about their behavior from being directly detected.

How do they do that?

Because the one thing your HHH cannot tell you, no matter how perfectly
it simulates what it can reach, is what DD will do when it reclaims
control.

Irrelevant. What matters is what happens when HHH eventually unwinds
the stack and returns.

The DD stack cannot possibly unwind because there is nothing driving the behavior of DD after HHH aborts its simulation of DD.

Third strike. The *HHH* stack.

It doesn't matter. What happens when HHH returns?

int main() {
Output("Input_Halts = ", HHH(DD));
}

What happens when main() calls DD?

Just as you are assured that you are self-evidently correct, so I am
sure that you self-evidently are mistaken. The x86 language has
NOTHING to say on the correctness of your code;

It has everything to say about the correctness of DD emulated by HHH.

Then you can save yourself a lot of clocks with this hack

int HHH(ptr P)
{
  return 0;
}
If the question before us is whether HHH observes DD to halt, you can
save yourself 1300-odd lines of code.

HHH works correctly with an infinite set of inputs, Your suggestion
would break that.

Oh no, it returns („correctly” according to its own rules) that it
did not observe the input halting.

I am shocked that everyone here thinks that recursive emulation is
incomprehensibly more difficult to understand than ordinary recursion.

I am shocked that you think they don’t understand recursive simulation.

Unless there exists a specific x86 instruction that was found to not be emulated according to the semantics of the x86 language then the
emulation is necessarily correct.

All of those after the abort.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 11:01 PM, olcott wrote:

On 8/13/2025 9:46 PM, Richard Heathfield wrote:

On 14/08/2025 00:42, olcott wrote:

<snip>

The halting function is computable when one
does not require it to have psychic ability
to report on something that it cannot see.

There is *nothing* stopping you from showing HHH the whole of DD.

The whole of DD has different behavior when it
is an input to its own simulating halt decider.

Then you didn't give it the right input, and are just admitting that.

HHH(DD) does correctly report on the behavior
that it was provided.

Then the "DD" you gave wasn't the right input.

The proof program is supposed to ask the decider what the proof program
will do, if the input asks something else, you formed it wrong.

If y0u can't form the correct input, then you are just showing your
system isn't Turing Complete as you can do that in a Turing Complete System.

Thus, you are just showing that your whole "proof" is just one big fat lie.

All you have to do is pass it another parameter stating the filename
of the source code, thus removing the need to guess and eliminating
any requirement for psychic ability.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 11:12 PM, olcott wrote:

On 8/13/2025 9:57 PM, Richard Heathfield wrote:

On 14/08/2025 01:39, dbush wrote:

On 8/13/2025 8:26 PM, olcott wrote:

On 8/13/2025 7:19 PM, dbush wrote:

On 8/13/2025 7:58 PM, olcott wrote:

On 8/13/2025 6:43 PM, dbush wrote:

On 8/13/2025 7:42 PM, olcott wrote:

On 8/13/2025 6:38 PM, dbush wrote:

On 8/13/2025 7:03 PM, olcott wrote:

On 8/13/2025 5:43 PM, wij wrote:

On Wed, 2025-08-13 at 22:19 +0100, Richard Heathfield wrote: >>>>>>>>>>>> On 13/08/2025 22:13, dbush wrote:

<snip>

Let the record show that Peter Olcott has admitted that HHH >>>>>>>>>>>>> violates the semantics of the x86 language by aborting is >>>>>>>>>>>>> simulation, and that DD is therefore NOT correctly
simulated by HHH.

Let the record further show that this is self-evident from DD's >>>>>>>>>>>> source code.

Clearly, whatever HHH returns is wrong.

Within the assumption that HHH must have psychic
ability to report on behavior that it cannot see.

When we come back to reality then we see that Turing
machine deciders only report on EXACTLY (not approximately) >>>>>>>>>> what their finite string inputs tell them, exactly as
HHH reports that the actual behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES* is non halting.

In other words, the HHH you implemented is a partial halt
decider which computes *some* computable function which
overlaps with the halting function for some inputs and not for >>>>>>>>> others such as DD.

It does not compute the halting function because the halting >>>>>>>>> function is not computable, as Linz and others have proved and >>>>>>>>> as you have *explicitly* agreed is correct.

The halting function is computable when one
does not require it to have psychic ability
to report on something that it cannot see.

So again, you agree with Linz and Turning.

No one else in the world understood that there
never has been any actual input that does the
opposite of whatever its halt decider decides.

That's because what you're referring to as "halt decider" is
actually a partial halt decider, i.e. an actual Turing machine that
computes some computable function that overlaps with the halting
function for some inputs and not others.

The point is that no actual Turing machine can compute the halting
function.

No one notice that the halting problem is incorrect
for 89 years. It is wrong in the same way that the
math problem of computing the radius of a square
circle on the basis of the length of one of its equally
length four sides is wrong.

False.  The problem of computing the radius of a square circle
assumes such a thing exists.

Which it does.

No thing requiring simultaneous mutually exclusive
properties exists as anything but a misconception.

The halting problem proof also exists yet only as
a misconception.

It assumes a non-existent *INPUT* that does the
opposite of whatever its halt decider decides.

So, you think you can't write the program DD that you have shown you
have writen?

Or as you saying that program can't be represented as an input?

If that was true, UTMs couldn't exist, but Turing proved they did.

Maybe you need to find the error in that proof.

Sorry, all you are doing is showing you admitted ignorance of the topic.'

The fact you have admitted to having only learned what you think you
know from a zero-principle non-study of the field explains why you are
so ignorant about it, and that you don't care about the truth, but just
want to make up your pathetic pathological lies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 11:15 PM, olcott wrote:

On 8/13/2025 9:59 PM, dbush wrote:

On 8/13/2025 10:37 PM, olcott wrote:

On 8/13/2025 9:35 PM, Richard Heathfield wrote:

On 14/08/2025 00:03, olcott wrote:

Within the assumption that HHH must have psychic
ability to report on behavior that it cannot see.

Nobody expects that. What they do expect is for HHH to fail to do
its job correctly, because it Just Can't report on behaviour it
can't see, behaviour that it *needs* to know about in order to do
its job.

HHH(DD) does correctly report on the behavior
that it does see even if you don't want to
bother to prove to yourself that HHH does
emulate DD correctly.

Which means it fails to be a halt decider:

We are back to the square root of a dead chicken
not proving mathematical incompleteness.

Your reasoning says that it does prove incompleteness.

No, we are back to you not knowing what you are talking about.

You have ADMITTED you don't know much about computation theory, and thus
you have no right to say it is broken.

Sorry, all you are doing is showing that you IQ is the square root of a
dead chicken.

A "Halt Decider" is a well defined quantity. That you can represent
programs to another progran is a well established principle.

That you can't understand it doesn't make that untrue, it make you
ignorant.

For you to make claims out of the ignorance, make you just stupid and a
liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/14/25 12:30 AM, olcott wrote:

On 8/13/2025 10:33 PM, dbush wrote:

On 8/13/2025 11:15 PM, olcott wrote:

On 8/13/2025 9:59 PM, dbush wrote:

On 8/13/2025 10:37 PM, olcott wrote:

On 8/13/2025 9:35 PM, Richard Heathfield wrote:

On 14/08/2025 00:03, olcott wrote:

Within the assumption that HHH must have psychic
ability to report on behavior that it cannot see.

Nobody expects that. What they do expect is for HHH to fail to do
its job correctly, because it Just Can't report on behaviour it
can't see, behaviour that it *needs* to know about in order to do
its job.

HHH(DD) does correctly report on the behavior
that it does see even if you don't want to
bother to prove to yourself that HHH does
emulate DD correctly.

Which means it fails to be a halt decider:

We are back to the square root of a dead chicken
not proving mathematical incompleteness.

Repeat of previously refuted point:

On 5/5/2025 4:31 PM, dbush wrote:

Strawman.  The square root of a dead rabbit does not exist, but the
question of whether any arbitrary algorithm X with input Y halts when
executed directly has a correct answer in all cases.

Good point, yet an actual input that can do the opposite of
whatever its decider decides never existed, thus all the proofs
fall completely apart.

Sure it does, you are just showing you are too stupid to understand it.

That fact that your logic accepts lies and deceptions, and does require starting from truths just shows how stupid you are.

Meaning that the above is less than no response and that you therefore
agree that HHH fails to be a halt decider.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/25 11:13 PM, olcott wrote:

On 8/13/2025 9:58 PM, dbush wrote:

On 8/13/2025 10:32 PM, olcott wrote:

On 8/13/2025 9:28 PM, Richard Heathfield wrote:

On 13/08/2025 23:20, olcott wrote:

On 8/13/2025 4:13 PM, Richard Heathfield wrote:

On 13/08/2025 21:49, olcott wrote:

On 8/13/2025 3:25 PM, Richard Heathfield wrote:

<snip>

You assume the bug, if any, is in the code. It isn't. Well, it >>>>>>>> might be; I'd be very surprised if it were bug-free. But the
real bug is in the design. Hence (b) below.

<restoring for context>
(b) Even if you find it, it won't matter, for reasons I outlined
(again!) in my last reply.

You are the one trying to get away with saying
that DD is not correctly simulated by HHH.

By returning 0 as you say it should, HHH claims that DD never halts. >>>>>

No as I have told you 100 times HHH is not claiming
one damn thing about the behavior of its own caller.

Your weary tone is noted. I'm not surprised you're sick and tired of
telling me you haven't screwed up... but you have, all the same.

If HHH(DD) fails to report a value *to* DD *about* DD,

When HHH(DD) does return to directly executed DD()
it is not reporting on the behavior of its caller.

If it claims to meet the below requirements that's exactly what it's
doing:

So you don't understand that requiring the square root
of a dead chicken does not prove incompleteness?

And you are the only one that has brought up the case.

If H exist, we can make the D program,

And if H is a halt decider, we can make a representation of D to give it.

That H will have a specific answer it gives for that input.

The program D will either Halt or it won't, so the question does it halt
has an answer.

H is correct for this input if its answer match the behavior of the
program D.

Since they won't match for ANY program H that answers H(D), there can't
be a correct Halt Decider.

No Dead Chickens involved.

It seems, just dead Olcott brains.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 15:27, olcott wrote:

I dare you to find an actual input that does
the opposite of whatever its decider decides.

First catch your decider.

Once you have that, constructing its nemesis is a piece of cake.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 15:33, olcott wrote:

<snip>

If there is no actual *INPUT* that does the opposite
of what its decider decides then the proof that no
universal halt decider exists fails.

You're putting the cart before the horse.

If a universal halt decider can exist at all, it must by its very
universality be capable of existing independently of all
candidates for overturning it.

Such a candidate is constructed from the decider itself, as well
you know. You have lost on logic, so now you're trying to win by
a trick of language, but logic will always prevail over weasel words.

I am trying to get my words clear enough so that
I can get published. People here that help me with
that could get academic credit for refuting the
halting problem proof. From honorable mention up
to co-authorship.

I doubt whether anyone here would consent to having their names
so sullied.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, 14 Aug 2025 09:33:06 -0500 schrieb olcott:

I am trying to get my words clear enough so that I can get published.
People here that help me with that could get academic credit for
refuting the halting problem proof. From honorable mention up to co-authorship.

Pleaso do not add my name on anything you publish.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <107l0q2$csg3$8@dont-email.me>, joes <noreply@example.org> wrote: >Am Thu, 14 Aug 2025 09:33:06 -0500 schrieb olcott:

I am trying to get my words clear enough so that I can get published.
People here that help me with that could get academic credit for
refuting the halting problem proof. From honorable mention up to
co-authorship.

Pleaso do not add my name on anything you publish.

Indeed.

Though I confess that I allowed my baser instincts to override
my better judgement over the last couple of days with my
attempts to troll him, it is clear that that Peter Olcott is
obviously and self-evidently a crank.

What I do not understand is why people are actually trying to
seriously engage him over his ideas, that are also obviously
sheer nonsense. Why bother? He is not going to suddenly admit
that he is wrong. Engaging with him just encourages him.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 17:41, olcott wrote:

On 8/14/2025 9:55 AM, Richard Heathfield wrote:

On 14/08/2025 15:27, olcott wrote:

I dare you to find an actual input that does
the opposite of whatever its decider decides.

First catch your decider.

Once you have that, constructing its nemesis is a piece of cake.

Machine M contains simulating halt decider H

Let me know when you have a clean compile.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 17:58, olcott wrote:

On 8/14/2025 10:07 AM, Richard Heathfield wrote:

On 14/08/2025 15:33, olcott wrote:

<snip>

I am trying to get my words clear enough so that
I can get published. People here that help me with
that could get academic credit for refuting the
halting problem proof. From honorable mention up
to co-authorship.

I doubt whether anyone here would consent to having their names
so sullied.

I was offering that as a benefit

I can't think of anyone in this group who would consider it
anything but an embarrassment.

so that people
might leave rebuttal mode and instead focus on
an honest dialogue.

You're *getting* an honest dialogue. You're just too fixated to
recognise it.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-13, olcott <polcott333@gmail.com> wrote:

On 8/13/2025 12:39 PM, Kaz Kylheku wrote:

On 2025-08-13, olcott <polcott333@gmail.com> wrote:

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?

The thing is that the procedure DD /integrates/ the deciding
function HHH.

If we have not yet committed to a behavior and return value for HHH(DD),
then it means we have not yet committed to the design of DD itself!

You have to commit to a definition of HHH.

I did in (a) and (b) above and three LLM systems were
able to figure out that the input to HHH(DD) does specify
the recursive simulation non-halting behavior pattern
on their own without prompting.

If you then make a different definition, that is a new version of HHH.

You have to separate these; you can't refer to all of them as HHH.

As you try different ways of creating the halting decider, you
have have HHH1, HHH2, HHH3.

The author of DD studies each of these and replicates its logic,
embedding it into DD.

This activity gives rise to DD1, DD2, DD3, ...

DD1 proves that HH1 is not a universal halting decider.
DD2 proves that HH2 is not a universal halting decider.
DD3 proves that HH3 is not a universal halting decider.

And so on. For every halting decider design that you finalize and commit
to, a test case is easily produced which shows that it does not decide
the halting of all computations.

That creates a simple and convincing inductive argument that there
doesn't exist a univeral halting decider.

When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.

OK and so if, in that recursive tower of HHH invocations, if one of the
HHH suddenly behaves differently and breaks the pattern, that HHH is not
the same as the previous HHH.

That HHH and the previous HHH have the same external name in your UTM
system, but that doesn't make them the same.

We can only be sure that two procedures in a language like C are
functions if their only inputs are are their arguments and compile time constants, and if none of their inputs ever mutate in between or during invocations.

I.e. f(x) is not a function invocation if x is a pointer
to something that is changing, so that two calls f(x); f(x)
do not actually operate on the same input.

Turing machines are pure functions in that they depend only on their
tape. The tape processing mechanism is destructive, but nothing external meddles with the tape, each machine has its own tape not shared with
any other machines, and the tape is reset to its original content for
each simulation of the machine.

Invocations of prodcedures that are not pure functions are not
Turing computations. (I.e. are not instance of the material that the
Halting Theorem is about.)

Three different LLM systems figured out that the execution
trace of DD correctly simulated by HHH does match the
*recursive simulation non-halting behavior pattern*

We all agree that there is a recursive non-halting behavior pattern.

This creates an infinite regress — HHH cannot finish
simulating DD() because to simulate it, it must simulate
itself again, and again, and again…

Since DD calls HHH, if HHH doesn't finish, DD is non-terminating.
That's the correct answer. HHH not terminating means it doesn't
calculate the correct answer.

It's possible for HHH to terminate and return an answer to DD.
Because the call HHH is not in the tail position, DD has the
last word; it has more material to execute and it executes a
computation which contradicts the answer given by HHH.

Note that if DD does not terminate, there are only two ways
it can happen: either HHH didn't return to DD, or else
DD executed the deliberate infinite loop.

If the reason for DD's non-termination is that HHH didn't terminate,
then the independent call to HHH(DD) must also not terminate, otherwise something is wrong with HHH.

If some calls to HHH(DD) terminate and some do not, it means that HHH
isn't a Turing computation, because it isn't a function.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-13, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

The inner workings of HHH is of little consequence (so your call traces
are just smoke and mirrors), what matters is what result HHH(DD) returns
to DD(); if HHH(DD) doesn't return a result to DD() then HHH is not a halt decider.

The inner workings are of consequence. If different invocations (e.g. at different simulation levels) of the expression HHH(DD) return different results, or if some of them terminate and others do not, that means
that HHH(DD) is not a Turing computation.

The Halting Theorem says that no Turing computation can decide the
halting of all Turing computations.

If something is not a Turing computation, then it's outside of the
scope; it is not meaningful to consider it a halting decider in the
context of that result.

It is unsound reasoning to do so.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 14 Aug 2025 11:47:12 -0500, olcott wrote:

On 8/14/2025 10:13 AM, dbush wrote:

On 8/14/2025 11:01 AM, olcott wrote:

On 8/14/2025 5:09 AM, joes wrote:

Am Wed, 13 Aug 2025 14:07:13 -0500 schrieb olcott:

On 8/13/2025 1:20 PM, Richard Heathfield wrote:

On 13/08/2025 18:01, olcott wrote:

On 8/13/2025 10:54 AM, Richard Heathfield wrote:

What happens after HHH returns?

As can be seen below, olcott doesn’t even understand this question.

When one claims that an emulation is incorrect yet zero
instructions were emulated incorrectly then the claim is proved to >>>>>>> be incorrect.

That also applies to simulating no instructions at all.

I am surprised to find that seeing this execution trace is too
difficult for everyone here:

Why should anyone even bother to look?

Because it proves that the counter-example input to the halting
problem is decidable when one uses a different criterion measure.

Ah, you’re not working on the HP.

I am working on the HP exactly the same way that ZFC worked on
Russell's Paradox.

So you're creating a new theory of computation?  Then do so.  And
remember, you can't use *anything* from the old theory.

I am correcting an erroneous aspect of the theory of computation. All deciders must only compute the mapping from their finite string input. Anything that is not a finite string input is outside of the scope of
any decider.

A *description* of DD *is* a finite string, your HHH(DD) gets the answer
wrong when called from DD() thus confirming the extant Halting Problem
proofs are correct.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 18:53, olcott wrote:

<snip>

If even one person here bothered to pay a tiny
bit of attention they would see that I am correct.

But that's clearly not true. Quite a few people have devoted a
considerable amount of attention to you, and they have concluded
that you are incorrect.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2025 18:58, olcott wrote:

<snip>

Yes HHH is a halt decider having a domain limited to DD
thus its decider is exactly correct.

Then it's rather a shame that it gets the answer wrong.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-14, olcott <polcott333@gmail.com> wrote:

On 8/14/2025 12:26 PM, Kaz Kylheku wrote:

We all agree that there is a recursive non-halting behavior pattern.

*By "we all" you are only actually including yourself and myself*
Everyone else here has consistently denied or dodged that point
for the last three years. That is why I needed to pull in some
experts in C.

Are you sure? I mean if HHH uses a simulator to execute DD, which calls HHH(DD), of course there is runaway recursion and non-halting.

I am correcting an erroneous aspect of the theory
of computation.

You're not, though, because your demonstration/proof machinery doesn't
conform to the rigidly defined formalisms of that theory.

All deciders must only compute the
mapping from their finite string input. Anything that
is not a finite string input is outside of the scope
of any decider.

The directly executed DD() that calls HHH(DD)
*IS NOT A FINITE STRING INPUT TO HHH*

The name DD in your scenario, like any other name, must unambiguously
refer to a single entity.

If you find it necessary in your narrative to separately refer
to a "directly executed DD" and "simulated DD" because they have
different properties, you're doing something wrong.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)