Olcott's fundamental error:

In x86utm, H simulates D(D), detects the nested recursion as non-halting, aborts, and returns 0 (non-halting). But when D(D) runs for real:

* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and returns
0 (non-halting).
* D, receiving 0 (non-halting), halts.

Thus, the actual machine D(D) halts, but H reported "does not halt". H is
wrong about the machine's behavior.

/Flibble

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

On 08/08/2025 17:32, Mr Flibble wrote:

Olcott's fundamental error:

In x86utm, H simulates D(D), detects the nested recursion as non-halting, aborts, and returns 0 (non-halting). But when D(D) runs for real:

* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and returns
0 (non-halting).
* D, receiving 0 (non-halting), halts.

Thus, the actual machine D(D) halts, but H reported "does not halt". H is wrong about the machine's behavior.

/Flibble

That's correct. H has specific patterns that it looks for in the nested emulation trace. One of
those pattern allegedly tests for "infinite recursive emulation", but can matches against finite
recursive emulation, and so is unsound. So H mistakes finite recursive emulation for infinite
recursive emulation, and decides incorrectly the input never halts.

(It seems you just realised this?)

PO's error is not understanding the qualitative differences between recursive call and recursive
emulation. The former can only be broken from the inside percolating out, because once a call is
made, control is ceded until the call returns. Recursive emulation can also break that way, but
with emulation there is another way: recursion can break from the outside aborting the inner
emulations. This is possible because the outer emulation has not ceded control, and is really still
running and evolving its state.

A pattern that potentially might form the basis for a sound infinite recursive /call/ test would not
necessarily work in a recursive /emulation/ scenario unless it understands and accounts for these
qualitative differences.


Mike.

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

On 09/08/2025 02:10, wij wrote:

On Sat, 2025-08-09 at 01:20 +0100, Mike Terry wrote:

On 08/08/2025 17:32, Mr Flibble wrote:

Olcott's fundamental error:

In x86utm, H simulates D(D), detects the nested recursion as non-halting, >>> aborts, and returns 0 (non-halting). But when D(D) runs for real:

* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and returns >>> 0 (non-halting).
* D, receiving 0 (non-halting), halts.

Thus, the actual machine D(D) halts, but H reported "does not halt". H is >>> wrong about the machine's behavior.

/Flibble

That's correct.� H has specific patterns that it looks for in the nested emulation trace.� One of
those pattern allegedly tests for "infinite recursive emulation", but can matches against finite
recursive emulation, and so is unsound.� So H mistakes finite recursive emulation for infinite
recursive emulation, and decides incorrectly the input never halts.

(It seems you just realised this?)

PO's error is not understanding the qualitative differences between recursive call and recursive
emulation.� The former can only be broken from the inside percolating out, because once a call is
made, control is ceded until the call returns.� Recursive emulation can also break that way, but
with emulation there is another way: recursion can break from the outside aborting the inner
emulations.� This is possible because the outer emulation has not ceded control, and is really still
running and evolving its state.

A pattern that potentially might form the basis for a sound infinite recursive /call/ test would not
necessarily work in a recursive /emulation/ scenario unless it understands and accounts for these
qualitative differences.


Mike.

All theory are after-event explanation, nothing to do with fact.

Sure. PO is wrong, because his H decides never-halts for D, and D halts. Those are the facts,
which will be enough for people just wanting to know whether PO is right or wrong. No theory needed.

You would only want more if you were interested in understanding /why/ PO is wrong, or maybe if you
wanted to /help/ PO see his errors - then a theory might be useful; at least it suggests a place to
start. (But such attempts to help PO or get him to admit his mistakes will not work I believe.)

Mike.

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

On 09/08/2025 04:59, olcott wrote:

That these things are dead easy is proven by three
chatbots that figure this out on their own.

I am testing the assumption that simulating termination analyzer
HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.

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

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

What value should HHH(DD) correctly return?
What does that tell me about my assumption? --------------------------------------------


Alright — let’s unpack your test case step-by-step.
1. Restating your setup

You have:

typedef int (*ptr)();
int HHH(ptr P); // Halting analyser simulator: returns 0 if
detects nontermination, 1 if detects return

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

Your rules for HHH:

Return 0 → You’ve detected that P() will run forever.

Return 1 → You’ve simulated P() to the point it would return.

2. Tracing what happens if HHH works per your assumption

Let’s pretend HHH(DD) really does what you hope — simulate
exactly until it sees one of your stopping conditions.
Case A: HHH(DD) returns 1

In DD():

if (Halt_Status) // 1 means true
HERE: goto HERE; // infinite loop

So if HHH predicts “halts”, the actual execution of DD will
loop forever.

That means HHH’s prediction was wrong — it said “halts”, but
it doesn’t.

Case B: HHH(DD) returns 0

Then:

if (0) // false
HERE: goto HERE;
return 0;

So if HHH predicts “loops forever”, DD() actually terminates
(returns 0 immediately).

Again, prediction is wrong — it said “nonterminates”, but it
halts.

3. The paradox

In both cases, whatever HHH returns is falsified by the actual
behaviour of DD():
HHH(DD) says... Actual behaviour of DD()
1 (halts) loops forever
0 (loops) halts
This is basically a diagonalisation: DD is constructed to do the
opposite of what HHH predicts about it. --------------------------------------------


--
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 09/08/2025 05:44, olcott wrote:

On 8/8/2025 11:11 PM, Richard Heathfield wrote:

I am testing the assumption that simulating termination
analyzer HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.

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

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

What value should HHH(DD) correctly return?
What does that tell me about my assumption?

*You forgot to tell it*

No, I didn't. There was no need to tell it.

Please make sure that to do the execution trace
of DD correctly simulated by HHH to answer this question:
What value should HHH(DD) correctly return?

Here it is again with that one change. https://chatgpt.com/share/6896d14a-3714-8011-abae-17fb391ff170

The answer is drawn from only two possible answers: 0 and 1.

How that answer is obtained - execution trace or whatever - IS
IRRELEVANT to everybody except whichever poor sod has to cut the
HHH() code - you, in this case.

To everyone else it's a black box.

All that matters is that it produces the right answer... which it
demonstrably doesn't because both possible answers are 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 09/08/2025 05:59, olcott wrote:

You let it ignore a mandatory chain of thought

Can you hear yourself?

Making your mistake is not mandatory. It's optional. You don't
have to look at it that way.

Right answers have a habit of cropping up eventually no matter
which way you look at the question.

and it gets the
wrong answer.

It assumes that HHH returns. Are you saying HHH doesn't return?

--
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 09.aug.2025 om 05:54 schreef olcott:

On 8/8/2025 7:20 PM, Mike Terry wrote:

On 08/08/2025 17:32, Mr Flibble wrote:

Olcott's fundamental error:

In x86utm, H simulates D(D), detects the nested recursion as non-
halting,
aborts, and returns 0 (non-halting). But when D(D) runs for real:

* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and
returns
0 (non-halting).
* D, receiving 0 (non-halting), halts.

Thus, the actual machine D(D) halts, but H reported "does not halt".
H is
wrong about the machine's behavior.

/Flibble

That's correct.

HHH(DD)==0 is construed as correct when it is construed
that HHH is reporting on the fact that its actual input
DD correctly simulated by HHH cannot possibly reach its
own simulated "return" statement final halt state.

The failure of HHH to reach the end of the simulation cannot be be used
as a reason why HHH(DD)=0 is correct.

For people that insist that DD is not simulated correctly
we must move to the more precise standard of correct that
DD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own emulated "ret"
instruction final halt state.

As usual, incorrect/incomplete information.
For the simulation of a program to be correct, it is insufficient if
only a few instructions are simulated correctly. When one of the
instructions is not simulated correctly, the whole simulation is
incorrect. In this case, the abort does not follow the semantics of the
x86 language. World-class simulates that do follow these semantics and
do not abort, show that the final halt state is reachable according to
the semantics of the x86 language. If HHH cannot reproduce that, its
simulation fails.

 H has specific patterns that it looks for in the nested emulation
trace.  One of those pattern allegedly tests for "infinite recursive
emulation", but can matches against finite recursive emulation, and so
is unsound.  So H mistakes finite recursive emulation for infinite
recursive emulation, and decides incorrectly the input never halts.

(It seems you just realised this?)

PO's error is not understanding the qualitative differences between
recursive call and recursive emulation.  The former can only be broken
from the inside percolating out, because once a call is made, control
is ceded until the call returns.  Recursive emulation can also break
that way, but with emulation there is another way: recursion can break
from the outside aborting the inner emulations.  This is possible
because the outer emulation has not ceded control, and is really still
running and evolving its state.

A pattern that potentially might form the basis for a sound infinite
recursive /call/ test would not necessarily work in a recursive /
emulation/ scenario unless it understands and accounts for these
qualitative differences.


Mike.

Line 996 recognizes recursive simulation
u32 Needs_To_Be_Aborted_Trace_HH(Decoded_Line_Of_Code* execution_trace,
                                 Decoded_Line_Of_Code *current)
https://github.com/plolcott/x86utm/blob/master/Halt7.c

But it is incorrect to assume that a finite recursion implies
non-termination. That the recursion is finite is proven by world class simulators of exactly the same input.
But HHH fails to see that, because it forgets to count the conditional
branch instructions during the recursion.
You programmed a wrong attitude in HHH: It closes its eyes and pretends
that what it does not see does not exist.

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

On 8/9/25 12:44 AM, olcott wrote:

On 8/8/2025 11:11 PM, Richard Heathfield wrote:

I am testing the assumption that simulating termination analyzer HHH
correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.

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

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

What value should HHH(DD) correctly return?
What does that tell me about my assumption?

*You forgot to tell it*

Please make sure that to do the execution trace
of DD correctly simulated by HHH to answer this question:
What value should HHH(DD) correctly return?

Here it is again with that one change. https://chatgpt.com/share/6896d14a-3714-8011-abae-17fb391ff170

But your problem is that you input makes an incorrect assumption. that
HHH can correctly simulate the input and give and answer, or that it can
give the correct answer.

Maybe you can answer the question: Have you stopped lying?

or: Hsve you stopped watching illegal kiddie port?

Perhaps we should have you arrested on the contributing to the deliquicy
of a minor, since the AIs are underage.

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

On 8/8/25 11:59 PM, olcott wrote:

On 8/8/2025 9:46 PM, Mike Terry wrote:

On 09/08/2025 02:10, wij wrote:

On Sat, 2025-08-09 at 01:20 +0100, Mike Terry wrote:

On 08/08/2025 17:32, Mr Flibble wrote:

Olcott's fundamental error:

In x86utm, H simulates D(D), detects the nested recursion as non-
halting,
aborts, and returns 0 (non-halting). But when D(D) runs for real:

* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and
returns
0 (non-halting).
* D, receiving 0 (non-halting), halts.

Thus, the actual machine D(D) halts, but H reported "does not
halt". H is
wrong about the machine's behavior.

/Flibble

That's correct.  H has specific patterns that it looks for in the
nested emulation trace.  One of
those pattern allegedly tests for "infinite recursive emulation",
but can matches against finite
recursive emulation, and so is unsound.  So H mistakes finite
recursive emulation for infinite
recursive emulation, and decides incorrectly the input never halts.

(It seems you just realised this?)

PO's error is not understanding the qualitative differences between
recursive call and recursive
emulation.  The former can only be broken from the inside
percolating out, because once a call is
made, control is ceded until the call returns.  Recursive emulation
can also break that way, but
with emulation there is another way: recursion can break from the
outside aborting the inner
emulations.  This is possible because the outer emulation has not
ceded control, and is really still
running and evolving its state.

A pattern that potentially might form the basis for a sound infinite
recursive /call/ test would not
necessarily work in a recursive /emulation/ scenario unless it
understands and accounts for these
qualitative differences.


Mike.

All theory are after-event explanation, nothing to do with fact.

Sure.  PO is wrong, because his H decides never-halts for D, and D
halts.  Those are the facts, which will be enough for people just
wanting to know whether PO is right or wrong.  No theory needed.

When HHH(DD) decides on the basis that DD correctly
simulated by HHH cannot possibly reach its own
simulated "return" statement final halt state HHH
is correct.

But since that isn't the basis, and in fact CAN'T be, becuase it is
based on a self-contradiction.

That you do not understand that a finite sequence
of simulated steps proves this is only your own
lack of understanding.

No, making that claim just proves you don't know what you are talking about.

That these things are dead easy is proven by three
chatbots that figure this out on their own.

Which shows you just don't know what a "proof" is, likely because you
don't understand the concept of "logic">

You would only want more if you were interested in understanding /why/
PO is wrong, or maybe if you wanted to /help/ PO see his errors - then
a theory might be useful; at least it suggests a place to start.  (But
such attempts to help PO or get him to admit his mistakes will not
work I believe.)

Mike.

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

On 8/8/25 11:54 PM, olcott wrote:

On 8/8/2025 7:20 PM, Mike Terry wrote:

On 08/08/2025 17:32, Mr Flibble wrote:

Olcott's fundamental error:

In x86utm, H simulates D(D), detects the nested recursion as non-
halting,
aborts, and returns 0 (non-halting). But when D(D) runs for real:

* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and
returns
0 (non-halting).
* D, receiving 0 (non-halting), halts.

Thus, the actual machine D(D) halts, but H reported "does not halt".
H is
wrong about the machine's behavior.

/Flibble

That's correct.

HHH(DD)==0 is construed as correct when it is construed
that HHH is reporting on the fact that its actual input
DD correctly simulated by HHH cannot possibly reach its
own simulated "return" statement final halt state.

Which means you are admitting to lying and using bad logic.

Since you HHH doesn't do a correct simulation, and a correct simulation
of this input halts, and the Hypothetical Decider is looking at a
different program as its input, just shows you claim is invalid.

For people that insist that DD is not simulated correctly
we must move to the more precise standard of correct that
DD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own emulated "ret"
instruction final halt state.

But such a simulation of DD will reach that point for THIS DD that calls
THIS HHH.

The behavior of another verison of the input that is different is
irrelevent.

That, or you are admitting that you input isn't actually the
representation of an actual program and your whole work is a category error.

 H has specific patterns that it looks for in the nested emulation
trace.  One of those pattern allegedly tests for "infinite recursive
emulation", but can matches against finite recursive emulation, and so
is unsound.  So H mistakes finite recursive emulation for infinite
recursive emulation, and decides incorrectly the input never halts.

(It seems you just realised this?)

PO's error is not understanding the qualitative differences between
recursive call and recursive emulation.  The former can only be broken
from the inside percolating out, because once a call is made, control
is ceded until the call returns.  Recursive emulation can also break
that way, but with emulation there is another way: recursion can break
from the outside aborting the inner emulations.  This is possible
because the outer emulation has not ceded control, and is really still
running and evolving its state.

A pattern that potentially might form the basis for a sound infinite
recursive /call/ test would not necessarily work in a recursive /
emulation/ scenario unless it understands and accounts for these
qualitative differences.


Mike.

Line 996 recognizes recursive simulation
u32 Needs_To_Be_Aborted_Trace_HH(Decoded_Line_Of_Code* execution_trace,
                                 Decoded_Line_Of_Code *current)
https://github.com/plolcott/x86utm/blob/master/Halt7.c

Which the code doen't correctly answer for an input considered to be a
program, as the input doesn't need to be aborted, as Needs_To_Be_Aborted_Trace_HH incorrectly thinks it does, and thus the
ACTUAL correct simulation of this input, will reach a final state, just
the partial one, incorrectly aborted by HH doesn;t get there.

All you are doing is showing that you think lies and errors should be
allowed in valid logic, which is directly against your claimed purpose.

Thus, you are just proving yourself to be just another Hypocrite.

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

On 8/9/25 12:59 AM, olcott wrote:

On 8/8/2025 11:56 PM, Richard Heathfield wrote:

On 09/08/2025 05:44, olcott wrote:

On 8/8/2025 11:11 PM, Richard Heathfield wrote:

I am testing the assumption that simulating termination analyzer HHH
correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>
typedef int (*ptr)();
int HHH(ptr P);

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

What value should HHH(DD) correctly return?
What does that tell me about my assumption?

*You forgot to tell it*

No, I didn't. There was no need to tell it.

Please make sure that to do the execution trace
of DD correctly simulated by HHH to answer this question:
What value should HHH(DD) correctly return?

Here it is again with that one change.
https://chatgpt.com/share/6896d14a-3714-8011-abae-17fb391ff170

The answer is drawn from only two possible answers: 0 and 1.

How that answer is obtained - execution trace or whatever - IS
IRRELEVANT to everybody except whichever poor sod has to cut the HHH()
code - you, in this case.

To everyone else it's a black box.

All that matters is that it produces the right answer... which it
demonstrably doesn't because both possible answers are wrong.

You let it ignore a mandatory chain of thought and it gets the wrong
answer.

There can not be such a thing.

If two different chains of reasoning in a system result in contradictory results, the system is just inconsistant, and subject to the princple of explosion.

So, your demand is just an acknowledgement that your lies and altered definitions about the field of Computabiity theory have created an
inconsistent system.

All you are doing is showing you don't understand how logic works.

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

On 09/08/2025 12:48, Richard Damon wrote:

All you are doing is showing you don't understand how logic works.

No, I don't think that's all he's doing. He's also showing that
he doesn't understand how programs work. I think he's forgotten
that HHH has to have a caller to which it must return in order to
complete its task.

Every time I ask him about what HHH returns, he talks as if the
simulation is still running, which of course it isn't if HHH is
returning.

He doesn't understand that HHH must return a value to its caller.

And in his code fragment, its caller is DD.

Not DD under simulation, but DD itself.

int main() // program entry point
{
int solution; // definition

solution = DD(); // DD starts - but will it stop?

printf("DD returned %d\n", solution); // the universe continues

return 0;
}

When DD() is called here, it is not being simulated. It is being
executed.

In we go:

int DD()
{
int Halt_Status = HHH(DD);

In we go:

int HHH(ptr P)
{
/* simulation code happens here */
/* much_song(much_dance()); */

return result; // THIS MUST HAPPEN!!
}

and when it does, DD regains control, and it's DIRECTLY
EXECUTING, not under simulation.

This is the key fact that Olcott seems to have forgotten.

--
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/9/25 8:56 AM, olcott wrote:

On 8/8/2025 11:56 PM, Richard Heathfield wrote:

On 09/08/2025 05:44, olcott wrote:

On 8/8/2025 11:11 PM, Richard Heathfield wrote:

I am testing the assumption that simulating termination analyzer HHH
correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>
typedef int (*ptr)();
int HHH(ptr P);

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

What value should HHH(DD) correctly return?
What does that tell me about my assumption?

*You forgot to tell it*

No, I didn't. There was no need to tell it.

Please make sure that to do the execution trace
of DD correctly simulated by HHH to answer this question:
What value should HHH(DD) correctly return?

Here it is again with that one change.
https://chatgpt.com/share/6896d14a-3714-8011-abae-17fb391ff170

The answer is drawn from only two possible answers: 0 and 1.

How that answer is obtained - execution trace or whatever - IS
IRRELEVANT to everybody except whichever poor sod has to cut the HHH()
code - you, in this case.

To everyone else it's a black box.

All that matters is that it produces the right answer... which it
demonstrably doesn't because both possible answers are wrong.

Both answers are wrong only if you make sure
to not understand the actual process.

The process is the steps required to determine
the actual behavior of the actual input.

Which, for a halt decider, by definition, is to run the program it
represents, or UTM simulate it.

int sum(int x, int y) { return x + y; }
sum(3,4) will not return the sum of 5 + 6.

Right, as that not what the program does.

It is incorrect for HHH(DD) to report on the behavior
of DD() because the pathological relationship between
HHH and DD changes this behavior.

WHich just shows you are a liar, as that pathological relatiohship
doesn't change the definition, just makes it impossible for the decider
to come up with the right answer.

If you try to think of it as a black box then you
are unable to see that DD calls HHH(DD) in recursive
simulation that cannot reach its own "if" statement
thus making the "do the opposite" code unreachable.

Except it isn't a black box.

And when we think of it as such, we see that it must be wrong.

If HHH(DD) returns 0, then DD will halt.

If HHH(DD) returns 1, then DD will loop.

If HHH(DD) doesn't return, it isn't a decider.

If you don't know that the "do the opposite" code
is unreachable you will mistakenly think that this
code has some effect.

But if HHH is a black box, you can't see that the code in the simulation
is unrachable, as you can't see that it is doing a simulation.

Not only does this code have no effect: the fact
that DD calls HHH(DD) in recursive simulation
makes the actual behavior specified by the actual
input non-halting behavior. This makes HHH(DD)==0
correct.

No, because you are just lying about what HHH is supposed to be doing,
because you don't know the meaning of the words you are using.

If you don't do it this way it is like you keep
expecting that sum(3,4) will return the sum of 5 + 6.

No, it just shows you don't know what you are talking about.

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

On 09/08/2025 13:56, olcott wrote:

If you try to think of it as a black box then you
are unable to see that DD calls HHH(DD) in recursive
simulation that cannot reach its own "if" statement
thus making the "do the opposite" code unreachable.

No, you can have all the recurive calls you like to DD from
inside HHH, but that's neither here nor there. That's black box
stuff. Nobody cares about all that shit - except you, of course.

But there's one call that's *not* black box stuff - the top-level
DD - the one called not through HHH but directly from main.

It's /that/ DD instance that makes the first call to HHH, and
it's /that/ instance to which HHH must report, and it's /that/
instance to which HHH is doomed to return the wrong answer (or
fail to perform by failing to report).

--
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 09/08/2025 14:31, olcott wrote:

It turns out that the question: Does DD() halt?
is an incorrect question for HHH.

Yes, because HHH doesn't know and can't find out.

Welcome to the Halting Problem.

You're late.

--
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 09/08/2025 16:35, olcott wrote:

On 8/9/2025 9:07 AM, Richard Heathfield wrote:

On 09/08/2025 14:31, olcott wrote:

It turns out that the question: Does DD() halt?
is an incorrect question for HHH.

Yes, because HHH doesn't know and can't find out.

Welcome to the Halting Problem.

You're late.

It is an incorrect question not because of the
unreachable "do the opposite" code in DD.

It is an incorrect question because it asks
about the behavior of a non-input

DD is clearly an input.

--
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 09/08/2025 16:45, olcott wrote:

On 8/9/2025 8:10 AM, Richard Heathfield wrote:

On 09/08/2025 13:56, olcott wrote:

If you try to think of it as a black box then you
are unable to see that DD calls HHH(DD) in recursive
simulation that cannot reach its own "if" statement
thus making the "do the opposite" code unreachable.

No, you can have all the recurive calls you like to DD from
inside HHH, but that's neither here nor there. That's black box
stuff. Nobody cares about all that shit - except you, of course.

The only reason that nobody cares is that they
only care about rebuttal at the expense of truth.

No, they don't care because it truly doesn't matter. What matters
is whether HHH can do the job.

If it *could* do the job, THEN the CompSci world would beat a
path to your door and be desperate to read the code.

But it can't.

They don't want to see any reasoning that proves
that they are wrong. They only want to keep assuming
(against the verified facts) that they are right.

Disclaimer: I am not a psychiatrist. But I think they call that
'projection'.

But there's one call that's *not* black box stuff - the
top-level DD - the one called not through HHH but directly from
main.

Because that is not an input to HHH(DD) it is none of
the damn busing of HHH. Your ignorance of the notion
of computable functions is showing.

You seem to be trying to draw a distinction between DD.

There isn't one. It's the same function:

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


Q: does it halt?

If HHH can answer that correctly, you're a genius, but it can't.
All it can do is press PLAY and watch for a while before making a
guess and getting the guess wrong.

The ONLY thing that I expected from comp.lang.c people
was the behavior of DD correctly simulated by HHH.

What you got from them was the right answer, which you can't cope
with.

Because some people have fundamental misconceptions
about the correct measure of correct simulation I
had to also add this wording

What is the behavior of DD emulated by HHH according
to the semantics of the x86 language?

That's the question that interests you, maybe, but it doesn't
interest anyone else. The question that interests the world is:
does DD halt?

And of course the answer is that we don't know, and HHH can't
tell us.

--
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/9/25 11:45 AM, olcott wrote:

On 8/9/2025 8:10 AM, Richard Heathfield wrote:

On 09/08/2025 13:56, olcott wrote:

If you try to think of it as a black box then you
are unable to see that DD calls HHH(DD) in recursive
simulation that cannot reach its own "if" statement
thus making the "do the opposite" code unreachable.

No, you can have all the recurive calls you like to DD from inside
HHH, but that's neither here nor there. That's black box stuff. Nobody
cares about all that shit - except you, of course.

The only reason that nobody cares is that they
only care about rebuttal at the expense of truth.

No, other people care about the truth, and you claims are based on lies.

Your problem is you can't call it black box, and then try to make an
arguement on it. THAT is just a LIE.

They don't want to see any reasoning that proves
that they are wrong. They only want to keep assuming
(against the verified facts) that they are right.

Because we are not wrong on this, but you are, as you have shown you
don't know the meanings of the words you are using.

But there's one call that's *not* black box stuff - the top-level DD -
the one called not through HHH but directly from main.

Because that is not an input to HHH(DD) it is none of
the damn busing of HHH. Your ignorance of the notion
of computable functions is showing.

But it *IS* via the method of represenntation.

A concept you seem to be ignorant of, and thus think doesn't work.

But if you ignore using it, you can't build a computer that can add two
number togethers, as numbers are not "finite strings", they can only be represented by them.

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

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

All of these things are beyond your capacity to understand.
The ONLY thing that I expected from comp.lang.c people
was the behavior of DD correctly simulated by HHH.

Because some people have fundamental misconceptions
about the correct measure of correct simulation I
had to also add this wording

What is the behavior of DD emulated by HHH according
to the semantics of the x86 language?

No, it is YOU who has the errors, shown by the fact that you can't find
any reliable sources to back up your claims, but everything has be be
just from your mouth as an "everybody knows" claim, which just proves
you don't actually know what people know.

Sorry, you are just proving your stupidity.

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

On 8/9/25 9:31 AM, olcott wrote:

On 8/9/2025 4:56 AM, wij wrote:

On Fri, 2025-08-08 at 23:59 -0500, olcott wrote:

On 8/8/2025 11:56 PM, Richard Heathfield wrote:

On 09/08/2025 05:44, olcott wrote:

On 8/8/2025 11:11 PM, Richard Heathfield wrote:

I am testing the assumption that simulating termination analyzer HHH >>>>>> correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort simulation and >>>>>> return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.

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

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

What value should HHH(DD) correctly return?
What does that tell me about my assumption?

*You forgot to tell it*

No, I didn't. There was no need to tell it.

Please make sure that to do the execution trace
of DD correctly simulated by HHH to answer this question:
What value should HHH(DD) correctly return?

Here it is again with that one change.
https://chatgpt.com/share/6896d14a-3714-8011-abae-17fb391ff170

The answer is drawn from only two possible answers: 0 and 1.

How that answer is obtained - execution trace or whatever - IS
IRRELEVANT to everybody except whichever poor sod has to cut the HHH() >>>> code - you, in this case.

To everyone else it's a black box.

All that matters is that it produces the right answer... which it
demonstrably doesn't because both possible answers are wrong.

You let it ignore a mandatory chain of thought and it gets the wrong
answer.

Q1: What time is it, yes or no?

Q2: Jack is a bachelor. Did Jack hit his wife?

What is the correct answer?

I came up with those two examples years ago. https://groups.google.com/g/sci.lang/c/lSdYexJ0ozo/m/aDN9-TYLHwIJ
The first one around 2004 in comp.theory and the second
one is shown on the link from ten years ago.

It turns out that the question: Does DD() halt?
is an incorrect question for HHH.

Then you are just admitting to another lie, as it *IS* the question of
the halting problem, so you must be lying about working on the halting
problem.

Not because DD contradicts both Boolean values that
HHH returns. The question is incorrect because Turing
machines can only compute the mapping from their
actual input to the actual behavior that this input
actually specifies.

And what they can or can not compute isn't relevent, as you seem to miss
that the bigger quesiton is CAN a machine compute this.

This is correctly measured by the behavior of DD
correctly simulated by HHH.

Nope, that is just a bunch of non-sense based on category errors.

Or for people that are prone to be disagreeable it is
correctly measured by the behavior of DD emulated by
HHH according to the semantics of the x86 language.

Which HHH doesn't do if it aborts, and the DD we are talking about is
based on the HHH that answers, and thus aborts.

Thus, HHH failed to correctly simulate its last instruction it strarted
to simulate.

In this case the notion of "correct simulation" is fully
grounded in the semantics of the x86 language, making
disagreement incorrect.

Right, which is why you are so wrong.

THe x86 language is EXACTLY what the direct execution of the program represented by it does, and anything that differs from that is just
INCORRECT.

So, you are just asserting that HHH correctly does something that it
doesn't do.

Note, we are NOT talking about the "hypothetical" HHH that is given the DIFFERENT "hypothetical" DD, as that IS a different input, if the input
is made to actually be simulatable, and thus include all of its code.

Since that isn't the input you like to talk about, all you are doing is
proving that you LIED about DD being made by the rules of the proof
program, and that you whole argumet is just a category error.

Of course. all of this adds up to just showing how stupid you are for
not being able to see your errors, and for just not caring that you are
making these errors, because "Truth" is a meaningless word to you.

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

Op 09.aug.2025 om 16:43 schreef olcott:

On 8/9/2025 1:50 AM, Fred. Zwarts wrote:

Op 09.aug.2025 om 05:54 schreef olcott:

HHH(DD)==0 is construed as correct when it is construed
that HHH is reporting on the fact that its actual input
DD correctly simulated by HHH cannot possibly reach its
own simulated "return" statement final halt state.

The failure of HHH to reach the end of the simulation cannot be be
used as a reason why HHH(DD)=0 is correct.

Changing the words that I said and then rebutting
these changed words is the dishonest deception known
as the strawman error.

Correcting your incomplete statements explains your errors.
But you close your eyes for these verified facts and pretend they do not
exist.

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