On 2025-11-11, olcott <polcott333@gmail.com> wrote:
On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
On 2025-11-11, olcott <polcott333@gmail.com> wrote:
On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
On 2025-11-11, olcott <polcott333@gmail.com> wrote:
On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
On 2025-11-10, olcott <polcott333@gmail.com> wrote:
On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
On 2025-11-10, olcott <polcott333@gmail.com> wrote:
That is not the behavior that the input to H(D) specifies.
Insane nonsense.
The input to H is one single D which specifies one single behavior. >>>>>>>>>
simulator.exe simulates Test.c. This simulates D that
calls H(D) that the simulator recognizes as itself.
"recognizing self" is an undecidable problem.
simulator.exe is
... a figment of your imagination, and has whatever
properties you need it to have to suit whatever narrative
you are spinning at the moment.
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
The interpreter API consists of primitives built
into the system, so it isn't traced.
The internals of these primitives can be imagined
without being directly specified.
In my interpreter walkthrough I more or less specified /what/ the
interfaces do with the example. It is very clear how the simulation
object tracks the control flows and steps into statements; it is
plausible due to these details; no step requires "magical thinking"
or the solution to incomputable problems.
You are not specifying anything concrete, neither by a body of
requirements, nor by concrete example.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
I will just go back to my original code
if you want to play head games.
It has been shown with actual programming against your code framework
that abortind deciders leave behind continuable simulations, which may
terminate.
Only if you don't resume them at the
exact same state where you left them
and that is flat our cheating.
The parameters required for the next DebugStep of the abandoned
simulation are correctly determined.
You need to point out the exact lines of code which have the problem
that you are alleging, and give details about that problem, otherwise
you are blabbing about nothing.
Am Wed, 12 Nov 2025 07:37:05 -0600 schrieb olcott:
On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
On 2025-11-11, olcott <polcott333@gmail.com> wrote:
Luckily that?s not what?s going on.Only if you don't resume them at the exact same state where you left >>>>>> them and that is flat our cheating.
A caller cannot abort a function.But, /all the instructions have to be from the same control flow/.When DD calls HHH(DD) and HHH simulates DD this control flow is
isomorphic to HHH invoking DD.
On 2025-11-12, olcott <polcott333@gmail.com> wrote:
You aren't doing that, by the way, in the latest Needs_To_Be_Aborted_Trace_HH:
On 11/12/2025 8:16 PM, Kaz Kylheku wrote:
On 2025-11-12, olcott <polcott333@gmail.com> wrote:
You aren't doing that, by the way, in the latest
Needs_To_Be_Aborted_Trace_HH:
*This is a FOREVER thing until someone admits the truth*
*This is a FOREVER thing until someone admits the truth*
*This is a FOREVER thing until someone admits the truth*
int D()
{
˙ int Halt_Status = H(D);
˙ if (Halt_Status)
˙˙˙ HERE: goto HERE;
˙ return Halt_Status;
}
Everyone here rejects that the execution trace
of 5 statements of D simulated by H according to
the semantics of C is this:
(1)˙˙˙ H simulates D that calls H(D)
(2) that simulates D that calls H(D)
(3) that simulates D that calls H(D)
(4) that simulates D that calls H(D)
(5) that simulates D that calls H(D)
if (current->Simplified_Opcode == CALL)
if (current->Simplified_Opcode == traced->Simplified_Opcode) // CALL >> if (current->Address == traced->Address) // from same address
if (current->Decode_Target == traced->Decode_Target)// to Same Function
if (Count_Conditional_Branch_Instructions == 0) // no escape >>
It's just checking for repeated "CALL HHH".
The CALL in struction doesn't include the arguments; they have to be
prepared in registers or pushed onto the stack (or both), depending on
the calling conventions.
I imagine you tried doing that but ran into the problem that since
you are idiotically conflating multiple execution traces,
The trace for the PUSH instruction which prepares the argument
for the CALL, in the Level [2] simulation will be separated
from its CALL by all the instruction traces of the DebugStep
loop of Level[1]!
The Level[1] loop, itself being simulated, has to DebugStep a PUSH
instruction that prepares an argument. Then it has to go all way around
its loop, during which time execution traces are being looged for it.
Then it has to DebugStep the CALL instruction.
If you did not conflate the instruction eents into a single buffer,
you could easily find the previous PUSH instruction for a given
CALL, in the private trace buffer of /that/ simulation.
(It may be that Mike Terry has implemented that; I've not seen his
code.)
But, /all the instructions have to be from the same control flow/.
When DD calls HHH(DD) and HHH simulates DD this
control flow is isomorphic to HHH invoking DD.
I'm afraid your knowledge and skills here are limited to being able to
spell "isomorophic" and use it in a syntactically plausible sentence,
much like your LLM friends.
On 11/12/2025 8:25 PM, Kaz Kylheku wrote:
If those two are in any way whatsoever different, the entire
castle you built in the sand is washed away.
*This is a FOREVER thing until someone admits the truth*
*This is a FOREVER thing until someone admits the truth*
*This is a FOREVER thing until someone admits the truth*
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Everyone here rejects that the execution trace
of 5 statements of D simulated by H according to
the semantics of C is this:
(1) H simulates D that calls H(D)
(2) that simulates D that calls H(D)
(3) that simulates D that calls H(D)
(4) that simulates D that calls H(D)
(5) that simulates D that calls H(D)
[...]
I note that a substantial fraction of the articles recently posted
to comp.lang.c (and probably comp.lang.c++) are cross-posted to
comp.theory, and are about the Halting Problem.
Some of these articles contain small fragments of C-like source code,
but I suggest that doesn't make them either topical or interesting
to most participants in the C and C++ newsgroups.
I humbly suggest, yet again, that these discussions be restricted
to comp.theory, and that users try to edit the "Newsgroups:" header
even when replying to a cross-posted article.
On 11/12/2025 9:49 PM, Keith Thompson wrote:
[...]
I note that a substantial fraction of the articles recently posted
to comp.lang.c (and probably comp.lang.c++) are cross-posted to
comp.theory, and are about the Halting Problem.
Some of these articles contain small fragments of C-like source code,
but I suggest that doesn't make them either topical or interesting
to most participants in the C and C++ newsgroups.
I humbly suggest, yet again, that these discussions be restricted
to comp.theory, and that users try to edit the "Newsgroups:" header
even when replying to a cross-posted article.
int D()
{
˙ int Halt_Status = H(D);
˙ if (Halt_Status)
˙˙˙ HERE: goto HERE;
˙ return Halt_Status;
}
I would love to do that after one person confirms
that D simulated by H according to the semantics
of the C programming language cannot reach its
own "return" statement.
People on all forums have been dodging that or
lying about that consistently for three years.
I only came to this forum to get that one question
answered and until then I will keep repeating it
several times a day forever. Feel free to keep
ignoring it now that you know the consequences.
On 13/11/2025 05:36, olcott wrote:
On 11/12/2025 9:49 PM, Keith Thompson wrote:
[...]
I note that a substantial fraction of the articles recently posted
to comp.lang.c (and probably comp.lang.c++) are cross-posted to
comp.theory, and are about the Halting Problem.
Some of these articles contain small fragments of C-like source code,
but I suggest that doesn't make them either topical or interesting
to most participants in the C and C++ newsgroups.
I humbly suggest, yet again, that these discussions be restricted
to comp.theory, and that users try to edit the "Newsgroups:" header
even when replying to a cross-posted article.
int D()
{
˙˙ int Halt_Status = H(D);
˙˙ if (Halt_Status)
˙˙˙˙ HERE: goto HERE;
˙˙ return Halt_Status;
}
I would love to do that after one person confirms
that D simulated by H according to the semantics
of the C programming language cannot reach its
own "return" statement.
People on all forums have been dodging that or
lying about that consistently for three years.
I only came to this forum to get that one question
answered and until then I will keep repeating it
several times a day forever. Feel free to keep
ignoring it now that you know the consequences.
Given that you've been doing this for so many years, and got the same results every time - everyone disagrees with your fundamental concepts - what makes you think you can change people's minds by repeating the same questions and claims?
If you are wrong, and everyone else is right, then you are wasting your
time and everyone else's time.
If you are right and everyone else is wrong, then your posts are /still/ wasting your time and everyone else's time.
If you are sure you are correct, you have to find a different way to
prove it.˙ How about you stop repeating yourself on Usenet groups (especially c.l.c and c.l.c++, but also comp.theory and other groups),
and do something /useful/ with your breakthrough?˙ You suggested your solution to the halting problem could lead to a universal truth
identifier that would save the world.˙ Surely that is more worthy of
your time than beating your head against this wall?˙ Give up on the
ignorant masses here, and work with the LLM's that believe in you to
create your truth identifier.˙ When we hear on international news how it
is changing the world, we'll get back to you and apologise for our lack
of faith.
On 13/11/2025 05:36, olcott wrote:
On 11/12/2025 9:49 PM, Keith Thompson wrote:
[...]
I note that a substantial fraction of the articles recently posted
to comp.lang.c (and probably comp.lang.c++) are cross-posted to
comp.theory, and are about the Halting Problem.
Some of these articles contain small fragments of C-like source code,
but I suggest that doesn't make them either topical or interesting
to most participants in the C and C++ newsgroups.
I humbly suggest, yet again, that these discussions be restricted
to comp.theory, and that users try to edit the "Newsgroups:" header
even when replying to a cross-posted article.
int D()
{
˙˙ int Halt_Status = H(D);
˙˙ if (Halt_Status)
˙˙˙˙ HERE: goto HERE;
˙˙ return Halt_Status;
}
I would love to do that after one person confirms
that D simulated by H according to the semantics
of the C programming language cannot reach its
own "return" statement.
People on all forums have been dodging that or
lying about that consistently for three years.
I only came to this forum to get that one question
answered and until then I will keep repeating it
several times a day forever. Feel free to keep
ignoring it now that you know the consequences.
Given that you've been doing this for so many years, and got the same results every time - everyone disagrees with your fundamental concepts - what makes you think you can change people's minds by repeating the same questions and claims?
If you are wrong, and everyone else is right, then you are wasting your
time and everyone else's time.
If you are right and everyone else is wrong, then your posts are /still/ wasting your time and everyone else's time.
If you are sure you are correct, you have to find a different way to
prove it.˙ How about you stop repeating yourself on Usenet groups (especially c.l.c and c.l.c++, but also comp.theory and other groups),
and do something /useful/ with your breakthrough?˙ You suggested your solution to the halting problem could lead to a universal truth
identifier that would save the world.˙ Surely that is more worthy of
your time than beating your head against this wall?˙ Give up on the
ignorant masses here, and work with the LLM's that believe in you to
create your truth identifier.˙ When we hear on international news how it
is changing the world, we'll get back to you and apologise for our lack
of faith.
On 2025-11-13, olcott <polcott333@gmail.com> wrote:
H computes the mapping from its input to the behavior
that this actual input actually specifies as measured
by N statements of D simulated by H according to the
semantics of the C language until N statements of D
match the their non-halting behavior pattern:
If the computation D is known to terminate in N + 5 steps,
then that measure is simply not long enough.
You're emeasuring a 15' room with a 12' measuring tape,
declaring the room to be infinite.
D calls H(D) twice in sequence with the same argument
Really? Let's look at the code:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
No competent programmer would look at that and say that D
calls H twice.
On 2025-11-19, olcott <polcott333@gmail.com> wrote:
On 11/18/2025 7:01 PM, Kaz Kylheku wrote:
On 2025-11-18, olcott <polcott333@gmail.com> wrote:
On 11/18/2025 3:21 PM, Kaz Kylheku wrote:
On 2025-11-18, olcott <polcott333@gmail.com> wrote:
If you ask a decider to determine if my
sister's name is "Sally" and I don't tell
it who I am then the information contained
in the input is insufficient. This does not
in any way limit computation itself.
The problem is that UTM(D) can work out the fact that
D halts. Why is it that UTM knows that D's sister's
name is Sally, but H does not?
UTM(D) is answering a different question.
(a) It is not providing any answer at all.
Well, of course, by "UTM" we mean a /decider/ that purely simulates:
bool UTM(ptr P) {
sim S = sim_create(P);
sim_step_exhaustively(S);
return true;
}
All deciders applied to D are tasked with answering exactly the same
question.
Pretending that a different question was asked is nonproductive;
the answer will be interpreted to the original question.
All the information needed to answer is positively contained in D.
It is just too complex relative to H.
What The F does UTM decide when DD calls UTM(DD)?
That doesn't happen; DD calls HHH(DD).
A diagonal functon set against UTM, call it DDUTM,
cannot be decided by UTM(DDUTM).
That call simply does not return.
On 11/18/2025 8:53 PM, Kaz Kylheku wrote:
On 2025-11-19, olcott <polcott333@gmail.com> wrote:
On 11/18/2025 7:01 PM, Kaz Kylheku wrote:
On 2025-11-18, olcott <polcott333@gmail.com> wrote:
On 11/18/2025 3:21 PM, Kaz Kylheku wrote:
On 2025-11-18, olcott <polcott333@gmail.com> wrote:
If you ask a decider to determine if my
sister's name is "Sally" and I don't tell
it who I am then the information contained
in the input is insufficient. This does not
in any way limit computation itself.
The problem is that UTM(D) can work out the fact that
D halts. Why is it that UTM knows that D's sister's
name is Sally, but H does not?
UTM(D) is answering a different question.
(a) It is not providing any answer at all.
Well, of course, by "UTM" we mean a /decider/ that purely simulates:
bool UTM(ptr P) {
sim S = sim_create(P);
sim_step_exhaustively(S);
return true;
}
All deciders applied to D are tasked with answering exactly the same
question.
Pretending that a different question was asked is nonproductive;
the answer will be interpreted to the original question.
All the information needed to answer is positively contained in D.
It is just too complex relative to H.
What The F does UTM decide when DD calls UTM(DD)?
That doesn't happen; DD calls HHH(DD).
A diagonal functon set against UTM, call it DDUTM,
cannot be decided by UTM(DDUTM).
That call simply does not return.
Yes, and the other one does return proving the
whole point that I have been making for three
years that everyone (besides Ben) was too damned
dishonest to acknowledge has been true all along.
D simulated by H cannot possibly reach its own
simulated final halt state.
I am not going to talk about any non-nonsense of
resuming a simulation after we already have this
final answer.
We just proved that the input to H(D) specifies
non-halting. Anything beyond this is flogging a
dead horse.
news://news.eternal-september.org/20251104183329.967@kylheku.com
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <polcott333@gmail.com> 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 06.11.2025 um 21:48 schrieb olcott:
D simulated by H cannot possibly reach its ownWhat you do is like thinking in circles before falling asleep.
simulated final halt state.
I am not going to talk about any non-nonsense of
resuming a simulation after we already have this
final answer.
We just proved that the input to H(D) specifies
non-halting. Anything beyond this is flogging a
dead horse.
news://news.eternal-september.org/20251104183329.967@kylheku.com
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <polcott333@gmail.com> 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.
It never ends. You're gonna die with that for sure sooner or later.
On 11/25/2025 9:20 AM, Bonita Montero wrote:It don't matters if you're correct. There's no benefit in discussing
What you do is like thinking in circles before falling asleep.
It never ends. You're gonna die with that for sure sooner or later.
I now have four different LLM AI models that prove
that I am correct on the basis that they derive the
proof steps that prove that I am correct.
Even Kimi that was dead set against me now fully
understands my new formal foundation for correct
reasoning.
Am 25.11.2025 um 16:47 schrieb olcott:
On 11/25/2025 9:20 AM, Bonita Montero wrote:
What you do is like thinking in circles before falling asleep.
It never ends. You're gonna die with that for sure sooner or later.
I now have four different LLM AI models that prove
that I am correct on the basis that they derive the
proof steps that prove that I am correct.
It don't matters if you're correct. There's no benefit in discussing
such a theoretical topic for years. You won't even stop if everyone
tells you're right.
Even Kimi that was dead set against me now fully
understands my new formal foundation for correct
reasoning.
On 11/25/2025 9:20 AM, Bonita Montero wrote:
Am 06.11.2025 um 21:48 schrieb olcott:
D simulated by H cannot possibly reach its ownWhat you do is like thinking in circles before falling asleep.
simulated final halt state.
I am not going to talk about any non-nonsense of
resuming a simulation after we already have this
final answer.
We just proved that the input to H(D) specifies
non-halting. Anything beyond this is flogging a
dead horse.
news://news.eternal-september.org/20251104183329.967@kylheku.com
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <polcott333@gmail.com> 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.
It never ends. You're gonna die with that for sure sooner or later.
I now have four different LLM AI models that prove
that I am correct on the basis that they derive the
proof steps that prove that I am correct.
Even Kimi that was dead set against me now fully
understands my new formal foundation for correct
reasoning.
On 11/25/2025 9:50 AM, Bonita Montero wrote:
Am 25.11.2025 um 16:47 schrieb olcott:
On 11/25/2025 9:20 AM, Bonita Montero wrote:
What you do is like thinking in circles before falling asleep.
It never ends. You're gonna die with that for sure sooner or later.
I now have four different LLM AI models that prove
that I am correct on the basis that they derive the
proof steps that prove that I am correct.
It don't matters if you're correct. There's no benefit in discussing
such a theoretical topic for years. You won't even stop if everyone
tells you're right.
My whole purpose of this has been to establish a
new foundation for correct reasoning that gets rid
The timing for such a system is perfect because it
could solve the LLM AI reliability issues.
On 2025-11-06, olcott <polcott333@gmail.com> wrote:
D simulated by H cannot possibly reach its own
simulated final halt state.
It has been shown /wth code/ that D simulated by H reaches its return, possible even in your horribly incorrect program that fails to conform
to the requirements for exploring the halting problem.
On 2025-11-05, olcott <polcott333@gmail.com> 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 2025-11-25, olcott <polcott333@gmail.com> wrote:
On 11/25/2025 11:42 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <polcott333@gmail.com> wrote:
D simulated by H cannot possibly reach its own
simulated final halt state.
It has been shown /wth code/ that D simulated by H reaches its return,
Liar, Liar Pants on Fire !!!
I made the code public; another person was able to build and get the
same results.
On 2025-11-05, olcott <polcott333@gmail.com> 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 2025-11-05, olcott <polcott333@gmail.com> 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 2025-11-05, olcott <polcott333@gmail.com> 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 2025-11-05, olcott <polcott333@gmail.com> 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 2025-11-05, olcott <polcott333@gmail.com> 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.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 14 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 237:53:18 |
| Calls: | 184 |
| Files: | 21,502 |
| Messages: | 82,415 |