On 26/10/2025 05:29, Kaz Kylheku wrote:
There you go:
https://www.kylheku.com/cgit/x86utm/commit/?id=2cd60805c4fb6dc46d7ccfcac2509ec8821a838d
All further arguments against the idea that DDD simulated by HHH(DDD)
is antyhing but halting must refer to the code, with patches.
No more bullshit about liar paradoxes, incorrect questions or ChatGPT
says this and that.
If the result is wrong, show me where the flaw is.
If DDD is non-halting, what is going wrong to make it look halting?
Propose a /patch/ to fix it, and argue why the patch is correct.
Just letting you know I tried out your code from GIT.� It built as expected, and ran against the
halt7.obj in the repository [main calls HHH(DDD)] pretty much like I described in a previous email.
As noted there, there are indeed huge problems due to PO's misuse of global variables, specifically
**execution_trace.
I did spot something I hadn't considered.� You mentioned that PushBack () had been amended to cater
for the trace buffer filling up, and elsewhere I noted that would surprise me, because there are
really not that many entries written to it, even with considerable simulation nesting, because it is
heavily filtered.� [Basically, just instructions inside DDD*(), so say half a dozen per level of
simulation/ and the buffer is enough for 10000 entries...]
So I wasn't expecting that code path to be hit, but indeed it was!� But looking closer it was due to
another of those global data problems :(� Basically, Decide_Halting_HH[1] was being stepped, and due
to **execution_trace (global) having been reset to 0x90909090 [by HHH[2]?? I forget now] it was
trying to PushBack () trace entries (generated by DDD[2] as it was exiting), but specifying a trace
table at 0x90909090.� That memory is all zeros, and that is interpreted as there being no space
left, and your compression code jumps in and somewhat splats some memory near 0x90909090.� As luck
has it, that memory was unused, so no disaster occured.
So in this case at least, the "real" trace table(s) hadn't filled up, but I don't know if it
legitimately fills up in other test cases.
I think I'll integrate your code into my play-code version of PO's code, as that has a number of
improvements/fixes and I don't see why your code wouldn't work entirely as originally envisioned,
and with better output being generated as well.� Assuming I find the time I'll post any new output
traces that result.
Hmm, one thing I wondered was whether your resumption code would correctly recognise a simulation
that had actually terminated prior to resumption.� [Thinks:� the final ret instruction will have
been stepped in such a simulation, so god only knows what the EIP will be in the slave_state
structure!� It wouldn't be the end-of-code address as its "gone past" that.� Well, PO's simulations
of interest are all abandoned, so not #1 priority...]
Mike.
Below are 3 traces with different inputs. I'm sure you'll have run the first two yourself, but the
third will be new (but not surprising...) I modified your code somewhat to make it resume all the
outstanding simulations (until interrupted), and to integrate with my "simulation depth" reporting -
that's the SIM column on the left of the traces. Also my play code has "rationalised" log output so
your resumptions show the (filtered) trace instructions executed. [That came for free without
changing your code.] So I'd say the traces below are clearer than previously posted, if only
because you can see which simulation level is producing the various output messages! PO once added
code to add the simulation level to the instruction trace output, but then removed it, saying it
confused people!
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.
On 2025-11-04, Mike Terry <[email protected]> wrote:
Below are 3 traces with different inputs. I'm sure you'll have run the first two yourself, but the
third will be new (but not surprising...) I modified your code somewhat to make it resume all the
outstanding simulations (until interrupted), and to integrate with my "simulation depth" reporting -
that's the SIM column on the left of the traces. Also my play code has "rationalised" log output so
your resumptions show the (filtered) trace instructions executed. [That came for free without
changing your code.] So I'd say the traces below are clearer than previously posted, if only
because you can see which simulation level is producing the various output messages! PO once added
code to add the simulation level to the instruction trace output, but then removed it, saying it
confused people!
You clarified the situation with PushBack as being a case of the execution_trace pointer becoming invalidated to 0x90909090, and the
memory at that address looking like a full buffer. The code could just
check for that 0x90909090 value, and in that case drop the sample and
return, to tie things over until a buffer reappears.
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.
Nice.
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.
On 2025-11-04, Mike Terry <[email protected]> wrote:
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.
If every HHH deallocates the memory resources of the terminated DDD,
this should be able to keep running indefinitely.
There is no recursion chewing up a single linear stack that will
overflow.
On 04/11/2025 19:36, Kaz Kylheku wrote:
On 2025-11-04, Mike Terry <[email protected]> wrote:True. With the code as it is, it didn't last very long before out of memory:
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. >>If every HHH deallocates the memory resources of the terminated DDD,
this should be able to keep running indefinitely.
There is no recursion chewing up a single linear stack that will
overflow.
.....
RECK: ---------------
RECK: continuing simulation of [50]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack ==
00F4D0E0
[51]--Allocate (00000018) --> 00fe2498
[51]--Allocate (00000034) --> 00fe24b8
[51]--Allocate (00000034) --> 00fe24f4
[51]--Allocate (00010000) --> 00fe2530
RECK: test case allocated new simulation [52]: 00fe2498:00000000:00fe24b8:00fe24f4:00fe2530
[51]New slave_stack at:fe2530
[51]--Allocate(240000) failed
[51]
Begin Local Halt Decider Simulation Execution Trace Stored at:0
RECK: 000021b2 is _MJT_DD
RECK: newly executing [52]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00FE2530
[52][000021b2][00ff2528][00ff252c] 55 push ebp
Ran out of memory@ Address[00000000]
So it ran out while resuming MJT_DD[50]. Like you say, the progress was linear, because each new
level resumed is like the original first level simulation, so there's no slowing down as we get
deeper.
The whole virtual address space is 32-bit, so 4GB. x86utm has no support for releasing
Allocate()ed memory...
On 2025-11-04, Mike Terry <[email protected]> wrote:
On 04/11/2025 19:36, Kaz Kylheku wrote:
On 2025-11-04, Mike Terry <[email protected]> wrote:True. With the code as it is, it didn't last very long before out of memory:
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.
If every HHH deallocates the memory resources of the terminated DDD,
this should be able to keep running indefinitely.
There is no recursion chewing up a single linear stack that will
overflow.
.....
RECK: ---------------
RECK: continuing simulation of [50]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack ==
00F4D0E0
[51]--Allocate (00000018) --> 00fe2498
[51]--Allocate (00000034) --> 00fe24b8
[51]--Allocate (00000034) --> 00fe24f4
[51]--Allocate (00010000) --> 00fe2530
RECK: test case allocated new simulation [52]: 00fe2498:00000000:00fe24b8:00fe24f4:00fe2530
[51]New slave_stack at:fe2530
[51]--Allocate(240000) failed
[51]
Begin Local Halt Decider Simulation Execution Trace Stored at:0
RECK: 000021b2 is _MJT_DD
RECK: newly executing [52]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00FE2530
[52][000021b2][00ff2528][00ff252c] 55 push ebp
Ran out of memory@ Address[00000000]
So it ran out while resuming MJT_DD[50]. Like you say, the progress was linear, because each new
level resumed is like the original first level simulation, so there's no slowing down as we get
deeper.
Each new level is resumed using a DebugStep() loop inside a function in reckoning.cc, which runs on the host processor directly, and so it
strips away the any extra layer of interpreter penalty under which that simulation had operated prior to being resumed.
In principle, it could be compiled for a different machine; if you port
and build x86utm for an ARM, our DebugStep loop in reckoning.cc will be
ARM code, calling into an ARM-compiled DebugStep, calling into an ARM-compiled x86emu.
DebugStep itself is always native, regardless of the simulation level
from which it is invoked; the x86emu code comprising it is never
simulated. When test cases like HHH call DebugStep (via a simplified
API), that is recognized by the VM and treated as one giant "microcoded" instruction coded inside x86utm_exe.
(The idea of the x86 emulator recognizing certain function calls and implementing them as "microcode" is a decent hack. I don't like that
it performs string comparisons on function names to do the dispatch.
I.e. when a CALL instruction is handled, the destination address
is first mapped to a name using the COFF reader context and then
string comparisons check that name against a vocabulary of function
names handled directly by the VM. Regardless, Olcott did a good
job in that regard; it's unclear why he's acting so dumb now. Maybe a
decade of cognitive decline? If that's literally the ony thing he coded
in ten years, and isn't working in any job, that's not enough to keep
the brain from turning into mush.)
I don't really see that PO has declined recently - It seems to me he's
been the way he is for as long as I recall. I would say he's become markedly ruder of late, though! Maybe that's all related to his LLMs pandering to his delusions and giving him a renewed confidence.
Mike.
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:
On 11/4/2025 7:20 PM, Mike Terry wrote:
I don't really see that PO has declined recently - It seems to me he's
been the way he is for as long as I recall. I would say he's become
markedly ruder of late, though! Maybe that's all related to his LLMs
pandering to his delusions and giving him a renewed confidence.
Mike.
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
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:
*This is the part that Kaz does not understand*
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))
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
If we continue the simulation with the exact
same machine state then H simply returns false
because i == 3.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 7:20 PM, Mike Terry wrote:
I don't really see that PO has declined recently - It seems to me he's
been the way he is for as long as I recall. I would say he's become
markedly ruder of late, though! Maybe that's all related to his LLMs
pandering to his delusions and giving him a renewed confidence.
Mike.
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
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:
*This is the part that Kaz does not understand*
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))
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.
H has to return zero first and terminate, leaving the simulation
abandoned.
That's the one thing that H can "do" which then lets D
reach its return statement.
Then the simulation framework itself picks up that simuation
and does the stepping.
If we continue the simulation with the exact
same machine state then H simply returns false
because i == 3.
Remember, we are not continuing the top level H,
which terminated and returned zero, but the simulated
D which is calling the simulated H.
That simulated H is just getting into the loop. Continued, it takes i
from 0 to i == 3, and returns false.
Where does it return? To the simulated D!
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 7:20 PM, Mike Terry wrote:
I don't really see that PO has declined recently - It seems to me he's >>>> been the way he is for as long as I recall. I would say he's become
markedly ruder of late, though! Maybe that's all related to his LLMs >>>> pandering to his delusions and giving him a renewed confidence.
Mike.
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
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:
*This is the part that Kaz does not understand*
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))
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.
H has to return zero first and terminate, leaving the simulation
abandoned.
Just like leaving the Infinite_loop() abandoned.
That's the one thing that H can "do" which then lets D
reach its return statement.
When H has stopped simulating D then a resumption
of the exact same machine state of this simulation
would simply be the point where H rejected D.
Then the simulation framework itself picks up that simuation
and does the stepping.
If the simulation framework resumes the simulation
at the exact same machine state with H local i == 3
and H already returned to the simulation framework
then resuming the simulation cannot do anything more
than immediately return to the simulation framework.
If we continue the simulation with the exact
same machine state then H simply returns false
because i == 3.
Remember, we are not continuing the top level H,
which terminated and returned zero, but the simulated
D which is calling the simulated H.
When we actually literally resume the simulation
then it must be the exact same machine state of
the whole system at the point just after H returned
false to the simulation framework.
If we don't do exactly this then we are not actually
resuming anything.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 7:20 PM, Mike Terry wrote:
I don't really see that PO has declined recently - It seems to me he's
been the way he is for as long as I recall. I would say he's become
markedly ruder of late, though! Maybe that's all related to his LLMs
pandering to his delusions and giving him a renewed confidence.
Mike.
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
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:
*This is the part that Kaz does not understand*
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))
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.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
Yes; this doesn't happen while H is running.
Then that all by itself conclusively proves that
the input to H(D) specifies non-halting behavior
when halting behavior is stipulated to mean behavior
that cannot possibly reach its own final halt state
as measured by D simulated by H.
Within the 100% perfectly exact meaning of those
words without the tiniest little change
I AM PROVED EXACTLY CORRECT.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 7:20 PM, Mike Terry wrote:
I don't really see that PO has declined recently - It seems to me he's
been the way he is for as long as I recall. I would say he's become
markedly ruder of late, though! Maybe that's all related to his LLMs
pandering to his delusions and giving him a renewed confidence.
Mike.
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
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:
*This is the part that Kaz does not understand*
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))
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.
On 11/4/2025 8:43 PM, Kaz Kylheku 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.
*That is the definition of non-halting input*
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
*That is the definition of non-halting input**This is the part that Kaz does not understand*
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))
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.
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:We are not resuming H. H has halted. We are resuming the simulation of D.
That's the one thing that H can "do" which then lets D reach its returnWhen H has stopped simulating D then a resumption of the exact same
statement.
machine state of this simulation would simply be the point where H
rejected D.
If the simulation framework resumes the simulation at the exact sameSee above.
machine state with H local i == 3 and H already returned to the
simulation framework then resuming the simulation cannot do anything
more than immediately return to the simulation framework.
When we actually literally resume the simulation then it must be the
exact same machine state of the whole system at the point just after H returned false to the simulation framework.
If we don't do exactly this then we are not actually resuming anything.
Am Tue, 04 Nov 2025 23:23:13 -0600 schrieb olcott:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
*That is the definition of non-halting input**This is the part that Kaz does not understand*
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))
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.
H stops running before D halts.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
*That is the definition of non-halting input*
Well, anyway, there you go; that's how the "D simulated by H" is the
same halting D as the directly executed one.
You can keep working your same rhetoric on top of that
if you like; that in spite of that, there is some magically
different D that is non-halting.
If halting doesn't happen on H's watch, then the
input is nonhalting, and that is correct.
For instance this:
void Finite_Loop(void)
{
for (i = 0; i < 1000; i++) { }
}
This doesn't finish simulating in H's three interp_step(s) operations. Therefore H(Finite_Loop) returns 0.
That must be correct, right? The 2000 step Finite_Loop, as measured by
H, is nonterminating: it does not reach termination while simulated by
H, exactly like the 11 step D.
Both of them obvious terminate, but ... wait for it .... that's not
the input!!!
Remember, halting deciders only operate on the finite string that is
their actual input, and not on a running process.
Yadda yadda, I've written it for you so you don't have to.
But anyway, I hope it is perfectly clear what is meant by
continuing an abandoned simulation and all that; it has been
shown in close to the simplest possible way possible subject
to C having to be used.
On 11/5/2025 1:42 AM, joes wrote:
Am Tue, 04 Nov 2025 23:23:13 -0600 schrieb olcott:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
*That is the definition of non-halting input**This is the part that Kaz does not understand*
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))
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.
H stops running before D halts.
The whole point is that D simulated by H cannot possibly reach
its own simulated "return" statement no matter what H does, thus
proving that D simulated by H never halts. Weasel words to the
contrary are lies.
On 05/11/2025 11:33, olcott wrote:
On 11/5/2025 1:42 AM, joes wrote:
Am Tue, 04 Nov 2025 23:23:13 -0600 schrieb olcott:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
*That is the definition of non-halting input**This is the part that Kaz does not understand*
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))
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.
H stops running before D halts.
The whole point is that D simulated by H cannot possibly reach
"H cannot possibly " is prime duffer-speak.
H is one algorithm and can do only one thing.
You are trying to suggest it can think about its
situation and dynamically change its mind somehow,
doing other than what its program says.
Mike.
--its own simulated "return" statement no matter what H does, thus
proving that D simulated by H never halts. Weasel words to the
contrary are lies.
On 11/5/2025 1:01 AM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
*That is the definition of non-halting input*
Well, anyway, there you go; that's how the "D simulated by H" is the
same halting D as the directly executed one.
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
The semantic halting property of the input
to H(D) has been proven to be non-halting.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/5/2025 1:01 AM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
*That is the definition of non-halting input*
Well, anyway, there you go; that's how the "D simulated by H" is the
same halting D as the directly executed one.
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
The semantic halting property of the input
to H(D) has been proven to be non-halting.
So you are saying that no simulating decider could ever be wrong about
its D-like diagonal input case, if it conducts an incomplete (but
otherwise correct) simulation of its input and then returns false for
any reason whatsoever (such as "if the input is taking more than three
steps, it must be nonterminating").
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.
And you believe that this will get you written into the history books as
the researcher who showed that the halting problem is all wrong.
You think that math/CS academia will see it from your perspective and
just agree that when H detaches from D, the question of whether the
abandoned simulation is terminating becomes off-limits (like some sort "inadmissible evidence")?
But at least hopefully you did see that the simulation of D started by H
can be completed, resulting in the same total 11 wsteps as a directly executed D. (It just cannot all happen while H is running; H obviously cannot be the sole driver which pushes the simulation to completion,
since it only pushes the first three steps.)
I and others have not lied or been mistaken in any observations about
what is going on. Everyone agrees that H returned false after certain
steps that were correct up to that point, that the input didn't reach
its return statement while simulated by H, and that there is an
unfinished simulation that can be continued and has been correctly shown
to reach its return statemnt.
Your whole position is that if a simluation does not reach
termination /while being simulated by the decider/ then it
is correct to call it nonterminating.
(If not absolutely then
at least in situations when the input is the diagonal case).
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
On 11/5/2025 11:35 AM, Kaz Kylheku wrote:
So you are saying that no simulating decider could ever be wrong about
its D-like diagonal input case, if it conducts an incomplete (but
otherwise correct) simulation of its input and then returns false for
any reason whatsoever (such as "if the input is taking more than three
steps, it must be nonterminating").
Boy is that an intentionally deceptive and moronically
stupid paraphrase of what I have been saying for years.
On 11/5/2025 11:35 AM, Kaz Kylheku wrote:At least you acknowledge it as a paraphrase :-) But where’s the deception? Isn’t that exactly what you mean? What do you think is being suggested
So you are saying that no simulating decider could ever be wrong aboutBoy is that an intentionally deceptive and moronically stupid paraphrase
its D-like diagonal input case, if it conducts an incomplete (but
otherwise correct) simulation of its input and then returns false for
any reason whatsoever (such as "if the input is taking more than three
steps, it must be nonterminating").
of what I have been saying for years.
You haven’t tested this. Kaz does exactly that and gets a differentAnd you believe that this will get you written into the history booksThis whole aspect of what you have been saying has been refuted. When
as the researcher who showed that the halting problem is all wrong.
You think that math/CS academia will see it from your perspective and
just agree that when H detaches from D, the question of whether the
abandoned simulation is terminating becomes off-limits (like some sort
"inadmissible evidence")?
you resume the simulation from the exact same machine state where H.i ==
3 then you get the same result. When you do it differently then this
then it is not any actual resumption.
I beg you to try this yourself.But at least hopefully you did see that the simulation of D started byOnly when you cheat and do not resume at the exact same machine state
H can be completed, resulting in the same total 11 wsteps as a directly
executed D. (It just cannot all happen while H is running; H obviously
cannot be the sole driver which pushes the simulation to completion,
since it only pushes the first three steps.)
where H.i == 3.
I and others have not lied or been mistaken in any observations aboutBecause the same not reached the "return" statement would occur for an infinite number of simulated steps any case of D reaching its "return" instruction is some sort of cheating by not resuming at the exact same machine state where H rejected D.
what is going on. Everyone agrees that H returned false after certain
steps that were correct up to that point, that the input didn't reach
its return statement while simulated by H, and that there is an
unfinished simulation that can be continued and has been correctly
shown to reach its return statemnt.
Your whole position is that if a simluation does not reach termination
/while being simulated by the decider/ then it is correct to call it
nonterminating.
When H correctly predicts that if it simulated D an infinite number of
steps that its simulated D would never reach its own simulated "return" statement then H is necessarily correct to reject D on the basis of
Semantic Properties of Finite String Inputs (SPoFSI).
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 8:43 PM, Kaz Kylheku 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.
*That is the definition of non-halting input*
Well, anyway, there you go; that's how the "D simulated by H" is the
same halting D as the directly executed one.
You can keep working your same rhetoric on top of that
if you like; that in spite of that, there is some magically
different D that is non-halting.
If halting doesn't happen on H's watch, then the
input is nonhalting, and that is correct.
For instance this:
void Finite_Loop(void)
{
for (i = 0; i < 1000; i++) { }
}
This doesn't finish simulating in H's three interp_step(s) operations. Therefore H(Finite_Loop) returns 0.
That must be correct, right? The 2000 step Finite_Loop, as measured by
H, is nonterminating: it does not reach termination while simulated by
H, exactly like the 11 step D.
Both of them obvious terminate, but ... wait for it .... that's not
the input!!!
Remember, halting deciders only operate on the finite string that is
their actual input, and not on a running process.
Yadda yadda, I've written it for you so you don't have to.
But anyway, I hope it is perfectly clear what is meant by
continuing an abandoned simulation and all that; it has been
shown in close to the simplest possible way possible subject
to C having to be used.
And you believe that this will get you written into the history books as
the researcher who showed that the halting problem is all wrong.
You think that math/CS academia will see it from your perspective and
just agree that when H detaches from D, the question of whether the
abandoned simulation is terminating becomes off-limits (like some sort
"inadmissible evidence")?
This whole aspect of what you have been saying has
been refuted. When you resume the simulation from
the exact same machine state where H.i == 3 then
you get the same result.
When you do it differently
then this then it is not any actual resumption.
Your whole position is that if a simluation does not reach
termination /while being simulated by the decider/ then it
is correct to call it nonterminating.
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement then H is necessarily correct
to reject D on the basis of Semantic Properties of Finite
String Inputs (SPoFSI).
On 2025-11-05, olcott <[email protected]> wrote:
And you believe that this will get you written into the history books as >>> the researcher who showed that the halting problem is all wrong.
You think that math/CS academia will see it from your perspective and
just agree that when H detaches from D, the question of whether the
abandoned simulation is terminating becomes off-limits (like some sort
"inadmissible evidence")?
This whole aspect of what you have been saying has
been refuted. When you resume the simulation from
the exact same machine state where H.i == 3 then
you get the same result.
Same result as what? Who said anything about a same or different
result?
Am Wed, 05 Nov 2025 12:17:06 -0600 schrieb olcott:
On 11/5/2025 11:35 AM, Kaz Kylheku wrote:
At least you acknowledge it as a paraphrase :-) But where’s the deception? Isn’t that exactly what you mean? What do you think is being suggested here?So you are saying that no simulating decider could ever be wrong aboutBoy is that an intentionally deceptive and moronically stupid paraphrase
its D-like diagonal input case, if it conducts an incomplete (but
otherwise correct) simulation of its input and then returns false for
any reason whatsoever (such as "if the input is taking more than three
steps, it must be nonterminating").
of what I have been saying for years.
You haven’t tested this. Kaz does exactly that and gets a differentAnd you believe that this will get you written into the history booksThis whole aspect of what you have been saying has been refuted. When
as the researcher who showed that the halting problem is all wrong.
You think that math/CS academia will see it from your perspective and
just agree that when H detaches from D, the question of whether the
abandoned simulation is terminating becomes off-limits (like some sort
"inadmissible evidence")?
you resume the simulation from the exact same machine state where H.i ==
3 then you get the same result. When you do it differently then this
then it is not any actual resumption.
result.
But at least hopefully you did see that the simulation of D started byOnly when you cheat and do not resume at the exact same machine state
H can be completed, resulting in the same total 11 wsteps as a directly
executed D. (It just cannot all happen while H is running; H obviously
cannot be the sole driver which pushes the simulation to completion,
since it only pushes the first three steps.)
where H.i == 3.
I beg you to try this yourself.
I and others have not lied or been mistaken in any observations aboutBecause the same not reached the "return" statement would occur for an
what is going on. Everyone agrees that H returned false after certain
steps that were correct up to that point, that the input didn't reach
its return statement while simulated by H, and that there is an
unfinished simulation that can be continued and has been correctly
shown to reach its return statemnt.
infinite number of simulated steps any case of D reaching its "return"
instruction is some sort of cheating by not resuming at the exact same
machine state where H rejected D.
Imagine if a processor had your detection logic without aborting, or if
H only logged the matched pattern. What would happen?
Your whole position is that if a simluation does not reach termination
/while being simulated by the decider/ then it is correct to call it
nonterminating.
When H correctly predicts that if it simulated D an infinite number of
steps that its simulated D would never reach its own simulated "return"
statement then H is necessarily correct to reject D on the basis of
Semantic Properties of Finite String Inputs (SPoFSI).
The simulated D does however its return statement because it still
doesn’t call an infinite simulator, even if simulated „infinitely”, better called „non-aborting”. After the return there is nothing left
to simulate.
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
On 2025-11-05, olcott <[email protected]> wrote:
On 11/5/2025 1:01 AM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
*That is the definition of non-halting input*
Well, anyway, there you go; that's how the "D simulated by H" is the
same halting D as the directly executed one.
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
The semantic halting property of the input
to H(D) has been proven to be non-halting.
So you are saying that no simulating decider could ever be wrong about
its D-like diagonal input case,
if it conducts an incomplete (but
otherwise correct) simulation of its input and then returns false for
any reason whatsoever (such as "if the input is taking more than three
steps, it must be nonterminating").
And you believe that this will get you written into the history books as
the researcher who showed that the halting problem is all wrong.
You think that math/CS academia will see it from your perspective and
just agree that when H detaches from D, the question of whether the
abandoned simulation is terminating becomes off-limits (like some sort "inadmissible evidence")?
But at least hopefully you did see that the simulation of D started by H
can be completed, resulting in the same total 11 wsteps as a directly executed D. (It just cannot all happen while H is running; H obviously cannot be the sole driver which pushes the simulation to completion,
since it only pushes the first three steps.)
I and others have not lied or been mistaken in any observations about
what is going on. Everyone agrees that H returned false after certain
steps that were correct up to that point, that the input didn't reach
its return statement while simulated by H, and that there is an
unfinished simulation that can be continued and has been correctly shown
to reach its return statemnt.
Your whole position is that if a simluation does not reach
termination /while being simulated by the decider/ then it
is correct to call it nonterminating. (If not absolutely then
at least in situations when the input is the diagonal case).
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
On 11/5/2025 11:35 AM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
On 11/5/2025 1:01 AM, Kaz Kylheku wrote:
On 2025-11-05, olcott <[email protected]> wrote:
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
*That is the definition of non-halting input*
Well, anyway, there you go; that's how the "D simulated by H" is the
same halting D as the directly executed one.
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
The semantic halting property of the input
to H(D) has been proven to be non-halting.
So you are saying that no simulating decider could ever be wrong about
its D-like diagonal input case,
I am saying that it has always been stupidly
incorrect to require a decider to report on
anything besides what its input specifies.
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
could refer to an algorithm, a C function, or a finite string, and would have different meaning depending on which one.
Clarify the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
could refer to an algorithm, a C function, or a finite string, and
would have different meaning depending on which one.
Clarify the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Liar !!!
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own >>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above
code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
could refer to an algorithm, a C function, or a finite string, and
would have different meaning depending on which one.
Clarify the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about the above code, not the code itself.
You're obviously actively avoiding being clear, proving that you're not interested in an honest dialogue.--
But I'm feeling generous and will assume that you simply have abysmal reading comprehension skills. So to reiterate:
The following sentence is rejected out-of-hand as unclear:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Prove that you're actually interested in an honest dialogue by
clarifying the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above
code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above
sentence could refer to an algorithm, a C function, or a finite
string, and would have different meaning depending on which one.
Clarify the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about the
above code, not the code itself.
Unless you start doing better you will be on the *plonked* list
You're obviously actively avoiding being clear, proving that you're
not interested in an honest dialogue.
But I'm feeling generous and will assume that you simply have abysmal
reading comprehension skills. So to reiterate:
The following sentence is rejected out-of-hand as unclear:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Prove that you're actually interested in an honest dialogue by
clarifying the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above >>>>>>> code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above
sentence could refer to an algorithm, a C function, or a finite
string, and would have different meaning depending on which one.
Clarify the above sentence by prefixing all instances of "H" and
"D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about the
above code, not the code itself.
Unless you start doing better you will be on the *plonked* list
In other words, you don't know how to answer my question without making
your lies obvious.
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above >>>>>>>> code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above
sentence could refer to an algorithm, a C function, or a finite
string, and would have different meaning depending on which one.
Clarify the above sentence by prefixing all instances of "H" and
"D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about the
above code, not the code itself.
Unless you start doing better you will be on the *plonked* list
In other words, you don't know how to answer my question without
making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above >>>>>>>>> code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above
sentence could refer to an algorithm, a C function, or a finite >>>>>>> string, and would have different meaning depending on which one. >>>>>>>
Clarify the above sentence by prefixing all instances of "H" and >>>>>>> "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about the
above code, not the code itself.
Unless you start doing better you will be on the *plonked* list
In other words, you don't know how to answer my question without
making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you. You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing each
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the >>>>>>>>>> above code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above
sentence could refer to an algorithm, a C function, or a finite >>>>>>>> string, and would have different meaning depending on which one. >>>>>>>>
Clarify the above sentence by prefixing all instances of "H" and >>>>>>>> "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about the >>>>>> above code, not the code itself.
Unless you start doing better you will be on the *plonked* list
In other words, you don't know how to answer my question without
making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you. You
refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing each instance of "H" and "D" with exactly one of:
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>>>>>> number of steps that its simulated D would never reach its >>>>>>>>>>>>>> own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the >>>>>>>>>>> above code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above >>>>>>>>> sentence could refer to an algorithm, a C function, or a finite >>>>>>>>> string, and would have different meaning depending on which one. >>>>>>>>>
Clarify the above sentence by prefixing all instances of "H" >>>>>>>>> and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about
the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list
In other words, you don't know how to answer my question without
making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you. You >>> refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
* algorithm
* C function
* finite string
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing each
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>>>>>>> number of steps that its simulated D would never reach >>>>>>>>>>>>>>> its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the >>>>>>>>>>>> above code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above >>>>>>>>>> sentence could refer to an algorithm, a C function, or a
finite string, and would have different meaning depending on >>>>>>>>>> which one.
Clarify the above sentence by prefixing all instances of "H" >>>>>>>>>> and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about >>>>>>>> the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list
In other words, you don't know how to answer my question without
making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you.
You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing each
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:In other words, you don't know how to answer my question without >>>>>>> making your lies obvious.
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an >>>>>>>>>>>>>>>> infinite
number of steps that its simulated D would never reach >>>>>>>>>>>>>>>> its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the >>>>>>>>>>>>> above code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above >>>>>>>>>>> sentence could refer to an algorithm, a C function, or a >>>>>>>>>>> finite string, and would have different meaning depending on >>>>>>>>>>> which one.
Clarify the above sentence by prefixing all instances of "H" >>>>>>>>>>> and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about >>>>>>>>> the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list >>>>>>>
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you.
You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing each
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:In other words, you don't know how to answer my question without >>>>>>> making your lies obvious.
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an >>>>>>>>>>>>>>>> infinite
number of steps that its simulated D would never reach >>>>>>>>>>>>>>>> its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the >>>>>>>>>>>>> above code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above >>>>>>>>>>> sentence could refer to an algorithm, a C function, or a >>>>>>>>>>> finite string, and would have different meaning depending on >>>>>>>>>>> which one.
Clarify the above sentence by prefixing all instances of "H" >>>>>>>>>>> and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about >>>>>>>>> the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list >>>>>>>
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you.
You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing each
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:In other words, you don't know how to answer my question without >>>>>>>> making your lies obvious.
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an >>>>>>>>>>>>>>>>> infinite
number of steps that its simulated D would never reach >>>>>>>>>>>>>>>>> its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the >>>>>>>>>>>>>> above code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the above >>>>>>>>>>>> sentence could refer to an algorithm, a C function, or a >>>>>>>>>>>> finite string, and would have different meaning depending on >>>>>>>>>>>> which one.
Clarify the above sentence by prefixing all instances of "H" >>>>>>>>>>>> and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence about >>>>>>>>>> the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list >>>>>>>>
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you. >>>>>> You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing each >>>>> instance of "H" and "D" with exactly one of:
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:In other words, you don't know how to answer my question
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an >>>>>>>>>>>>>>>>>> infinite
number of steps that its simulated D would never reach >>>>>>>>>>>>>>>>>> its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the >>>>>>>>>>>>>>> above code which is not the code it was given.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the >>>>>>>>>>>>> above sentence could refer to an algorithm, a C function, >>>>>>>>>>>>> or a finite string, and would have different meaning >>>>>>>>>>>>> depending on which one.
Clarify the above sentence by prefixing all instances of >>>>>>>>>>>>> "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence >>>>>>>>>>> about the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list >>>>>>>>>
without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you. >>>>>>> You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above sentence with exactly one of:
* algorithm
* C function
* finite string
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:In other words, you don't know how to answer my question
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:Its only 50% nonsense which is better than
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an >>>>>>>>>>>>>>>>>>> infinite
number of steps that its simulated D would never >>>>>>>>>>>>>>>>>>> reach its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on >>>>>>>>>>>>>>>> the above code which is not the code it was given. >>>>>>>>>>>>>>>
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the >>>>>>>>>>>>>> above sentence could refer to an algorithm, a C function, >>>>>>>>>>>>>> or a finite string, and would have different meaning >>>>>>>>>>>>>> depending on which one.
Clarify the above sentence by prefixing all instances of >>>>>>>>>>>>>> "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence >>>>>>>>>>>> about the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list >>>>>>>>>>
without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is you. >>>>>>>> You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of: >>>>>>>> * algorithm
* C function
* finite string
I completely addressed every single detail
of this
each instance of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above sentence with
exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own
simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
People (not LLMs) are so sure that I
must be wrong that they find it impossible
to see when I have actually proved my point.
LLMs give me lots of pushback that I address.
Then they revise their views. People can't do
that.
They start with the idea that I am wrong
and nothing can ever change this view.
Their whole foundation is Olcott is wrong.
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing >>>>>>> each instance of "H" and "D" with exactly one of:
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:In other words, you don't know how to answer my question >>>>>>>>>>> without making your lies obvious.
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:Its only 50% nonsense which is better than
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an >>>>>>>>>>>>>>>>>>>> infinite
number of steps that its simulated D would never >>>>>>>>>>>>>>>>>>>> reach its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on >>>>>>>>>>>>>>>>> the above code which is not the code it was given. >>>>>>>>>>>>>>>>
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the >>>>>>>>>>>>>>> above sentence could refer to an algorithm, a C function, >>>>>>>>>>>>>>> or a finite string, and would have different meaning >>>>>>>>>>>>>>> depending on which one.
Clarify the above sentence by prefixing all instances of >>>>>>>>>>>>>>> "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence >>>>>>>>>>>>> about the above code, not the code itself.
Unless you start doing better you will be on the *plonked* list >>>>>>>>>>>
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is >>>>>>>>> you. You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>> * algorithm
* C function
* finite string
I completely addressed every single detail
of this
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above sentence
with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you can nail
that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of an
ASCII string of C source code, since the function call H(D) is given a function pointer, and function pointers don't contain an ASCII string of
C source code.
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:
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite
number of steps that its simulated D would never reach its own >>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code >>>>> which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
People (not LLMs) are so sure that I
must be wrong that they find it impossible
to see when I have actually proved my point.
If you think you've proven your point, but nobody here sees it,
then maybe you need to take it somewhere else, like the
next step --- establishing some academic contacts wwith a view
toward publishing.
Time is ticking away. You are on a trajectory of pissing it all away in Usenet arguments, rather than on the trajectory of publishing and
becoming famous for dismantling the halting problem.
LLMs give me lots of pushback that I address.
Then they revise their views. People can't do
that.
Language models do not have "views". They have context windows full of
input tokens, and a trained network full of weights for predicting
output tokens.
They start with the idea that I am wrong
and nothing can ever change this view.
Their whole foundation is Olcott is wrong.
You are ignoring all the times someone has agreed with
you on some point.
You can't expect smart, informed people to agree with
you when you are wrong.
Repeating the wrong point may work with token-predicting slot machines;
it won't work with informed, thinking people.
People are much better at recognizing that you are rephrasing the same
thing in slightly different ways.
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing >>>>>>>> each instance of "H" and "D" with exactly one of:
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:Its only 50% nonsense which is better than
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an >>>>>>>>>>>>>>>>>>>>> infinite
number of steps that its simulated D would never >>>>>>>>>>>>>>>>>>>>> reach its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on >>>>>>>>>>>>>>>>>> the above code which is not the code it was given. >>>>>>>>>>>>>>>>>
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the >>>>>>>>>>>>>>>> above sentence could refer to an algorithm, a C >>>>>>>>>>>>>>>> function, or a finite string, and would have different >>>>>>>>>>>>>>>> meaning depending on which one.
Clarify the above sentence by prefixing all instances of >>>>>>>>>>>>>>>> "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence >>>>>>>>>>>>>> about the above code, not the code itself.
Unless you start doing better you will be on the *plonked* >>>>>>>>>>>>> list
In other words, you don't know how to answer my question >>>>>>>>>>>> without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is >>>>>>>>>> you. You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>> * algorithm
* C function
* finite string
I completely addressed every single detail
of this
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above sentence
with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you can nail
that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of an
ASCII string of C source code, since the function call H(D) is given a
function pointer, and function pointers don't contain an ASCII string
of C source code.
Kaz provided the most apt something or other.
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
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:
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code >>>>>> which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
People (not LLMs) are so sure that I
must be wrong that they find it impossible
to see when I have actually proved my point.
If you think you've proven your point, but nobody here sees it,
then maybe you need to take it somewhere else, like the
next step --- establishing some academic contacts wwith a view
toward publishing.
It took me three years to get anyone to agree to
the dead obvious truth that D simulated by H
cannot possibly reach its own simulated "return"
statement final halt state because all people
here make disagreement their highest priority.
If we could switch to an actual honest dialogue
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
On 11/5/2025 12:55 PM, joes wrote:The data of the D it was simulating is still around.
Am Wed, 05 Nov 2025 12:17:06 -0600 schrieb olcott:
On 11/5/2025 11:35 AM, Kaz Kylheku wrote:
So you are saying that no simulating decider could ever be wrong
about its D-like diagonal input case, if it conducts an incomplete
(but otherwise correct) simulation of its input and then returns
false for any reason whatsoever (such as "if the input is taking more
than three steps, it must be nonterminating").
We can see by his code that as soon as H.i == 3 H returns false.
D will halt!Imagine if a processor had your detection logic without aborting, or if
H only logged the matched pattern. What would happen?
*reachThe simulated D does however* its return statement because it still
doesn’t call an infinite simulator, even if simulated „infinitely”,
better called „non-aborting”. After the return there is nothing left to >> simulate.
This just seem to be evidence that you are clueless about programming.What’s wrong about it?
Am Wed, 05 Nov 2025 19:23:01 -0600 schrieb olcott:
On 11/5/2025 12:55 PM, joes wrote:
Am Wed, 05 Nov 2025 12:17:06 -0600 schrieb olcott:
On 11/5/2025 11:35 AM, Kaz Kylheku wrote:
So you are saying that no simulating decider could ever be wrong
about its D-like diagonal input case, if it conducts an incomplete
(but otherwise correct) simulation of its input and then returns
false for any reason whatsoever (such as "if the input is taking more >>>>> than three steps, it must be nonterminating").
We can see by his code that as soon as H.i == 3 H returns false.The data of the D it was simulating is still around.
D will halt!Imagine if a processor had your detection logic without aborting, or if
H only logged the matched pattern. What would happen?
*reachThe simulated D does however* its return statement because it still
doesn’t call an infinite simulator, even if simulated „infinitely”, >>> better called „non-aborting”. After the return there is nothing left to >>> simulate.
This just seem to be evidence that you are clueless about programming.What’s wrong about it?
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/6/2025 12:00 AM, olcott wrote:
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing >>>>>>>>> each instance of "H" and "D" with exactly one of:
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:Its only 50% nonsense which is better than >>>>>>>>>>>>>>>>>> Chris ever did. Flibble used to say things >>>>>>>>>>>>>>>>>> that made good sense.
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>
When H correctly predicts that if it simulated D >>>>>>>>>>>>>>>>>>>>>> an infinite
number of steps that its simulated D would never >>>>>>>>>>>>>>>>>>>>>> reach its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on >>>>>>>>>>>>>>>>>>> the above code which is not the code it was given. >>>>>>>>>>>>>>>>>>
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the >>>>>>>>>>>>>>>>> above sentence could refer to an algorithm, a C >>>>>>>>>>>>>>>>> function, or a finite string, and would have different >>>>>>>>>>>>>>>>> meaning depending on which one.
Clarify the above sentence by prefixing all instances >>>>>>>>>>>>>>>>> of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence >>>>>>>>>>>>>>> about the above code, not the code itself.
Unless you start doing better you will be on the *plonked* >>>>>>>>>>>>>> list
In other words, you don't know how to answer my question >>>>>>>>>>>>> without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is >>>>>>>>>>> you. You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>> * algorithm
* C function
* finite string
I completely addressed every single detail
of this
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above sentence
with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you can
nail that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of an
ASCII string of C source code, since the function call H(D) is given
a function pointer, and function pointers don't contain an ASCII
string of C source code.
Kaz provided the most apt something or other.
The H provided by Kaz doesn't take an ASCII string of C code as input.
It accepts a function pointer.
Would you then accept that the finite string input to H is a 32-bit (in
your implementation) function pointer, and in particular that the finite string D is a specific 32-bit value which is the starting address of function D?
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
;
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:
;
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
On 11/6/2025 12:12 AM, olcott wrote:
On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code >>>>>>> which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
People (not LLMs) are so sure that I
must be wrong that they find it impossible
to see when I have actually proved my point.
If you think you've proven your point, but nobody here sees it,
then maybe you need to take it somewhere else, like the
next step --- establishing some academic contacts wwith a view
toward publishing.
It took me three years to get anyone to agree to
the dead obvious truth that D simulated by H
cannot possibly reach its own simulated "return"
statement final halt state because all people
here make disagreement their highest priority.
If we could switch to an actual honest dialogue
Then you would clarify this sentence:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
By prefixing all instances of "D" and "H" in the above sentence with
exactly one of:
* algorithm
* C function
* finite string
On 11/6/2025 6:51 AM, dbush wrote:
On 11/6/2025 12:00 AM, olcott wrote:
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by prefixing >>>>>>>>>> each instance of "H" and "D" with exactly one of:
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:Its only 50% nonsense which is better than >>>>>>>>>>>>>>>>>>> Chris ever did. Flibble used to say things >>>>>>>>>>>>>>>>>>> that made good sense.
On 11/5/2025 12:43 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>
When H correctly predicts that if it simulated D >>>>>>>>>>>>>>>>>>>>>>> an infinite
number of steps that its simulated D would never >>>>>>>>>>>>>>>>>>>>>>> reach its own
simulated "return" statement
In other words, H reports on the following non-input: >>>>>>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting >>>>>>>>>>>>>>>>>>>> on the above code which is not the code it was given. >>>>>>>>>>>>>>>>>>>
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in the >>>>>>>>>>>>>>>>>> above sentence could refer to an algorithm, a C >>>>>>>>>>>>>>>>>> function, or a finite string, and would have different >>>>>>>>>>>>>>>>>> meaning depending on which one.
Clarify the above sentence by prefixing all instances >>>>>>>>>>>>>>>>>> of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your sentence >>>>>>>>>>>>>>>> about the above code, not the code itself.
Unless you start doing better you will be on the >>>>>>>>>>>>>>> *plonked* list
In other words, you don't know how to answer my question >>>>>>>>>>>>>> without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is >>>>>>>>>>>> you. You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>>> * algorithm
* C function
* finite string
I completely addressed every single detail
of this
* algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above sentence >>>>>> with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you can
nail that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of an
ASCII string of C source code, since the function call H(D) is given
a function pointer, and function pointers don't contain an ASCII
string of C source code.
Kaz provided the most apt something or other.
The H provided by Kaz doesn't take an ASCII string of C code as input.
It accepts a function pointer.
Would you then accept that the finite string input to H is a 32-bit
(in your implementation) function pointer, and in particular that the
finite string D is a specific 32-bit value which is the starting
address of function D?
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
;
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:
;
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
How many years of C programming do you
have. Failing to answer will result in
me believing that you have less than five
minutes of C programming.
On 11/6/2025 10:16 AM, olcott wrote:
On 11/6/2025 6:51 AM, dbush wrote:
On 11/6/2025 12:00 AM, olcott wrote:
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>Its only 50% nonsense which is better than >>>>>>>>>>>>>>>>>>>> Chris ever did. Flibble used to say things >>>>>>>>>>>>>>>>>>>> that made good sense.
When H correctly predicts that if it simulated D >>>>>>>>>>>>>>>>>>>>>>>> an infinite
number of steps that its simulated D would never >>>>>>>>>>>>>>>>>>>>>>>> reach its own
simulated "return" statement
In other words, H reports on the following non- >>>>>>>>>>>>>>>>>>>>>>> input:
int D()
{
int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet. >>>>>>>>>>>>>>>>>>>>>> Very rarely you do say some things >>>>>>>>>>>>>>>>>>>>>> that are not nonsense.
And it is clearly not nonsense that H is reporting >>>>>>>>>>>>>>>>>>>>> on the above code which is not the code it was given. >>>>>>>>>>>>>>>>>>>>
H correctly predicts the D simulated by >>>>>>>>>>>>>>>>>>>> H cannot possibly reach its own final
halt state.
Rejected out-of-hand as unclear, as "D" and "H" in >>>>>>>>>>>>>>>>>>> the above sentence could refer to an algorithm, a C >>>>>>>>>>>>>>>>>>> function, or a finite string, and would have >>>>>>>>>>>>>>>>>>> different meaning depending on which one. >>>>>>>>>>>>>>>>>>>
Clarify the above sentence by prefixing all instances >>>>>>>>>>>>>>>>>>> of "H" and "D" with exactly one of:
* algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D);
; if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your >>>>>>>>>>>>>>>>> sentence about the above code, not the code itself. >>>>>>>>>>>>>>>>>
Unless you start doing better you will be on the >>>>>>>>>>>>>>>> *plonked* list
In other words, you don't know how to answer my question >>>>>>>>>>>>>>> without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup is >>>>>>>>>>>>> you. You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>>>> * algorithm
* C function
* finite string
I completely addressed every single detail
of this
prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>> * algorithm
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above sentence >>>>>>> with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you can
nail that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of an >>>>> ASCII string of C source code, since the function call H(D) is
given a function pointer, and function pointers don't contain an
ASCII string of C source code.
Kaz provided the most apt something or other.
The H provided by Kaz doesn't take an ASCII string of C code as
input. It accepts a function pointer.
Would you then accept that the finite string input to H is a 32-bit
(in your implementation) function pointer, and in particular that the
finite string D is a specific 32-bit value which is the starting
address of function D?
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
;
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:
;
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
How many years of C programming do you
have. Failing to answer will result in
me believing that you have less than five
minutes of C programming.
Dishonest dodge, and I don't care what you believe.
Would you then accept that the finite string input to H is a 32-bit (in
your implementation) function pointer, and in particular that the finite string D is a specific 32-bit value which is the starting address of function D?--
On 11/6/2025 9:22 AM, dbush wrote:
On 11/6/2025 10:16 AM, olcott wrote:
On 11/6/2025 6:51 AM, dbush wrote:
On 11/6/2025 12:00 AM, olcott wrote:
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by >>>>>>>>>>>> prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>>> * algorithm
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>Its only 50% nonsense which is better than >>>>>>>>>>>>>>>>>>>>> Chris ever did. Flibble used to say things >>>>>>>>>>>>>>>>>>>>> that made good sense.
When H correctly predicts that if it simulated >>>>>>>>>>>>>>>>>>>>>>>>> D an infinite
number of steps that its simulated D would >>>>>>>>>>>>>>>>>>>>>>>>> never reach its own
simulated "return" statement
In other words, H reports on the following non- >>>>>>>>>>>>>>>>>>>>>>>> input:
int D()
{
int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet. >>>>>>>>>>>>>>>>>>>>>>> Very rarely you do say some things >>>>>>>>>>>>>>>>>>>>>>> that are not nonsense.
And it is clearly not nonsense that H is reporting >>>>>>>>>>>>>>>>>>>>>> on the above code which is not the code it was given. >>>>>>>>>>>>>>>>>>>>>
H correctly predicts the D simulated by >>>>>>>>>>>>>>>>>>>>> H cannot possibly reach its own final >>>>>>>>>>>>>>>>>>>>> halt state.
Rejected out-of-hand as unclear, as "D" and "H" in >>>>>>>>>>>>>>>>>>>> the above sentence could refer to an algorithm, a C >>>>>>>>>>>>>>>>>>>> function, or a finite string, and would have >>>>>>>>>>>>>>>>>>>> different meaning depending on which one. >>>>>>>>>>>>>>>>>>>>
Clarify the above sentence by prefixing all >>>>>>>>>>>>>>>>>>>> instances of "H" and "D" with exactly one of: >>>>>>>>>>>>>>>>>>>> * algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>> >>>>> if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your >>>>>>>>>>>>>>>>>> sentence about the above code, not the code itself. >>>>>>>>>>>>>>>>>>
Unless you start doing better you will be on the >>>>>>>>>>>>>>>>> *plonked* list
In other words, you don't know how to answer my question >>>>>>>>>>>>>>>> without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup >>>>>>>>>>>>>> is you. You refuse to clarify this sentence:
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly one >>>>>>>>>>>>>> of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above
sentence with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you can >>>>>> nail that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of
an ASCII string of C source code, since the function call H(D) is >>>>>> given a function pointer, and function pointers don't contain an
ASCII string of C source code.
Kaz provided the most apt something or other.
The H provided by Kaz doesn't take an ASCII string of C code as
input. It accepts a function pointer.
Would you then accept that the finite string input to H is a 32-bit
(in your implementation) function pointer, and in particular that
the finite string D is a specific 32-bit value which is the starting
address of function D?
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
;
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:
;
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
How many years of C programming do you
have. Failing to answer will result in
me believing that you have less than five
minutes of C programming.
Dishonest dodge, and I don't care what you believe.
I have been programing in N since K & R was the standard.
Would you then accept that the finite string input to H is a 32-bit (in
No mine will work with ASCII text.
If you know C well enough I could
avoid wasting a week f programming.
Its dead obvious to any C programmer
that D simulated by H cannot possibly
reach its own "return" statement so you
must be clueless about C.
your implementation) function pointer, and in particular that the
finite string D is a specific 32-bit value which is the starting
address of function D?
On 11/6/2025 6:54 AM, dbush wrote:
On 11/6/2025 12:12 AM, olcott wrote:
On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
� ��� int Halt_Status = UTM(D);
� ��� if (Halt_Status)
� ����� HERE: goto HERE;
� ��� return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above code >>>>>>>> which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
People (not LLMs) are so sure that I
must be wrong that they find it impossible
to see when I have actually proved my point.
If you think you've proven your point, but nobody here sees it,
then maybe you need to take it somewhere else, like the
next step --- establishing some academic contacts wwith a view
toward publishing.
It took me three years to get anyone to agree to
the dead obvious truth that D simulated by H
cannot possibly reach its own simulated "return"
statement final halt state because all people
here make disagreement their highest priority.
If we could switch to an actual honest dialogue
Then you would clarify this sentence:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Call it a C interpreter. I will see if I can write one.
By prefixing all instances of "D" and "H" in the above sentence with exactly one of:
* algorithm
* C function
* finite string
On 11/6/2025 11:08 AM, olcott wrote:
On 11/6/2025 9:22 AM, dbush wrote:
On 11/6/2025 10:16 AM, olcott wrote:
On 11/6/2025 6:51 AM, dbush wrote:
On 11/6/2025 12:00 AM, olcott wrote:
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by >>>>>>>>>>>>> prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>>>> * algorithm
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 7:39 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 8:24 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>
When H correctly predicts that if it simulated >>>>>>>>>>>>>>>>>>>>>>>>>> D an infiniteIn other words, H reports on the following non- >>>>>>>>>>>>>>>>>>>>>>>>> input:
number of steps that its simulated D would >>>>>>>>>>>>>>>>>>>>>>>>>> never reach its own
simulated "return" statement >>>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet. >>>>>>>>>>>>>>>>>>>>>>>> Very rarely you do say some things >>>>>>>>>>>>>>>>>>>>>>>> that are not nonsense.
And it is clearly not nonsense that H is >>>>>>>>>>>>>>>>>>>>>>> reporting on the above code which is not the code >>>>>>>>>>>>>>>>>>>>>>> it was given.
Its only 50% nonsense which is better than >>>>>>>>>>>>>>>>>>>>>> Chris ever did. Flibble used to say things >>>>>>>>>>>>>>>>>>>>>> that made good sense.
H correctly predicts the D simulated by >>>>>>>>>>>>>>>>>>>>>> H cannot possibly reach its own final >>>>>>>>>>>>>>>>>>>>>> halt state.
Rejected out-of-hand as unclear, as "D" and "H" in >>>>>>>>>>>>>>>>>>>>> the above sentence could refer to an algorithm, a C >>>>>>>>>>>>>>>>>>>>> function, or a finite string, and would have >>>>>>>>>>>>>>>>>>>>> different meaning depending on which one. >>>>>>>>>>>>>>>>>>>>>
Clarify the above sentence by prefixing all >>>>>>>>>>>>>>>>>>>>> instances of "H" and "D" with exactly one of: >>>>>>>>>>>>>>>>>>>>> * algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>> >>>>> if (Halt_Status)
; HERE: goto HERE;
; return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your >>>>>>>>>>>>>>>>>>> sentence about the above code, not the code itself. >>>>>>>>>>>>>>>>>>>
Unless you start doing better you will be on the >>>>>>>>>>>>>>>>>> *plonked* list
In other words, you don't know how to answer my >>>>>>>>>>>>>>>>> question without making your lies obvious.
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup >>>>>>>>>>>>>>> is you. You refuse to clarify this sentence:
H correctly predicts the D simulated by >>>>>>>>>>>>>>> >>>>>>> H cannot possibly reach its own final
halt state.
By prefixing each instance of "H" and "D" with exactly >>>>>>>>>>>>>>> one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above
sentence with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you can >>>>>>> nail that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of >>>>>>> an ASCII string of C source code, since the function call H(D) is >>>>>>> given a function pointer, and function pointers don't contain an >>>>>>> ASCII string of C source code.
Kaz provided the most apt something or other.
The H provided by Kaz doesn't take an ASCII string of C code as
input. It accepts a function pointer.
Would you then accept that the finite string input to H is a 32-bit >>>>> (in your implementation) function pointer, and in particular that
the finite string D is a specific 32-bit value which is the
starting address of function D?
news://news.eternal-september.org/[email protected]
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
;
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:
;
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
How many years of C programming do you
have. Failing to answer will result in
me believing that you have less than five
minutes of C programming.
Dishonest dodge, and I don't care what you believe.
I have been programing in N since K & R was the standard.
Would you then accept that the finite string input to H is a 32-bit (in
No mine will work with ASCII text.
If you know C well enough I could
avoid wasting a week f programming.
If you knew C well enough you would know that functions pointers don't consist of the ASCII source code of the C function in question
Its dead obvious to any C programmer
that D simulated by H cannot possibly
reach its own "return" statement so you
must be clueless about C.
Rejected out-of-hand as unclear.
This can be fixed by prefixing all > instances of "D" and "H" in theabove sentence with exactly one of:
* algorithm
* C function
* finite string
your implementation) function pointer, and in particular that the
finite string D is a specific 32-bit value which is the starting
address of function D?
On 11/6/2025 10:26 AM, dbush wrote:
On 11/6/2025 11:08 AM, olcott wrote:
On 11/6/2025 9:22 AM, dbush wrote:
On 11/6/2025 10:16 AM, olcott wrote:
On 11/6/2025 6:51 AM, dbush wrote:
On 11/6/2025 12:00 AM, olcott wrote:
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by >>>>>>>>>>>>>> prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>>>>> * algorithm
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote:
On 11/5/2025 8:08 PM, dbush wrote:
On 11/5/2025 8:54 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 7:39 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 8:24 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>
When H correctly predicts that if it >>>>>>>>>>>>>>>>>>>>>>>>>>> simulated D an infiniteIn other words, H reports on the following >>>>>>>>>>>>>>>>>>>>>>>>>> non- input:
number of steps that its simulated D would >>>>>>>>>>>>>>>>>>>>>>>>>>> never reach its own
simulated "return" statement >>>>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>> }
I am not going to *plonk* you yet. >>>>>>>>>>>>>>>>>>>>>>>>> Very rarely you do say some things >>>>>>>>>>>>>>>>>>>>>>>>> that are not nonsense.
And it is clearly not nonsense that H is >>>>>>>>>>>>>>>>>>>>>>>> reporting on the above code which is not the >>>>>>>>>>>>>>>>>>>>>>>> code it was given.
Its only 50% nonsense which is better than >>>>>>>>>>>>>>>>>>>>>>> Chris ever did. Flibble used to say things >>>>>>>>>>>>>>>>>>>>>>> that made good sense.
H correctly predicts the D simulated by >>>>>>>>>>>>>>>>>>>>>>> H cannot possibly reach its own final >>>>>>>>>>>>>>>>>>>>>>> halt state.
Rejected out-of-hand as unclear, as "D" and "H" in >>>>>>>>>>>>>>>>>>>>>> the above sentence could refer to an algorithm, a >>>>>>>>>>>>>>>>>>>>>> C function, or a finite string, and would have >>>>>>>>>>>>>>>>>>>>>> different meaning depending on which one. >>>>>>>>>>>>>>>>>>>>>>
Clarify the above sentence by prefixing all >>>>>>>>>>>>>>>>>>>>>> instances of "H" and "D" with exactly one of: >>>>>>>>>>>>>>>>>>>>>> * algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>>> >>>>> if (Halt_Status)
; HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>> >>>>> return Halt_Status;
}
Liar !!!
I clearly stated that the problem was with your >>>>>>>>>>>>>>>>>>>> sentence about the above code, not the code itself. >>>>>>>>>>>>>>>>>>>>
Unless you start doing better you will be on the >>>>>>>>>>>>>>>>>>> *plonked* list
In other words, you don't know how to answer my >>>>>>>>>>>>>>>>>> question without making your lies obvious. >>>>>>>>>>>>>>>>>>
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this newsgroup >>>>>>>>>>>>>>>> is you. You refuse to clarify this sentence:
H correctly predicts the D simulated by >>>>>>>>>>>>>>>> >>>>>>> H cannot possibly reach its own final >>>>>>>>>>>>>>>> >>>>>>> halt state.
By prefixing each instance of "H" and "D" with exactly >>>>>>>>>>>>>>>> one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above
sentence with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you >>>>>>>> can nail that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting of >>>>>>>> an ASCII string of C source code, since the function call H(D) >>>>>>>> is given a function pointer, and function pointers don't contain >>>>>>>> an ASCII string of C source code.
Kaz provided the most apt something or other.
The H provided by Kaz doesn't take an ASCII string of C code as
input. It accepts a function pointer.
Would you then accept that the finite string input to H is a 32-
bit (in your implementation) function pointer, and in particular
that the finite string D is a specific 32-bit value which is the
starting address of function D?
news://news.eternal-september.org/[email protected] >>>>>>>
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
;
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:
;
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
How many years of C programming do you
have. Failing to answer will result in
me believing that you have less than five
minutes of C programming.
Dishonest dodge, and I don't care what you believe.
I have been programing in N since K & R was the standard.
Would you then accept that the finite string input to H is a 32-bit (in >>>No mine will work with ASCII text.
If you know C well enough I could
avoid wasting a week f programming.
If you knew C well enough you would know that functions pointers don't
consist of the ASCII source code of the C function in question
I would not use a function pointer in my implementation.
If necessary I would parse the source file myself and
present it to the interpreter as the interpreter needs
to see it as an ASCII text string.
Its dead obvious to any C programmer
that D simulated by H cannot possibly
reach its own "return" statement so you
must be clueless about C.
Rejected out-of-hand as unclear.
To anyone that is clueless about C.
It is always going to be the same ASCII
text of a C function:D
Go ahead an interpret that as a bucket of
paint if you want to.
This can be fixed by prefixing all > instances of "D" and "H" in theabove sentence with exactly one of:
* algorithm
* C function
* finite string
your implementation) function pointer, and in particular that the
finite string D is a specific 32-bit value which is the starting
address of function D?
On 06/11/2025 15:19, olcott wrote:
On 11/6/2025 6:54 AM, dbush wrote:
On 11/6/2025 12:12 AM, olcott wrote:
On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/5/2025 7:39 PM, dbush wrote:
On 11/5/2025 8:24 PM, olcott wrote:
On 11/5/2025 12:43 PM, dbush wrote:
On 11/5/2025 1:17 PM, olcott wrote:
When H correctly predicts that if it simulated D an infinite >>>>>>>>>>>> number of steps that its simulated D would never reach its own >>>>>>>>>>>> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
And it is clearly not nonsense that H is reporting on the above >>>>>>>>> code
which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
People (not LLMs) are so sure that I
must be wrong that they find it impossible
to see when I have actually proved my point.
If you think you've proven your point, but nobody here sees it,
then maybe you need to take it somewhere else, like the
next step --- establishing some academic contacts wwith a view
toward publishing.
It took me three years to get anyone to agree to
the dead obvious truth that D simulated by H
cannot possibly reach its own simulated "return"
statement final halt state because all people
here make disagreement their highest priority.
If we could switch to an actual honest dialogue
Then you would clarify this sentence:
H correctly predicts the finite string D simulated by
H cannot possibly reach its own final
halt state.
Call it a C interpreter. I will see if I can write one.
If you like doing that kind of thing, go ahead. You should spend your
time on stuff you enjoy doing.
As long as you're not thinking that such an interpreter will help you in making your arguments about HP! If that is your reason, you are
deluding yourself yet again. [Remember what people said before you
wrote your acyclic graph notation parser (I can't remember what you
called it) and before you wrote x86utm. They pointed out that those efforts would not aid you in making arguments you were proposing at the time, and they were right!]
Mike.
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.
--By prefixing all instances of "D" and "H" in the above sentence with
exactly one of:
* algorithm
* C function
* finite string
On 11/6/2025 11:49 AM, olcott wrote:
On 11/6/2025 10:26 AM, dbush wrote:
On 11/6/2025 11:08 AM, olcott wrote:
On 11/6/2025 9:22 AM, dbush wrote:
On 11/6/2025 10:16 AM, olcott wrote:
On 11/6/2025 6:51 AM, dbush wrote:
On 11/6/2025 12:00 AM, olcott wrote:
On 11/5/2025 10:25 PM, dbush wrote:
On 11/5/2025 11:15 PM, olcott wrote:
On 11/5/2025 10:04 PM, dbush wrote:
On 11/5/2025 10:57 PM, olcott wrote:
On 11/5/2025 9:53 PM, dbush wrote:
On 11/5/2025 10:50 PM, olcott wrote:
On 11/5/2025 9:39 PM, dbush wrote:
On 11/5/2025 10:38 PM, olcott wrote:
On 11/5/2025 9:32 PM, dbush wrote:False. You have not corrected the above sentence by >>>>>>>>>>>>>>> prefixing each instance of "H" and "D" with exactly one of: >>>>>>>>>>>>>>> * algorithm
On 11/5/2025 10:27 PM, olcott wrote:
On 11/5/2025 9:18 PM, dbush wrote:
On 11/5/2025 10:15 PM, olcott wrote:
On 11/5/2025 9:05 PM, dbush wrote:
On 11/5/2025 9:24 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 8:08 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 8:54 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 7:39 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 8:24 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
When H correctly predicts that if it >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated D an infinite >>>>>>>>>>>>>>>>>>>>>>>>>>>> number of steps that its simulated D would >>>>>>>>>>>>>>>>>>>>>>>>>>>> never reach its ownIn other words, H reports on the following >>>>>>>>>>>>>>>>>>>>>>>>>>> non- input:
simulated "return" statement >>>>>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>> }
I am not going to *plonk* you yet. >>>>>>>>>>>>>>>>>>>>>>>>>> Very rarely you do say some things >>>>>>>>>>>>>>>>>>>>>>>>>> that are not nonsense.
And it is clearly not nonsense that H is >>>>>>>>>>>>>>>>>>>>>>>>> reporting on the above code which is not the >>>>>>>>>>>>>>>>>>>>>>>>> code it was given.
Its only 50% nonsense which is better than >>>>>>>>>>>>>>>>>>>>>>>> Chris ever did. Flibble used to say things >>>>>>>>>>>>>>>>>>>>>>>> that made good sense.
H correctly predicts the D simulated by >>>>>>>>>>>>>>>>>>>>>>>> H cannot possibly reach its own final >>>>>>>>>>>>>>>>>>>>>>>> halt state.
Rejected out-of-hand as unclear, as "D" and "H" >>>>>>>>>>>>>>>>>>>>>>> in the above sentence could refer to an >>>>>>>>>>>>>>>>>>>>>>> algorithm, a C function, or a finite string, and >>>>>>>>>>>>>>>>>>>>>>> would have different meaning depending on which one. >>>>>>>>>>>>>>>>>>>>>>>
Clarify the above sentence by prefixing all >>>>>>>>>>>>>>>>>>>>>>> instances of "H" and "D" with exactly one of: >>>>>>>>>>>>>>>>>>>>>>> * algorithm
* C function
* finite string
int D()
{
; int Halt_Status = UTM(D); >>>>>>>>>>>>>>>>>>>>>> >>>>> if (Halt_Status)
; HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>> >>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>> >>>>> }
Liar !!!
I clearly stated that the problem was with your >>>>>>>>>>>>>>>>>>>>> sentence about the above code, not the code itself. >>>>>>>>>>>>>>>>>>>>>
Unless you start doing better you will be on the >>>>>>>>>>>>>>>>>>>> *plonked* list
In other words, you don't know how to answer my >>>>>>>>>>>>>>>>>>> question without making your lies obvious. >>>>>>>>>>>>>>>>>>>
Not at all. your whole basis for rebuttal
is dishonestly twisting my words then
rebutting the dishonest twist.
Projection. The only dishonest person in this >>>>>>>>>>>>>>>>> newsgroup is you. You refuse to clarify this sentence: >>>>>>>>>>>>>>>>>
H correctly predicts the D simulated by >>>>>>>>>>>>>>>>> >>>>>>> H cannot possibly reach its own final >>>>>>>>>>>>>>>>> >>>>>>> halt state.
By prefixing each instance of "H" and "D" with exactly >>>>>>>>>>>>>>>>> one of:
* algorithm
* C function
* finite string
I completely addressed every single detail
of this
* C function
* finite string
You are only a damned liar that may
actually eventually be condemned to
actual Hell (if such a place exists)
unless you repent.
All you're doing is proving the old saying:
Clarity is crank kryptonite.
D is self-evidently a finite string that encodes
a C function in ASCII text.
So we've made a partial clarification:
H correctly predicts the finite string D simulated by >>>>>>>>>>> > H cannot possibly reach its own final
halt state.
Now you need to prefix each instance of "H" in the above >>>>>>>>>>> sentence with exactly one of:
* algorithm
* C function
* finite string
H only need be something or other**
Then your claim is dismissed out-of-hand as unclear until you >>>>>>>>> can nail that down.
that
correctly simulates a finite number of
steps of the above D according to the
semantics of the C language
Then that conflicts with "D" being a finite string consisting >>>>>>>>> of an ASCII string of C source code, since the function call >>>>>>>>> H(D) is given a function pointer, and function pointers don't >>>>>>>>> contain an ASCII string of C source code.
Kaz provided the most apt something or other.
The H provided by Kaz doesn't take an ASCII string of C code as >>>>>>> input. It accepts a function pointer.
Would you then accept that the finite string input to H is a 32- >>>>>>> bit (in your implementation) function pointer, and in particular >>>>>>> that the finite string D is a specific 32-bit value which is the >>>>>>> starting address of function D?
news://news.eternal-september.org/[email protected] >>>>>>>>
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
;
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:
;
until it matches
the recursive simulation behavior pattern
that proves it is impossible for D simulated
by H to reach its own simulated "return"
statement.
** Including a human mind,
a program written in any language...
How many years of C programming do you
have. Failing to answer will result in
me believing that you have less than five
minutes of C programming.
Dishonest dodge, and I don't care what you believe.
I have been programing in N since K & R was the standard.
Would you then accept that the finite string input to H is a 32-bit >>>>> (in
No mine will work with ASCII text.
If you know C well enough I could
avoid wasting a week f programming.
If you knew C well enough you would know that functions pointers
don't consist of the ASCII source code of the C function in question
I would not use a function pointer in my implementation.
If necessary I would parse the source file myself and
present it to the interpreter as the interpreter needs
to see it as an ASCII text string.
Then let's see it so we can point out how what you're doing doesn't
apply to the halting problem proof, given that your gross
misunderstanding of the problem means you most likely won't build it in
a compatible manner.
Its dead obvious to any C programmer
that D simulated by H cannot possibly
reach its own "return" statement so you
must be clueless about C.
Rejected out-of-hand as unclear.
To anyone that is clueless about C.
It is always going to be the same ASCII
text of a C function:D
Go ahead an interpret that as a bucket of
paint if you want to.
This can be fixed by prefixing all > instances of "D" and "H" in theabove sentence with exactly one of:
* algorithm
* C function
* finite string
your implementation) function pointer, and in particular that the
finite string D is a specific 32-bit value which is the starting
address of function D?
Call it a C interpreter. I will see if I can write one.
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and continue them to show that the decider is incorrect.
The only reason to rework things into a new C interpreter framework
would be to show that the problem was somehow caused by the x86utm.
Since you've chosen to deny the issue, you might as well stick
to the x86utm, since you've denied it for all possible platforms.
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and
continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
The only reason to rework things into a new C interpreter framework
would be to show that the problem was somehow caused by the x86utm.
Not at all. The details of x86 have proven to be
over everyone's head. That is the ONLY reason to
switch to a C interpreter.
Since you've chosen to deny the issue, you might as well stick
to the x86utm, since you've denied it for all possible platforms.
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and
continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H
is not part of the simulation and therefore not part of the machine state.
The only reason to rework things into a new C interpreter framework
would be to show that the problem was somehow caused by the x86utm.
Not at all. The details of x86 have proven to be
over everyone's head. That is the ONLY reason to
switch to a C interpreter.
Translation: My x86 code has been proven to be in error by Kaz's modifications so I have to use something else to hide my errors.
Since you've chosen to deny the issue, you might as well stick
to the x86utm, since you've denied it for all possible platforms.
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and
continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H
is not part of the simulation and therefore not part of the machine
state.
When D is simulated by H this requires H to simulate
itself simulating D.
The only reason to rework things into a new C interpreter framework
would be to show that the problem was somehow caused by the x86utm.
Not at all. The details of x86 have proven to be
over everyone's head. That is the ONLY reason to
switch to a C interpreter.
Translation: My x86 code has been proven to be in error by Kaz's
modifications so I have to use something else to hide my errors.
Kaz has gotten confused even by his own C code.
He does not understand that resuming the simulation
must begin at the total machine state when H.i==3
and H has just returned false.
Since you've chosen to deny the issue, you might as well stick
to the x86utm, since you've denied it for all possible platforms.
On 11/6/2025 12:58 PM, olcott wrote:
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed
H is not part of the simulation and therefore not part of the machine
state.
When D is simulated by H this requires H to simulate
itself simulating D.
And when that simulation is continued by something else,
it picks up
where the directly executed H left off which may be in the simulated H.
The only reason to rework things into a new C interpreter framework
would be to show that the problem was somehow caused by the x86utm.
Not at all. The details of x86 have proven to be
over everyone's head. That is the ONLY reason to
switch to a C interpreter.
Translation: My x86 code has been proven to be in error by Kaz's
modifications so I have to use something else to hide my errors.
Kaz has gotten confused even by his own C code.
He does not understand that resuming the simulation
must begin at the total machine state when H.i==3
and H has just returned false.
Nope, that's the directly executed H which is not part of the simulation
and therefore not part of the state.
Since you've chosen to deny the issue, you might as well stick
to the x86utm, since you've denied it for all possible platforms.
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and
continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
The only reason to rework things into a new C interpreter framework
would be to show that the problem was somehow caused by the x86utm.
Not at all. The details of x86 have proven to be
over everyone's head.
On 11/6/2025 12:01 PM, dbush wrote:
On 11/6/2025 12:58 PM, olcott wrote:
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed
H is not part of the simulation and therefore not part of the
machine state.
When D is simulated by H this requires H to simulate
itself simulating D.
And when that simulation is continued by something else,
This is cheating. There is "no something else" in the control flow path.
it picks up where the directly executed H left off which may be in the
simulated H.
The only reason to rework things into a new C interpreter framework >>>>>> would be to show that the problem was somehow caused by the x86utm. >>>>>>
Not at all. The details of x86 have proven to be
over everyone's head. That is the ONLY reason to
switch to a C interpreter.
Translation: My x86 code has been proven to be in error by Kaz's
modifications so I have to use something else to hide my errors.
Kaz has gotten confused even by his own C code.
He does not understand that resuming the simulation
must begin at the total machine state when H.i==3
and H has just returned false.
Nope, that's the directly executed H which is not part of the
simulation and therefore not part of the state.
To resume a computation requires that
exact same total machine state be restored.
Since you've chosen to deny the issue, you might as well stick
to the x86utm, since you've denied it for all possible platforms.
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and
continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
The point is that whether these remarks are true or not, the situation
is the same in x86utm-side work as in the abstract pseudo-interpretation exercise.
Now, the remarks are not true. You have misunderstood the technique.
The simulation of D is represented by a bunch of state (which in
the abstract exercise is represened by an "interp *s" handle;
in the x86utm Halt7 test case it is several objects, tracked by pointers with names like slave_state and slave_stack).
Conducting that simulation does not specifically require H. It requires /something/ to make repeated calls to interp_step(s). None of the simulation state is inside H: it is all encapsualted inside the "interp" object. After any
interp_step(s) call made by H, that simulation could be handed off to another agent to make subsequent calls to interp_step; the result of stepping
the simulation would be the same.
When H walks away from the interpretation and returns false, we are not interested in resuming H from the point where it made the decision.
(Which lies sometime between the most recent interp_step call and the
return false statement).
To resume D, all we need is the "interp *s" API handle, and to start
making interp_step(s) calls.
We do not need to do anythning with H; that doesn't make sense.
H, and the simulation of D, are like separate threads. We only care
about the D thread. After H detaches from that thread, is the remaining execution of that thread terminating.
The only reason to rework things into a new C interpreter framework
would be to show that the problem was somehow caused by the x86utm.
Not at all. The details of x86 have proven to be
over everyone's head.
That's simply untrue. People have built your code and meaningfully experimented with it.
What is your evidence for the belief that it was over anyone's head?
It's easy to work with; the compiled x86 functions are mostly small, and
a complete disassembly is given of the entire test case when it is run
so things are easy to follow.
That said, neither interpreted nor compiled C is the best mode of presentation
of this material to academia; switching from one to the other is mostly a lateral, unproductive move.
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and
continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H
is not part of the simulation and therefore not part of the machine state. >>
When D is simulated by H this requires H to simulate
itself simulating D.
On 11/6/2025 12:14 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and
continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
The point is that whether these remarks are true or not, the situation
is the same in x86utm-side work as in the abstract pseudo-interpretation
exercise.
No you are confused on the C side and confused
on the x86 side it is much more difficult to
show your mistake on the x86 side because no
one here (besides me) understands the x86 side.
If you resume your C code at the same total machine
state where H.i==3 and H has returned then you get
the exact same result. If you do this differently
then you didn't actually resume.
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H
is not part of the simulation and therefore not part of the machine state. >>>
When D is simulated by H this requires H to simulate
itself simulating D.
The simulation of D doesn't require H. It just happens that H is
initially conducting it.
H is initially conducting the simulation it in order to be able to
monitor it in detail, so that it can make a decision about D.
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H
is not part of the simulation and therefore not part of the machine state. >>>
When D is simulated by H this requires H to simulate
itself simulating D.
The simulation of D doesn't require H. It just happens that H is
initially conducting it.
void D(void)--
{
if (H(D)) { for (;;); }
return;
}
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 12:14 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
The point is that whether these remarks are true or not, the situation
is the same in x86utm-side work as in the abstract pseudo-interpretation >>> exercise.
No you are confused on the C side and confused
on the x86 side it is much more difficult to
show your mistake on the x86 side because no
one here (besides me) understands the x86 side.
So, let's get this straight:
Because ... I ... supposedly do not understand the x86 side (and neither
does anyone else besides you) .... you ... are not able to show the
mistake?
Is this how you interacted with your colleagues, managers and customers
in your career as coding technician?
What /ATTEMPT/ have you made to show what is wrong on the x86 side?
People who /CAN/ show that something is wrong are generally not concerned with whether the mistaken party understands it, as a first priority,
before showing anything at all. They show what is wrong, and then if it
is not understood they try to explain it.
If I'm wrong, it's not even important that I understand it; it's
important that you show that to the /WORLD/ to defend your work
against a wrong claim.
If you resume your C code at the same total machine
state where H.i==3 and H has returned then you get
the exact same result. If you do this differently
then you didn't actually resume.
No, we do not want to roll back the H control flow to an earlier
state. Nothing like that is going on.
Just code other than H picks up the interp object and makes more
interp_step calls on it.
The post I just made, specifying a different API for simulating
deciders, makes everything as clear as it can possibly be.
On 06/11/2025 18:37, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H >>>> is not part of the simulation and therefore not part of the machine
state.
When D is simulated by H this requires H to simulate
itself simulating D.
The simulation of D doesn't require H. It just happens that H is
initially conducting it.
H is initially conducting the simulation it in order to be able to
monitor it in detail, so that it can make a decision about D.
You're assuming that PO understands fundamentally "what a simulation
is". Simulation is an abstract concept, as is the more basic idea of "computation", and I've said many times (not to you especially) that
PO's brain wiring means he can't do "abstract" concepts and reasoning -
at least not in the way that "normal" people naturally handle such
concepts from a young age. For PO, it's all just his initial
intuitions, and then repeating his claims over and over using slightly different words.
As for the current situation - we know that PO often claims that the behaviour of a simulation is dependent on who is performing the
simulation.
So it comes as no surprise that PO now thinks that to
resume the simulation you have to also restore the simulator to the same point! :( To us that is just silly, but imagine it really was the case that the behaviour changes with the simulator?
Anyhow, to set PO on the correct path of recognising his errors, you
would need to correct his understanding of "simulation", but in doing
that it would turn out that he didn't understand "computation", and then that he didn't properly understand "halting", and "TM" and "function"
and "decision problem" and so on and so on.
Your focus on an infinite tower of simulations, and resuming abandonned simulations is intersesting - probably it's the only genuinely new
approach to convincing PO that's come along in the last couple of
years! But in the end it is all just too abstract for him. FIRST PO needs to be convinced that a computation only has one behaviour (in
terms of the computation's steps) and that simulations are just
evaluations of that one computation behaviour. I can't see any signs of even that much happening!
Mike.
On 11/6/2025 12:37 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H >>>> is not part of the simulation and therefore not part of the machine state. >>>>
When D is simulated by H this requires H to simulate
itself simulating D.
The simulation of D doesn't require H. It just happens that H is
initially conducting it.
Counter-factual
void D(void)
{
if (H(D)) { for (;;); }
return;
}
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 12:37 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:34 AM, dbush wrote:
On 11/6/2025 12:26 PM, olcott wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was >>>>>>> reproduced using the x86utm. We can pick up abandoned simulations and >>>>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
No, you got confused by not understanding that the directly executed H >>>>> is not part of the simulation and therefore not part of the machine state.
When D is simulated by H this requires H to simulate
itself simulating D.
The simulation of D doesn't require H. It just happens that H is
initially conducting it.
Counter-factual
void D(void)
{
if (H(D)) { for (;;); }
return;
}
Again, you are deliberately trying to muddle the conversation.
D incorporates the H(D) calculation and its behavior depends on it.
The simulation of D doesn't require H. It just happens that H is
initially conducting it.
That's /obviously/ not what I mean when I say "simulation of D does not require H".
The simulation itself of D requires H because D incorporates it.
The act of performing the simulation does not require H to be doing it.
The simulation can be performed by any calling context whatsoever,
which is able to call interp_step on the handle previously created
by interp_create(D).
On 11/6/2025 12:46 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 12:14 PM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 11:16 AM, Kaz Kylheku wrote:
On 2025-11-06, olcott <[email protected]> wrote:
Call it a C interpreter. I will see if I can write one.
What for? Abstract C interpretation shows the same issue that was
reproduced using the x86utm. We can pick up abandoned simulations and >>>>>> continue them to show that the decider is incorrect.
You got confused about resuming an aborted simulation
by trying to start it in a different machine state.
The point is that whether these remarks are true or not, the situation >>>> is the same in x86utm-side work as in the abstract pseudo-interpretation >>>> exercise.
No you are confused on the C side and confused
on the x86 side it is much more difficult to
show your mistake on the x86 side because no
one here (besides me) understands the x86 side.
So, let's get this straight:
Because ... I ... supposedly do not understand the x86 side (and neither
does anyone else besides you) .... you ... are not able to show the
mistake?
I will not tolerate going through any convoluted mess.
The C code I can spot the error in less than a minute.
Is this how you interacted with your colleagues, managers and customers
in your career as coding technician?
These people did not lie to disparage me.
What /ATTEMPT/ have you made to show what is wrong on the x86 side?
People who /CAN/ show that something is wrong are generally not concerned
with whether the mistaken party understands it, as a first priority,
before showing anything at all. They show what is wrong, and then if it
is not understood they try to explain it.
If I'm wrong, it's not even important that I understand it; it's
important that you show that to the /WORLD/ to defend your work
against a wrong claim.
If you resume your C code at the same total machine
state where H.i==3 and H has returned then you get
the exact same result. If you do this differently
then you didn't actually resume.
No, we do not want to roll back the H control flow to an earlier
state. Nothing like that is going on.
you didn't actually resume the simulation
you cheated instead.
Just code other than H picks up the interp object and makes more
interp_step calls on it.
The post I just made, specifying a different API for simulating
deciders, makes everything as clear as it can possibly be.
On 11/6/2025 2:03 PM, Mike Terry wrote:
As for the current situation - we know that PO often claims that the
behaviour of a simulation is dependent on who is performing the
simulation.
I am proven this and it is dead obvious that D simulated
by H includes H simulating itself simulated D and D simulated
by H1 does not require this. Is everyone here brain damaged?
On 2025-11-06, olcott <[email protected]> wrote:
On 11/6/2025 2:03 PM, Mike Terry wrote:
As for the current situation - we know that PO often claims that the
behaviour of a simulation is dependent on who is performing the
simulation.
I am proven this and it is dead obvious that D simulated
by H includes H simulating itself simulated D and D simulated
That's a different instance of H, conducting a different instance
of the simulation (different "level").
No simulation level N requires the previous N-1 level to be
conducted specifically by H.
Any code which calls the simulation API can conduct a simulation,
either from start to finish, or taking it over from other code.
by H1 does not require this. Is everyone here brain damaged?
By H1 I understand a procedure which simulates forever, until
the subject halts by itself.
"normal" people assume that textbooks and other foundations
are infallible. I double check and found out "not so much".
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,076 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 77:09:49 |
| Calls: | 13,805 |
| Files: | 186,990 |
| D/L today: |
5,243 files (1,704M bytes) |
| Messages: | 2,443,143 |