From Newsgroup: comp.theory

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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-31, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator
(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume
simulating something which has not been abandoned. If any simulation has
a parent that is also in the list, we must not step it, but its parent.
Unless that parent still has a parent and so on. Only the thing with no
living parent---an abandoned orphan---must be stepped.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 31/10/2025 05:18, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator
(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

Yes that's a good approach.

It's funny PO claims to be a bit of an expert on OS-level coding, but his solution for "how can we
detect when a piece of user code is done?" is "gee, I must analyse the user code, and locate the
final 'ret' instruction (assuming our compiler has arranged for there to be only the one...) then I
can compare EIP with that address"! There is a surprising amount of PO code that is there only in
support of finding and tracking addresses of "final ret" instructions. You'd think he might
understand how Windows, Unix, and every other OS that's ever existed handles this question...

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume simulating something which has not been abandoned. If any simulation has
a parent that is also in the list, we must not step it, but its parent. Unless that parent still has a parent and so on. Only the thing with no living parent---an abandoned orphan---must be stepped.

In PO's halt7.c no computation (directly) starts multiple child simulations, so there is a strict
hierarchy of nestings. When the main input computation has returned, the oldest simulation that is
not naturally terminated must be parentless (abandonned). Once that has been resumed and ended, the
next oldest can be examined and so on. If we want to cater for a parent-child tree of simulations
rather than a strict sequence, let's see... Well it still seems OK to resume in order of
creation/first use - a simulation's parent must logically have been created earlier than that
simulation, so if the oldest unfinished simulation is resumed, its parent (being older) must have
already been resumed so has ended. Hmm,. Also there is the case of new simulations being created
by a resumed simulation, to handle, but you obviously know about that and just haven't sorted it yet
in your GIT code.


Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 12:18 AM, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator

Nope.

(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

Which of the stacks are you referring to?

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume simulating something which has not been abandoned. If any simulation has
a parent that is also in the list, we must not step it, but its parent. Unless that parent still has a parent and so on. Only the thing with no living parent---an abandoned orphan---must be stepped.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 12:18 AM, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator

You don't even know the difference between
H calling D and H simulating D.

Even when H1 simulates D as soon as D reaches
its "return" statement there is no address on
its stack that D can return to. If H1 didn't
catch this it might crash the x86utm operating
system. Popping from an empty stack probably
can only return garbage.

(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume simulating something which has not been abandoned. If any simulation has
a parent that is also in the list, we must not step it, but its parent. Unless that parent still has a parent and so on. Only the thing with no living parent---an abandoned orphan---must be stepped.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 31/10/2025 16:14, olcott wrote:

On 10/31/2025 12:18 AM, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator

Nope.

You prime it to return to the END_OF_CODE: label in HHH. That makes no sense, but you then make no
further use of that.

Mike.

(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

Which of the stacks are you referring to?

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume
simulating something which has not been abandoned. If any simulation has
a parent that is also in the list, we must not step it, but its parent.
Unless that parent still has a parent and so on.  Only the thing with no
living parent---an abandoned orphan---must be stepped.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 11:35 AM, Mike Terry wrote:

On 31/10/2025 16:14, olcott wrote:

On 10/31/2025 12:18 AM, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator

Nope.

You prime it to return to the END_OF_CODE: label in HHH.  That makes no sense, but you then make no further use of that.

Mike.

D simulated by H cannot possibly return because:
(a) It never reaches its return
(b) There is no address on its stack to return to.
D is not called by H, it is simulated by H
and the H stack is not the same as the simulation
stack.

(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

Which of the stacks are you referring to?

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume
simulating something which has not been abandoned. If any simulation has >>> a parent that is also in the list, we must not step it, but its parent.
Unless that parent still has a parent and so on.  Only the thing with no >>> living parent---an abandoned orphan---must be stepped.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/25 12:23 PM, olcott wrote:

On 10/31/2025 12:18 AM, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator

You don't even know the difference between
H calling D and H simulating D.

Even when H1 simulates D as soon as D reaches
its "return" statement there is no address on
its stack that D can return to. If H1 didn't
catch this it might crash the x86utm operating
system. Popping from an empty stack probably
can only return garbage.

And the proper solution would be to setup the stack so there *IS* a
special return address on the stack (perhaps 0 would be a good special
value).

You should not use an address that is in the executable space of the
program, like any address of the simulator, since the simulated program includes the simulator.

This is of course, part of your problem that you don't clearly define
memory spaces and thus don't have the needed independence.

A proper fully generic simulator puts the code to be simulated inside a virtual address space so EVERY access in the simulation gets mapped the
same. The key is that "Simuated Addresses" and "Simulator Addresses" are distinct things, even if the simulated machine uses the simulator, as it really needs to have its own instance of it, even it if just happens to
be the same code, or the simulated code isn't actually a seperate program.

(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume
simulating something which has not been abandoned. If any simulation has
a parent that is also in the list, we must not step it, but its parent.
Unless that parent still has a parent and so on.  Only the thing with no
living parent---an abandoned orphan---must be stepped.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-31, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 12:18 AM, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator

You don't even know the difference between
H calling D and H simulating D.

Yah, /that's/ what i don't know. Uh huh!

Even when H1 simulates D as soon as D reaches
its "return" statement there is no address on
its stack that D can return to.

Well there isn't one that you actually /rembember/ coding up,
due to your failing memory and congitive decline.

But you could always, you know, look at the fucking code.

Does this line ring a bell?

// Inside HHH:

Init_slave_state0((u32)P, End_Of_Code, slave_state, slave_stack); // 2024-06-16

look at the second paraemeter, what is that?

Inside INit_slave_state0:

Top_of_Stack = StackPush(slave_stack, End_Of_Code); // Return Address in Halts()

The primed return address of the simulated subject points to the
end-of-code label in Halts which compiles to the RET instruction.
(which I know from the studying the disassembly.)

In your DebugStep loop, you actually step DD past its RET instruction.

Why? BEcause you do do the code_end step //after// running the
instruction.

At the top of Decide_Halting's step loop you have this:

u32 EIP = (*slave_state)->EIP; // Save EIP of instruction to be executed
DebugStep(*master_state, *slave_state, *decoded); // Execute this instruction
if (EIP == code_end) // last instruction of P "ret"
return 1; // input has halted

The current instruction is first put through DebugStep, and /then/
the original EIP is checked for code_end.

So what happens is that DD's (or D's) RET branch is taken,
and the EIP ends up pointing at the RET inside HHH.

Why do I knwo this? Because my report informed me of that!

After I found that DDD terminates, I dumped information about it
including its EIP. I was surprised to find that it's pointing into HHH. Moreover at the last instruction in HHH. I scratched my head for a
second: how can I be? So then I went in detail into the stack priming
code, and gained the above undersatnding.

catch this it might crash the x86utm operating
system. Popping from an empty stack probably
can only return garbage.

Luckily, a person you evidently no longer remember knew a thing or two
about priming the stacks of newly executing threads, and applied it to
x86utm simulation.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/25 12:55 PM, olcott wrote:

On 10/31/2025 11:35 AM, Mike Terry wrote:

On 31/10/2025 16:14, olcott wrote:

On 10/31/2025 12:18 AM, Kaz Kylheku wrote:

On 2025-10-31, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:

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

I happen to know the exact answer for that from the typical way Halt7
sets up the simualtion, and believe that to obe consistent across
different H functions and versions.

The initial slave_stack is primed in such a way that when
the last RET instruction at code_end of the simulated function is
executed, it will return to the last instruction of the simulator

Nope.

You prime it to return to the END_OF_CODE: label in HHH.  That makes
no sense, but you then make no further use of that.

Mike.

D simulated by H cannot possibly return because:

You have a equivication over your words.

The PROGRAM D that H is trying to simulate, DOES reach its return, as
its behavior continues even after H aborts its simulation.

The PARTIAL SIMULATION BY H of D, doesn't reach the return, but that is
not what the actual question asks.

Part of your problem is you seem to equivocate over what H actually is, sometimes it is the code in your github in Halt7.c, in which case it is
just wrong, as with this definition D() will halt when run, while H(D)
returns 0, and thus H claims D() will never halt.

When you start to try to define H as some indeterminate program, you
suddenly don't have an input D to use, as for the halting problem, the
input MUST be a specific program, but D isn't if H isn't one. Thus this
case is just a category error.

(a) It never reaches its return
(b) There is no address on its stack to return to.
    D is not called by H, it is simulated by H
    and the H stack is not the same as the simulation
    stack.

Which is part of the problem of your C model. Note, that in C, the
"program" is DEFINED to have been called by "the system" and a return
from the first function called (normally main if in a hosted system, but
can be another function in a free statnding syste) is DEFINED to return
to that system, which in your model is "halting"

So, giving your input to a pure simulator, rather than to H, results in
a simulation that reaches the final state (if H(D) returns 0 as you
claim is correct) and said pure simulator, to be correct, has some way
to detect that "empty stack", simplest is by preconditioning the
simulated stack with a special value (like 0) to detect this.

(the relevant H function). RET returns to RET. No idea what for.

Needless to say, that is hokey and we don't want to be looking for
that.

We can just use ESP to detect terminated simuations.

Which of the stacks are you referring to?

No, not extra-sensory perception (haha, I bet that got a twinkle
out of Olcott's eye there!) but the stack pointer.

When the first instruction of a new simulaton is observed, we can
record the stack pointer. Then we can tell from the slave_state
that it has popped up out of that context.

The reckoning module can remove such simulations from the list.

What you hae to be careful in the reckoning module is not to resume
simulating something which has not been abandoned. If any simulation
has
a parent that is also in the list, we must not step it, but its parent. >>>> Unless that parent still has a parent and so on.  Only the thing
with no
living parent---an abandoned orphan---must be stepped.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-31, Richard Damon <Richard@Damon-Family.org> wrote:

On 10/31/25 12:55 PM, olcott wrote:
Part of your problem is you seem to equivocate over what H actually is, sometimes it is the code in your github in Halt7.c, in which case it is

But even if is consistently understood to be that code, it is still
equivocated upon. H is an aborting decider if it is the top-level one
with Root == 1, and H is the non-aborting decider if it is any other
level with Root = 0.

It is two functions in one thanks to mutable, static state.

It's as if Olcott cannot write a page of C code in relation to some
logic proble, without equivocating right in the code itself.

(At least it jibes with his rhetoric then, I suppose; equivocal rhetoric deserves equivocal code.)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/25 2:03 PM, Kaz Kylheku wrote:

On 2025-10-31, Richard Damon <Richard@Damon-Family.org> wrote:

On 10/31/25 12:55 PM, olcott wrote:
Part of your problem is you seem to equivocate over what H actually is,
sometimes it is the code in your github in Halt7.c, in which case it is

But even if is consistently understood to be that code, it is still equivocated upon. H is an aborting decider if it is the top-level one
with Root == 1, and H is the non-aborting decider if it is any other
level with Root = 0.

It is two functions in one thanks to mutable, static state.

It's as if Olcott cannot write a page of C code in relation to some
logic proble, without equivocating right in the code itself.

(At least it jibes with his rhetoric then, I suppose; equivocal rhetoric deserves equivocal code.)

That just makes it not a computation, and thus a category error to be
called a decider.

But even being a non-computation, it can't be always correct for this
input, and thus not even a correct halt meta-decider.

His problem is that he needs to imagine H not even being that code, as
that code is still deterministic, even if it incorrectly uses
information it isn't supposed to have, all that does is possible allow
to be right in one case, but wrong somewhere else, which still makes it
wrong.
--- Synchronet 3.21a-Linux NewsLink 1.2