You said they be identical. If they are not equivlaent they can't
be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
On 11/1/2025 5:59 PM, Kaz Kylheku wrote:
On 2025-11-01, Tristan Wibberley <[email protected]> wrote:
On 01/11/2025 22:19, Kaz Kylheku wrote:
To trace D, we need a definition of H.
The situation statement is a constraint on H, it almost defines a puzzle >>> which may have solutions in H. Given the phrasing and the newsgroup I
think that's what Olcott was going for.
That is /you/ the /puzzled/ provides the H!
Coming up with the tracing H which aborts its simulation is
Olcott's job.
He did that with the "x86utm", and that has been shot down.
It has not been shot down.
On 01/11/2025 02:32, Richard Damon wrote:
On 10/31/25 3:57 PM, Tristan Wibberley wrote:
On 31/10/2025 18:06, Richard Damon wrote:
[H and H1] fail to be correct C
interpreters, as the code has a required diagnostic.
Really? even in K&R C?
Yep, the link step will fail as H and H1 are not defined.
Is "link step" defined in K&R C?
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the situation/.
On 2025-11-01 16:36, Tristan Wibberley wrote:
On 01/11/2025 02:32, Richard Damon wrote:
On 10/31/25 3:57 PM, Tristan Wibberley wrote:
On 31/10/2025 18:06, Richard Damon wrote:
[H and H1] fail to be correct C
interpreters, as the code has a required diagnostic.
Really? even in K&R C?
Yep, the link step will fail as H and H1 are not defined.
Is "link step" defined in K&R C?
Not in the first edition. Section 11.2 mentions that a program can be
made up of many files, and that declarations with external linkage can
refer to something defined in a different file, but that's about all
they say about it.
When the language was standardized, a lot more thought was put into it.
In C89, Section 2.1.1.2 describes the phases of translation of a
program, and phase 8 is described the link step (though it does not name
it as such): "All external object and function references are resolved. Library components are linked to satisfy external references to
functions and objects not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment."
In the second edition, K&R was brought into line with the latest draft version of what would become C89. As a result, A.12 contains the
following simplified version of that specification: "The result is translated, then linked together with other programs and libraries, by collecting the necessary programs and data, and connecting external
functions and object references to their definitions."
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the
situation/.
C89 3.7 says "... If an identifier declared with external linkage is
used in an expression (other than as part of the operand of a sizeof operator), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no
more than one."
Violation of a "shall" that occurs outside of a constraints section
means that the behavior is undefined, which in turn means that the C
standard imposes no requirements on the behavior of such a program. No diagnostic is required, nor is the translation required to fail, so
Richard is wrong on those points.
Because the behavior is undefined, anything is permitted, including
providing a definition of H when the program itself contains none - but
it most certainly isn't required to do so, and I doubt that any normal C compiler would do so.
I try my best to avoid olcott messages. Does he specify that his
nonsense requires an implementation that takes advantage of undefined behavior in that fashion?
On 01/11/2025 02:32, Richard Damon wrote:
On 10/31/25 3:57 PM, Tristan Wibberley wrote:
On 31/10/2025 18:06, Richard Damon wrote:
[H and H1] fail to be correct C
interpreters, as the code has a required diagnostic.
Really? even in K&R C?
Yep, the link step will fail as H and H1 are not defined.
Is "link step" defined in K&R C?
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the situation/.
Olcott: it might help to say, instead of that H and H1 are anchored in
the interpreter, that the interpreter defines the symbol "H", if that is
what you mean for your situation (I think it is but also my C
terminology is rusty). I expect Kaz will know, he's a real dab-hand.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 11/2/2025 6:17 AM, Mikko wrote:
On 2025-11-01 13:25:41 +0000, olcott said:
On 11/1/2025 3:42 AM, Mikko wrote:
On 2025-10-31 12:44:17 +0000, olcott said:
On 10/31/2025 6:28 AM, Mikko wrote:
On 2025-10-30 14:49:08 +0000, olcott said:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
Being identical means that H and H1 compute the same semantic
property.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
It turns out that my big discovery the overturns
part of the foundation of computer science is that
the semantic property can be relative to the decider.
It actually always relative to the decider yet this
has never made any difference with non-self-referential
inputs. H(D) != UTM(D) == H1(D)
The halting problem has always been an issue where
the halt decider has never been smart enough to
figure out halting for self-contradictory inputs.
That never has been the real issue.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
With a simulating halt decider D simulated by
H never reaches the contradictory part. It
stays stuck on its first line.
H and D do get stuck in recursive simulation. H
can and does see this. H does abort its own simulation
of D to prevent its own non-termination.
The real issue (that could not be seen until I created
the notion of a simulating halt decider in 2016) is
that the halting problem requires H to report on
behavior other than the behavior that its actual input
actually specifies.
int sum(int x, int y){ return x + y; }
this is the same as requiring sum(3,4) to report on
the sum of 5 + 6.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
As H and H1 return different values for the same input they are
found to be non-identical, contrary to the initial claim.
The above confirms that H and H1 give different results for the same
input. By the meanngs of the words H and H1 are not equivalent.
I never claimed that the were equivalent.
You said they be identical. If they are not equivlaent they can't
be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
Am Thu, 30 Oct 2025 08:08:12 -0500 schrieb olcott:
On 10/30/2025 5:10 AM, Mikko wrote:
On 2025-10-29 16:41:32 +0000, olcott said:
On 10/29/2025 5:35 AM, Mikko wrote:
To determine that DD halts is not merely possible but easy. Just
simulate it until it halts (which doesn't take a long time) and there >>>>> it is. The same with any other camputaion that halts, though the time >>>>> to find out may be longer.
D simulated by H according to the semantics of the C programmingH simulates D that calls H(D) to simulate D that calls H(D) to
simulate D that calls H(D) to simulate D that calls H(D) to simulate D >>>> that calls H(D) to simulate D until H sees this repeating pattern.
And what happens if it sees?
language until H correctly determines that its simulated D cannot
possibly reach its own simulated "return" statement correctly rejects D
on this basis not some other basis.
Make sure that you see the word "until"
Yes, and then what?
Identical codes mean the same and specify identical behaviours.
On 2025-11-01 16:36, Tristan Wibberley wrote:
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the
situation/.
C89 3.7 says "... If an identifier declared with external linkage is
used in an expression (other than as part of the operand of a sizeof operator), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no
more than one."
On 03/11/2025 01:49, James Kuyper wrote:
On 2025-11-01 16:36, Tristan Wibberley wrote:
The compiler can provide definitions for H--which is the only symbol
missing a definition in the situation statement, IIRC--/to satisfy the
situation/.
C89 3.7 says "... If an identifier declared with external linkage is
used in an expression (other than as part of the operand of a sizeof
operator), somewhere in the entire program there shall be exactly one
external definition for the identifier; otherwise, there shall be no
more than one."
I think the interpretation of K&R original is that no prototype is as if
the function were declared with external linkage so the above allows
defined behaviour when one provides the solution to the situation.
The C implementation sources other translation units to close the
definition of the entire program even if the translation unit is
included within the implementation's program text.
I'm not sure the solutions to Olcott's situation statement necessarily
have undefined behaviour following the concerns raised.
I can see that the situation statement has not defined the external definition of H, it has only constrained it but also he is not issuing anything as input to a C compiler, but as input to usenet which may
provide the defining text for the external definition of H to be
included in the C interpreter as part of a solution to the puzzle. The C interpreter may use it as part of the program.
It's a difficult challenge and I think we've only scratched the surface
of its solution.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 03/11/2025 10:05, Mikko wrote:
Identical codes mean the same and specify identical behaviours.
... with respect to closure.
----
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 2025-11-02, olcott <[email protected]> wrote:
You said they be identical. If they are not equivlaent they can't
be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
Can you show that concretely with C?
On 2025-11-02, Kaz Kylheku <[email protected]> wrote:
On 2025-11-02, olcott <[email protected]> wrote:
You said they be identical. If they are not equivlaent they can't
be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
Can you show that concretely with C?
Didn't think so.
Tristan Wibberley <[email protected]> wrote:
On 03/11/2025 10:05, Mikko wrote:
Identical codes mean the same and specify identical behaviours.
... with respect to closure.
You've used the word "closure" quite a number of times. What do you
mean by it? It's beyond my powers of guessing from context.
Tristan Wibberley <[email protected]> wrote:
On 03/11/2025 10:05, Mikko wrote:
Identical codes mean the same and specify identical behaviours.
... with respect to closure.
You've used the word "closure" quite a number of times. What do you
mean by it? It's beyond my powers of guessing from context.
On 03/11/2025 20:19, Alan Mackenzie wrote:
Tristan Wibberley <[email protected]> wrote:
On 03/11/2025 10:05, Mikko wrote:
Identical codes mean the same and specify identical behaviours.
... with respect to closure.
You've used the word "closure" quite a number of times. What do you
mean by it? It's beyond my powers of guessing from context.
Well, we can see it from a couple of perspectives and find the same
result so I'll avoid the hours of checking what I say and be a bit loose.
A program (or subprogram) that doesn't define everything itself refers
to a definition provided elsewhere. In essence, the provision of the
missing piece is closing with a closure. Some of them are lexical, some dynamic, I'm sure there are other kinds. Personally I also don't see I/O
as being an awful lot different but I don't know what meaning is
assigned conventionally everywhere.
I feel even procedure arguments can be seen as a closure though we tend
not to talk about them like that in programming as seen conteporarily.
In formal systems the concept of closure appears when defining its
objects and it seems to me to be highly related. The meaning of an
operation that constructs an object is progressively completed by
applying its arguments until the consequence of the operation is fully specified whereupon it is closed and the arguments were its closure.
To go further into how it applies here and where it might but isn't
relevant is a whole essay with lots of care needed, so I won't. I don't
say this to sound all secretly knowledgable because I'm not, but I mean
to point to what I think is the relevant concept for understanding
Olcott's situation statement without saying anything egregiously wrong
and without taking forever.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 03/11/2025 20:19, Alan Mackenzie wrote:
Tristan Wibberley <[email protected]> wrote:
On 03/11/2025 10:05, Mikko wrote:
Identical codes mean the same and specify identical behaviours.
... with respect to closure.
You've used the word "closure" quite a number of times. What do you
mean by it? It's beyond my powers of guessing from context.
Well, we can see it from a couple of perspectives and find the same
result so I'll avoid the hours of checking what I say and be a bit loose.
A program (or subprogram) that doesn't define everything itself refers
to a definition provided elsewhere. In essence, the provision of the
missing piece is closing with a closure. Some of them are lexical, some dynamic, I'm sure there are other kinds. Personally I also don't see I/O
as being an awful lot different but I don't know what meaning is
assigned conventionally everywhere.
I feel even procedure arguments can be seen as a closure though we tend
not to talk about them like that in programming as seen conteporarily.
In formal systems the concept of closure appears when defining its
objects and it seems to me to be highly related. The meaning of an
operation that constructs an object is progressively completed by
applying its arguments until the consequence of the operation is fully specified whereupon it is closed and the arguments were its closure.
On 11/3/2025 2:43 PM, Kaz Kylheku wrote:
On 2025-11-02, Kaz Kylheku <[email protected]> wrote:
On 2025-11-02, olcott <[email protected]> wrote:
You said they be identical. If they are not equivlaent they can't
be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
Can you show that concretely with C?
Didn't think so.
I have done that hundreds of times and you just ignore it.
On 2025-11-03, olcott <[email protected]> wrote:
On 11/3/2025 2:43 PM, Kaz Kylheku wrote:
On 2025-11-02, Kaz Kylheku <[email protected]> wrote:
On 2025-11-02, olcott <[email protected]> wrote:
You said they be identical. If they are not equivlaent they can't
be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
Can you show that concretely with C?
Didn't think so.
I have done that hundreds of times and you just ignore it.
What? Where? All you ever post these days is useless talk.
Where is the URL to a project with .c files and a Makefile, etc?
I can write a C interpreter which can interpret itself.
On 11/3/2025 4:40 PM, Kaz Kylheku wrote:
On 2025-11-03, olcott <[email protected]> wrote:
On 11/3/2025 2:43 PM, Kaz Kylheku wrote:
On 2025-11-02, Kaz Kylheku <[email protected]> wrote:
On 2025-11-02, olcott <[email protected]> wrote:
You said they be identical. If they are not equivlaent they can't >>>>>>> be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
Can you show that concretely with C?
Didn't think so.
I have done that hundreds of times and you just ignore it.
What? Where? All you ever post these days is useless talk.
Where is the URL to a project with .c files and a Makefile, etc?
Are you saying that you are smart enough to do this:
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
Yet not smart enough to do a simple execution trace in your head?
On 2025-11-03, olcott <[email protected]> wrote:
On 11/3/2025 4:40 PM, Kaz Kylheku wrote:
On 2025-11-03, olcott <[email protected]> wrote:
On 11/3/2025 2:43 PM, Kaz Kylheku wrote:
On 2025-11-02, Kaz Kylheku <[email protected]> wrote:
On 2025-11-02, olcott <[email protected]> wrote:
You said they be identical. If they are not equivlaent they can't >>>>>>>> be identical.
Identical code and different behavior
because D calls H in recursive simulation
and D does not call H1 in recursive simulation.
Can you show that concretely with C?
Didn't think so.
I have done that hundreds of times and you just ignore it.
What? Where? All you ever post these days is useless talk.
Where is the URL to a project with .c files and a Makefile, etc?
Are you saying that you are smart enough to do this:
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
Yet not smart enough to do a simple execution trace in your head?
Bleeping idiot, of course it was the "execution trace in my head"
which led me to the realization that abandoned simulations of D have
a continuable future which leads to termination.
What step(s) of D come next in C?
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C syntax several days ago,
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C
syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C
syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3 0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
The D simulation is not "totally killed"; it (the #<interp0> object) continues to exist.
The interpreter machine can identify it and continue to step it: to do
the reckoning.
Level Step Code Vars
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
1 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 0
1 5 if (interp_step(s)) ... P = D; s = #<interp1>; i = 0
2 1 if (H(D)) ...
1 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 1
1 7 if (interp_step(s)) ... P = D; s = #<interp1>; i = 0
2 2 H(D)
1 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 2
1 7 if (interp_step(s)) ... P = D; s = #<interp1>; i = 0
2 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
1 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp1>; i = 3
1 9 return false; P = D; s = #<interp1>; i = 3
1 10 if (#<false>) { for(;;); }
1 11 return;
At simulation level 1, step 9, the simulated H(D) returns false.
Step 10 is back in the simulated D(). The evaluated value of H(D)
is false, shown by #<false>. The if statement falls through.
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
What continues the simulation? The "reckoning" machinery in the UTM
which runs the H(D) test case. When the test case returns, this code
kicks in to check for the oldest unfinished simulation and keeps
stepping it to try to show whether H(D) returning false was the right verdict.
I have shown the concept using a simple simulating halt decider H wth a minimal viable abort test, consisting of trying to run the input for
three instructions and then abandoning it as non-terminating.
You may find the criteria too simple, but if you drill into it, you will
find they don't matter. More complicated criteria which try to detect a repeating pattern of some kind will not change the outcome.
All that matters is that the simulated D gets a false return value from
the simulated H(D) somehow. It could take three steps, or three billion.
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that
you said we could do it for this:
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C
syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3 0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
All the monkeying around with stopping it and restarting it merely
proves that you did not restart it with the exactly the same virtual
machine state as the machine state that is was stopped with.
Am Tue, 04 Nov 2025 14:35:07 -0600 schrieb olcott:
All the monkeying around with stopping it and restarting it merely
proves that you did not restart it with the exactly the same virtual
machine state as the machine state that is was stopped with.
lolwhat? Kaz has working code. Find the error.
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this:
Remember, I had only been joking that you might as well regard
Infinite_Loop as halting. Obviously it isn't
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
If you substitute that for D in my above simulation, you will find that,
no, that doesn't terminate. The example H will give up after the three steps, just like before, and return 0, leaving an abandoned #<interp0> simulation.
When we continue stepping the abandoned #<interp0>, it will just be
trapped in the HERE: goto HERE (confirming that 0 was the correct return value).
It is specifically the diagonal D which reaches its return statement due
to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version of HHH
and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static data:
He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to
its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
without the global variable misuse. HHH[0] decides
non-halting. Resumed simulations all halt with same behaviour
as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
0.
Mike added back your square brackets level indication, so we can see the increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute
indefinitely.
Because it is not recursion, it is not chewing up space in a linear
stack. Every simuation gets a stack and state buffers from Allocate,
which can be released when the simulation terminates, keeping the peak
memory use constant.
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C >>>> syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very
simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation
proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
Yes that part was an excellent empirical proof.
You could just keep increasing N until out-of-memory
error. This would form a reasonably plausible proof
that comes short of absolute certainty that D simulated
by H cannot possibly reach its own "return" statement.
The absolute certainty comes by simply recognizing
the behavior pattern that D simulated cannot possibly
reach its own "return" statement no matter what H does.
All the monkeying around with stopping it and
restarting it merely proves that you did not
restart it with the exactly the same virtual
machine state as the machine state that is
was stopped with.
On 11/4/2025 2:51 PM, joes wrote:
Am Tue, 04 Nov 2025 14:35:07 -0600 schrieb olcott:
All the monkeying around with stopping it and restarting it merely
proves that you did not restart it with the exactly the same virtual
machine state as the machine state that is was stopped with.
lolwhat? Kaz has working code. Find the error.
The absolute certainty comes by simply recognizing
the behavior pattern that D simulated cannot possibly
reach its own "return" statement no matter what H does.
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C
syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3 0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C >>>> syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very
simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
That seems to be a great empirical test.
(step (let ((a 3) (b 4)) (+ a b)))step 1 --> (LET ((A 3) (B 4)) (+ A B))
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation
proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
I don't think so
i == 0 reaches if (interp_step(s))
i == 1 reaches if (interp_step(s))
i == 2 reaches if (interp_step(s))
i == 3 NEVER reaches if (interp_step(s))
Then bool H(fptr P) returns false.
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C
syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0 0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2 0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3 0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C >>>> syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very
simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation
proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
I don't think so
i == 0 reaches if (interp_step(s))
i == 1 reaches if (interp_step(s))
i == 2 reaches if (interp_step(s))
i == 3 NEVER reaches if (interp_step(s))
Then bool H(fptr P) returns false.
The arbitrary cessation of a simulation isn't a determiner of whether
the simulated subject is halting or not.
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C >>>>> syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it. >>>
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very
simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage> >>> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation
proceeded far enough to hit the "interp_init(P)" calculation, to create
the next simulation level.
I don't think so
i == 0 reaches if (interp_step(s))
i == 1 reaches if (interp_step(s))
i == 2 reaches if (interp_step(s))
i == 3 NEVER reaches if (interp_step(s))
Then bool H(fptr P) returns false.
Yes, but then the #<interp0> simulation still exists, and the machine continues it:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C
syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use
for setting up and stepping a simulation; you made no comments about it.
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {--
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
On 11/4/2025 4:33 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C >>>>>> syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use >>>> for setting up and stepping a simulation; you made no comments about it. >>>>
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very >>>> simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it
assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so
it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage> >>>> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage> >>>> 0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation
proceeded far enough to hit the "interp_init(P)" calculation, to create >>>> the next simulation level.
I don't think so
i == 0 reaches if (interp_step(s))
i == 1 reaches if (interp_step(s))
i == 2 reaches if (interp_step(s))
i == 3 NEVER reaches if (interp_step(s))
Then bool H(fptr P) returns false.
Yes, but then the #<interp0> simulation still exists, and the machine
continues it:
No. As soon as i == 3 it does not begin another simulation.
On 2025-11-04, olcott <[email protected]> wrote:
On 11/4/2025 4:33 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 8:22 PM, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:You did not stick with an execution trace of D and only D
What step(s) of D come next in C?
When I posted a detailed symbolic statement-by-statememnt trace using C >>>>>>> syntax several days ago,
showing that and how D reaches its own "return" statement
final halt state when simulated and only simulated by H.
It was a warm-up exercise. The example H wasn't the aborting H.
You made no remarks on the format: is that a good way or bad
way to trace executions of just C.
I invented some fictitious API's into the interpreter that H could use >>>>> for setting up and stepping a simulation; you made no comments about it. >>>>>
The first thing D does when entered is call H(D), so we need an H
to trace concretely.
How about this minimal viable H:
#include <interpret.h> // C interpreter's own API
bool H(fptr P)
{
interp *s = interp_init(P);
for (int i = 0; i < 3; i++) {
if (interp_step(s))
return true;
}
return false;
}
H initializes an interpreter for its argument P. Then it applies a very >>>>> simple abort logic: it steps the interpreter state three times. If
during those three steps, P terminates, it returns true. Otherwise it >>>>> assumes P is nonterminating and returns false.
(Pretend that more complicated abort criteria are there.)
The interpreter API consists of primitives built into the system, so >>>>> it isn't traced.
So then we have D:
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Let's trace H(D). We indicate the simulation levels from 0,
step numbers from 1 within each level, with a bit of indentation
to tell apart the levels:
Level Step Code Vars
0 1 if (H(D)) ...
0 2 H(D)
0 3 interp *s = interp_init(P); ... P = D; s = #<garbage> >>>>> 0 4 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 0
0 5 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 1 if (H(D)) ...
0 6 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 1
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 2 H(D)
0 7 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 2
0 7 if (interp_step(s)) ... P = D; s = #<interp0>; i = 0
1 3 interp *s = interp_init(P); ... P = D; s = #<garbage>
0 8 for (int i = 0; i < 3 i++) ... P = D; s = #<interp0>; i = 3
0 9 return false; P = D; s = #<interp0>; i = 3
OK, so after those 3 steps, H(D) has returned false. The D simulation >>>>> proceeded far enough to hit the "interp_init(P)" calculation, to create >>>>> the next simulation level.
I don't think so
i == 0 reaches if (interp_step(s))
i == 1 reaches if (interp_step(s))
i == 2 reaches if (interp_step(s))
i == 3 NEVER reaches if (interp_step(s))
Then bool H(fptr P) returns false.
Yes, but then the #<interp0> simulation still exists, and the machine
continues it:
No. As soon as i == 3 it does not begin another simulation.
What do you mean by "it"?
If "it" refers to H, that's certainly true.
H is gone after this; it
does nothing, and so if no action is taken, then H's result remains unverified.
The framework does the verification.
H is called from some test case:
void test_main()
{
printf("D halts = %s\n", H(D) ? "true" : "false");
}
The test_main() test case is run by some framework.
After test_main returns to the framework, the framework looks for an unfininished simulation, finding #<interp0> that was created in step "0
3" above.
It begins stepping that simulation, which results in the additional
steps I showed traced after "0 9".
The purpose of these steps is to show whether H's simulation of D
is really nonterminating as it claimed.
H(D) committed a crime against computer science by calling something nonterminating that terminates. It left incriminating evidence behind,
and we are doing the crime scene forensics.
On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this:
Remember, I had only been joking that you might as well regard Infinite_Loop as halting. Obviously it isn't
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
If you substitute that for D in my above simulation, you will find that, no, that doesn't terminate. The example H will give up after the three steps, just like before, and return 0, leaving an abandoned #<interp0> simulation.
When we continue stepping the abandoned #<interp0>, it will just be
trapped in the HERE: goto HERE (confirming that 0 was the correct return value).
It is specifically the diagonal D which reaches its return statement due
to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version of HHH and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static data:
He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but without the global variable misuse. HHH[0] decides non-halting. Resumed simulations all halt with same behaviour
as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0.
Mike added back your square brackets level indication, so we can see the increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute
indefinitely.
Because it is not recursion, it is not chewing up space in a linear
stack. Every simuation gets a stack and state buffers from Allocate,
which can be released when the simulation terminates, keeping the peak memory use constant.
Why are you complicating things, Kaz? It is really quite simple: D does
the opposite of what H(D) reports thus H is wrong. Nothing more needs to
be said on the matter.
/Flibble
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:What details? The trace? More details don’t change the truth.
It was a warm-up exercise. The example H wasn't the aborting H.All of these details must be assumed. When you try to specify these additional steps the essential truth gets lost in the details.
You made no remarks on the format: is that a good way or bad way to
trace executions of just C.
Yes, but D halts when continued this way.At simulation level 1, step 9, the simulated H(D) returns false.
Step 10 is back in the simulated D(). The evaluated value of H(D)
is false, shown by #<false>. The if statement falls through.
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this:
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Exactly! This H_N then returns 1 for D(){ while(!H(D)); }.What continues the simulation? The "reckoning" machinery in the UTMOr you could have much more simply made N larger.
which runs the H(D) test case. When the test case returns, this code
kicks in to check for the oldest unfinished simulation and keeps
stepping it to try to show whether H(D) returning false was the right
verdict.
Proof of what?I have shown the concept using a simple simulating halt decider H wth aYou could just keep increasing N until out-of-memory error. This would
minimal viable abort test, consisting of trying to run the input for
three instructions and then abandoning it as non-terminating.
form a reasonably plausible proof that comes short of absolute
certainty.
The absolute certainty comes by simply recognizing the behavior patternI.e. blind faith.
that D simulated cannot possibly reach its own "return" statement no
matter what H does.
On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:Remember, I had only been joking that you might as well regard
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this: >>>
Infinite_Loop as halting. Obviously it isn't
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
If you substitute that for D in my above simulation, you will find that, >>> no, that doesn't terminate. The example H will give up after the three >>> steps, just like before, and return 0, leaving an abandoned #<interp0>
simulation.
When we continue stepping the abandoned #<interp0>, it will just be
trapped in the HERE: goto HERE (confirming that 0 was the correct return >>> value).
It is specifically the diagonal D which reaches its return statement due >>> to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version of HHH >>> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static >>> data:
He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to >>> its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but >>> without the global variable misuse. HHH[0] decides >>> non-halting. Resumed simulations all halt with same behaviour
as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns >>> 0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns >>> 0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns >>> 0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns >>> 0.
Mike added back your square brackets level indication, so we can see the >>> increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute
indefinitely.
Because it is not recursion, it is not chewing up space in a linear
stack. Every simuation gets a stack and state buffers from Allocate,
which can be released when the simulation terminates, keeping the peak
memory use constant.
Why are you complicating things, Kaz? It is really quite simple: D does
the opposite of what H(D) reports thus H is wrong. Nothing more needs to
be said on the matter.
/Flibble
I think Kaz and Mike were discussing their model of theory, not really
the HP.
To me, the basic idea of HP proof is a simple fact. All theories cannot
defy, whatever they are. If they can address the HP problem, they must conform the fact.
On 2025-11-05, olcott <[email protected]> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
Am Tue, 04 Nov 2025 13:52:58 -0600 schrieb olcott:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
It was a warm-up exercise. The example H wasn't the aborting H.All of these details must be assumed. When you try to specify these
You made no remarks on the format: is that a good way or bad way to
trace executions of just C.
additional steps the essential truth gets lost in the details.
What details? The trace? More details don’t change the truth.
Yes, but D halts when continued this way.At simulation level 1, step 9, the simulated H(D) returns false.
Step 10 is back in the simulated D(). The evaluated value of H(D)
is false, shown by #<false>. The if statement falls through.
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this:
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Exactly! This H_N then returns 1 for D(){ while(!H(D)); }.What continues the simulation? The "reckoning" machinery in the UTMOr you could have much more simply made N larger.
which runs the H(D) test case. When the test case returns, this code
kicks in to check for the oldest unfinished simulation and keeps
stepping it to try to show whether H(D) returning false was the right
verdict.
(H(D_N) still returns 0.)
Proof of what?I have shown the concept using a simple simulating halt decider H wth aYou could just keep increasing N until out-of-memory error. This would
minimal viable abort test, consisting of trying to run the input for
three instructions and then abandoning it as non-terminating.
form a reasonably plausible proof that comes short of absolute
certainty.
The absolute certainty comes by simply recognizing the behavior patternI.e. blind faith.
that D simulated cannot possibly reach its own "return" statement no
matter what H does.
On 2025-11-05, olcott <[email protected]> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
On 11/5/2025 8:52 AM, joes wrote:
Am Tue, 04 Nov 2025 13:52:58 -0600 schrieb olcott:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
Sure we can do that the same way that you said we could do it forYes, but D halts when continued this way.
this:
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Or you could have much more simply made N larger.Exactly! This H_N then returns 1 for D(){ while(!H(D)); }. (H(D_N)
still returns 0.)
I keep asking you if you have ever had any actual programming experienceYou could just keep increasing N until out-of-memory error. This wouldProof of what?
form a reasonably plausible proof that comes short of absolute
certainty.
The absolute certainty comes by simply recognizing the behaviorI.e. blind faith.
pattern that D simulated cannot possibly reach its own "return"
statement no matter what H does.
and you keep proving no, not really. You will keep disagreeing with my
code on the basis that I totally don't understand anything about
programming.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
Kaz finally affirmed the key element of my proof after waiting three
years for this.
Am Wed, 05 Nov 2025 09:54:05 -0600 schrieb olcott:
On 11/5/2025 8:52 AM, joes wrote:
Am Tue, 04 Nov 2025 13:52:58 -0600 schrieb olcott:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
Sure we can do that the same way that you said we could do it forYes, but D halts when continued this way.
this:
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Or you could have much more simply made N larger.Exactly! This H_N then returns 1 for D(){ while(!H(D)); }. (H(D_N)
still returns 0.)
I keep asking you if you have ever had any actual programming experienceYou could just keep increasing N until out-of-memory error. This would >>>> form a reasonably plausible proof that comes short of absoluteProof of what?
certainty.
The absolute certainty comes by simply recognizing the behaviorI.e. blind faith.
pattern that D simulated cannot possibly reach its own "return"
statement no matter what H does.
and you keep proving no, not really. You will keep disagreeing with my
code on the basis that I totally don't understand anything about
programming.
I have programming experience FWIW, but you won’t accept any amount as sufficient, only agreement.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> Yes; this doesn't happen while H is running.
> So while H does /something/, no matter what H does,
> that D simulation won't reach the return statement.
>
Kaz finally affirmed the key element of my proof after waiting three
years for this.
They didn’t affirm what you think they did, just like Sipser and Ben.
They only said that H is wrong by not simulating the halting of D.
So, unlike Infinite_Loop() D() halts when resumed and H_N(D) returns 1.
On 11/5/2025 6:04 AM, wij wrote:
On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:Remember, I had only been joking that you might as well regard
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this: >>>>
Infinite_Loop as halting. Obviously it isn't
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
If you substitute that for D in my above simulation, you will find that, >>>> no, that doesn't terminate. The example H will give up after the three >>>> steps, just like before, and return 0, leaving an abandoned #<interp0> >>>> simulation.
When we continue stepping the abandoned #<interp0>, it will just be
trapped in the HERE: goto HERE (confirming that 0 was the correct return >>>> value).
It is specifically the diagonal D which reaches its return statement due >>>> to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version of HHH >>>> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static >>>> data:
He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to >>>> its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but >>>> without the global variable misuse. HHH[0] decides >>>> non-halting. Resumed simulations all halt with same behaviour
as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns >>>> 0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns >>>> 0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns >>>> 0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns >>>> 0.
Mike added back your square brackets level indication, so we can see the >>>> increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute
indefinitely.
Because it is not recursion, it is not chewing up space in a linear
stack. Every simuation gets a stack and state buffers from Allocate,
which can be released when the simulation terminates, keeping the peak >>>> memory use constant.
Why are you complicating things, Kaz? It is really quite simple: D does
the opposite of what H(D) reports thus H is wrong. Nothing more needs to >>> be said on the matter.
/Flibble
I think Kaz and Mike were discussing their model of theory, not really
the HP.
To me, the basic idea of HP proof is a simple fact. All theories cannot
defy, whatever they are. If they can address the HP problem, they must
conform the fact.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
Kaz finally affirmed the key element of my proof
after waiting three years for this.
On 11/5/2025 10:52 AM, joes wrote:
Am Wed, 05 Nov 2025 09:54:05 -0600 schrieb olcott:
On 11/5/2025 8:52 AM, joes wrote:
Am Tue, 04 Nov 2025 13:52:58 -0600 schrieb olcott:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
Sure we can do that the same way that you said we could do it forYes, but D halts when continued this way.
this:
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Or you could have much more simply made N larger.Exactly! This H_N then returns 1 for D(){ while(!H(D)); }. (H(D_N)
still returns 0.)
I keep asking you if you have ever had any actual programming experience >>> and you keep proving no, not really. You will keep disagreeing with myYou could just keep increasing N until out-of-memory error. This would >>>>> form a reasonably plausible proof that comes short of absoluteProof of what?
certainty.
The absolute certainty comes by simply recognizing the behaviorI.e. blind faith.
pattern that D simulated cannot possibly reach its own "return"
statement no matter what H does.
code on the basis that I totally don't understand anything about
programming.
I have programming experience FWIW, but you won’t accept any amount as
sufficient, only agreement.
How many years in C / C++?
You keep answering like you have no idea what recursion is.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/5/2025 6:04 AM, wij wrote:
On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:Remember, I had only been joking that you might as well regard
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this: >>>>>
Infinite_Loop as halting. Obviously it isn't
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
If you substitute that for D in my above simulation, you will find that, >>>>> no, that doesn't terminate. The example H will give up after the three >>>>> steps, just like before, and return 0, leaving an abandoned #<interp0> >>>>> simulation.
When we continue stepping the abandoned #<interp0>, it will just be
trapped in the HERE: goto HERE (confirming that 0 was the correct return >>>>> value).
It is specifically the diagonal D which reaches its return statement due >>>>> to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version of HHH >>>>> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static >>>>> data:
He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to >>>>> its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but >>>>> without the global variable misuse. HHH[0] decides
non-halting. Resumed simulations all halt with same behaviour
as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
0.
Mike added back your square brackets level indication, so we can see the >>>>> increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute
indefinitely.
Because it is not recursion, it is not chewing up space in a linear
stack. Every simuation gets a stack and state buffers from Allocate, >>>>> which can be released when the simulation terminates, keeping the peak >>>>> memory use constant.
Why are you complicating things, Kaz? It is really quite simple: D does >>>> the opposite of what H(D) reports thus H is wrong. Nothing more needs to >>>> be said on the matter.
/Flibble
I think Kaz and Mike were discussing their model of theory, not really
the HP.
To me, the basic idea of HP proof is a simple fact. All theories cannot
defy, whatever they are. If they can address the HP problem, they must
conform the fact.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
Kaz finally affirmed the key element of my proof
after waiting three years for this.
But that has never been controversial.
The simulating procedure H(P) can never finish simulating its diagonal
case D, because no matter how H is defined, D requires more steps than H performs.
H "spends" a certain "budget" of simulation steps and returns false;
that budget is always too short to cover the full cost of simulating D,
which requires a bunch more steps.
You propose the idea that a machine is nonterminating if the initial
portion of its execution steps is carried out by a simulating decider
which quits before that machine reaches its halting state.
Surely you must realize that looks crazy!?
It's not because of poor communication any more: everything is crystal
clear.
What is the rational argument why anyone should adopt your viewpoint?
We have a simulating decider H which rejects anything as nonterminating
if it requires four or more steps.
Obviously, that is incorrect for any machine which terminates in
four steps. And for any machine which terminqates in five steps.
And for any machine which terminates in six steps ...
And then we have D, which terminates in 11 steps; yet for that one,
the false is correct?
I just don't see how that is going to get you written into history
as the researcher who dismantled the halting problem.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/5/2025 6:04 AM, wij wrote:
On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:Remember, I had only been joking that you might as well regard
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned,
its return statement is reached.
Sure we can do that the same way that you said we could do it for this: >>>>>
Infinite_Loop as halting. Obviously it isn't
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
If you substitute that for D in my above simulation, you will find that, >>>>> no, that doesn't terminate. The example H will give up after the three >>>>> steps, just like before, and return 0, leaving an abandoned #<interp0> >>>>> simulation.
When we continue stepping the abandoned #<interp0>, it will just be
trapped in the HERE: goto HERE (confirming that 0 was the correct return >>>>> value).
It is specifically the diagonal D which reaches its return statement due >>>>> to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version of HHH >>>>> and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated static >>>>> data:
He's getting a nice "infinite tower" in which every MJT_HHH returns 0 to >>>>> its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but >>>>> without the global variable misuse. HHH[0] decides
non-halting. Resumed simulations all halt with same behaviour
as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns
0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns
0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns
0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns
0.
Mike added back your square brackets level indication, so we can see the >>>>> increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute
indefinitely.
Because it is not recursion, it is not chewing up space in a linear
stack. Every simuation gets a stack and state buffers from Allocate, >>>>> which can be released when the simulation terminates, keeping the peak >>>>> memory use constant.
Why are you complicating things, Kaz? It is really quite simple: D does >>>> the opposite of what H(D) reports thus H is wrong. Nothing more needs to >>>> be said on the matter.
/Flibble
I think Kaz and Mike were discussing their model of theory, not really
the HP.
To me, the basic idea of HP proof is a simple fact. All theories cannot
defy, whatever they are. If they can address the HP problem, they must
conform the fact.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
Kaz finally affirmed the key element of my proof
after waiting three years for this.
But that has never been controversial.
On 11/5/2025 11:51 AM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
On 11/5/2025 6:04 AM, wij wrote:
On Tue, 2025-11-04 at 21:04 +0000, Mr Flibble wrote:
On Tue, 04 Nov 2025 20:20:04 +0000, Kaz Kylheku wrote:
On 2025-11-04, olcott <[email protected]> wrote:
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
Step 11 is the return statement reached by D.
When we continue the simulation D that H started and abandoned, >>>>>>>> its return statement is reached.
Sure we can do that the same way that you said we could do it for >>>>>>> this:
Remember, I had only been joking that you might as well regard
Infinite_Loop as halting. Obviously it isn't
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
If you substitute that for D in my above simulation, you will find >>>>>> that,
no, that doesn't terminate. The example H will give up after the >>>>>> three
steps, just like before, and return 0, leaving an abandoned
#<interp0>
simulation.
When we continue stepping the abandoned #<interp0>, it will just be >>>>>> trapped in the HERE: goto HERE (confirming that 0 was the correct >>>>>> return
value).
It is specifically the diagonal D which reaches its return
statement due
to H's return value being 0, including in simulation.
Mike Terry posted some new execution traces from the x86utm with
reckoning continuation. He wrote a new test case: a clean version >>>>>> of HHH
and DDD (called MJT_HHH and MJT_DDD) which do not rely on mutated >>>>>> static
data:
He's getting a nice "infinite tower" in which every MJT_HHH
returns 0 to
its respective MJT_DDD, which then terminates.
He posted this:
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as
HHH, but
without the global variable misuse. HHH[0] decides
non-halting. Resumed simulations all halt with same
behaviour
as HHH[n] deciding non-halting (like HHH[0]) then DDD[n]
returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and >>>>>> returns
0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and >>>>>> returns
0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and >>>>>> returns
0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and >>>>>> returns
0.
Mike added back your square brackets level indication, so we can
see the
increasing simulation levels.
The tower keeps going, but the DDD's terminate.
If the memory management is done right, this should execute
indefinitely.
Because it is not recursion, it is not chewing up space in a linear >>>>>> stack. Every simuation gets a stack and state buffers from Allocate, >>>>>> which can be released when the simulation terminates, keeping the >>>>>> peak
memory use constant.
Why are you complicating things, Kaz? It is really quite simple: D
does
the opposite of what H(D) reports thus H is wrong. Nothing more
needs to
be said on the matter.
/Flibble
I think Kaz and Mike were discussing their model of theory, not really >>>> the HP.
To me, the basic idea of HP proof is a simple fact. All theories cannot >>>> defy, whatever they are. If they can address the HP problem, they must >>>> conform the fact.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
Kaz finally affirmed the key element of my proof
after waiting three years for this.
But that has never been controversial.
The why did it take three f-cking years for even
one person to acknowledge it?
... why did it take three f-cking years for even
one person to acknowledge it?
I would say because all my reviewers have been
dishonest
giving disagreement much more priority
than truth.
I had to box you into a corner where not acknowledging
it would make you look utterly ridiculous.
... a claim about C functions has^^^^^^^
nothing to do with a claim about algorithms
On 06/11/2025 01:29, olcott wrote:
... why did it take three f-cking years for even
one person to acknowledge it?
Did it take 3 three years to establish both of:
(a) common meaning/understanding
(b) a match between perceived purpose and actual purpose
I would say because all my reviewers have been
dishonest
I recall that you gave a nonempty list of those you decided had been
honest. IIRC then you have work to do on your use of "all".
giving disagreement much more priority
than truth.
Truth is a speck of belief in a universe of illusions. Few satisfying interchanges seeking truth will have more than a few truths among many disagreements as the disagreements progressively prompt restrictions
upon the space of meaning until truth remains.
Arthur Conan Doyle said it better than me.
I had to box you into a corner where not acknowledging
it would make you look utterly ridiculous.
I recall seeing a shrinking box as terminology was clarified
satisfactorily. I should note, language often defines a set of (sets of) solutions rather than one and a prompt may be taken to ask for any
solution, the unique solution, a valuation of the universal generality
of a propositional statement, a valuation of any restricted generality
of such, or more besides. You should expect to be required to box your reviewers into a corner before they give a valuation or solution even
when many will foolishly offer them.
We're doing (almost) logic here, if Sipser and Linz do not box their
readers into a corner then I should avoid them.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 06/11/2025 01:29, olcott wrote:
... why did it take three f-cking years for even
one person to acknowledge it?
Did it take 3 three years to establish both of:
(a) common meaning/understanding
(b) a match between perceived purpose and actual purpose
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
I would say because all my reviewers have been
dishonest
I recall that you gave a nonempty list of those you decided had been
honest. IIRC then you have work to do on your use of "all".
giving disagreement much more priority
than truth.
Truth is a speck of belief in a universe of illusions. Few satisfying interchanges seeking truth will have more than a few truths among many disagreements as the disagreements progressively prompt restrictions
upon the space of meaning until truth remains.
Arthur Conan Doyle said it better than me.
I had to box you into a corner where not acknowledging
it would make you look utterly ridiculous.
I recall seeing a shrinking box as terminology was clarified
satisfactorily. I should note, language often defines a set of (sets of) solutions rather than one and a prompt may be taken to ask for any
solution, the unique solution, a valuation of the universal generality
of a propositional statement, a valuation of any restricted generality
of such, or more besides. You should expect to be required to box your reviewers into a corner before they give a valuation or solution even
when many will foolishly offer them.
We're doing (almost) logic here, if Sipser and Linz do not box their
readers into a corner then I should avoid them.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 11/7/2025 9:59 AM, Tristan Wibberley wrote:
Did it take 3 three years to establish both of:
(a) common meaning/understanding
(b) a match between perceived purpose and actual purpose
It took three years to box someone into a corner
where they could not simply dodge the question.
On 07/11/2025 16:13, olcott wrote:
On 11/7/2025 9:59 AM, Tristan Wibberley wrote:
Did it take 3 three years to establish both of:
(a) common meaning/understanding
(b) a match between perceived purpose and actual purpose
It took three years to box someone into a corner
where they could not simply dodge the question.
well dodged that man.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,076 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 78:39:21 |
| Calls: | 13,805 |
| Files: | 186,990 |
| D/L today: |
5,990 files (1,958M bytes) |
| Messages: | 2,443,207 |