On 8/23/2025 11:37 PM, Richard Heathfield wrote:
Then if he's reporting on his input (as seems only fitting), he
should be reporting on DD's behaviour, not the simulation's
behaviour. (Clearly, they differ.)
You keep failing to understand that the actual behavior
specified by the actual input is measured by DD correctly
simulated by HHH.
Most everyone have been totally ignoring the actual
execution trace of DD correctly simulated by HHH.
Its like I tell them 2 + 6 = 8 and they disagree.
On 8/23/2025 11:37 PM, Richard Heathfield wrote:
On 23/08/2025 21:38, Richard Damon wrote:
On 8/23/25 3:53 PM, Richard Heathfield wrote:
On 23/08/2025 18:59, olcott wrote:
On 8/23/2025 12:51 PM, Richard Heathfield wrote:
On 23/08/2025 18:42, olcott wrote:
On 8/23/2025 12:38 PM, Richard Heathfield wrote:
On 23/08/2025 17:27, olcott wrote:DD simulated by HHH is a way to determine the
On 8/23/2025 11:06 AM, Richard Heathfield wrote:
On 23/08/2025 16:36, olcott wrote:
<snip>
Turing machine deciders only compute the mapping
from their inputs...
DD isn't a Turing machine. It's a C function.
And Because HHH is called by DD, HHH /is/ an input.
When 0 to ∞ instructions of DD are correctly
simulated by HHH this simulated DD never reaches
its own simulated "return" statement final halt state.
Reaching its own simulated return statement isn't the issue.
actual behavior that the actual input actually
specifies.
What about the behaviour of DD(), the C function? You keep
ignoring it in favour of DD-as-simulated-by-a-function-that-can't- >>>>>> see-75%- of- the-code.
Turing machine
You don't have a TM. DD is a C function.
deciders
You don't have a working decider.
only compute the mapping
...incorrectly...
from their inputs...
You don't concede that DD (the C function) is an input, so you don't
have a meaningful input.
<puerile repetition snipped>
Actually, he HAS conceded that DD is an input, and that as an input
it represents the behavior of DD directly executed, but he will try
to deny that concession.
Then if he's reporting on his input (as seems only itting), he should
be reporting on DD's behaviour, not the simulation's behaviour.
(Clearly, they differ.)
You keep failing to understand that the actual behavior
specified by the actual input is measured by DD correctly
simulated by HHH.
Most everyone have been totally ignoring the actual
execution trace of DD correctly simulated by HHH.
Its like I tell them 2 + 6 = 8 and they disagree.
The problem is he as specified that HHH is a counter example to the
proof, and thus that DD is the "pathological input" of the proof,
which is semantically defined to "Ask the decider to answer about the
direct execution of myself, where I will do the opposite of what the
decider will say".
One doesn't solve programming problems by calling them names. The task
of determining whether an input program halts is well-defined. The
task of using a solution to that problem to twist its tail is well-
defined. No pathology need apply.
Since he encodes this statement, in part, with HHH(DD), that call
MUST be DD asking HHH to decide on the direct execution of itself,
namely DD.
Well, he is asking HHH to decide on the algorithm specified by the DD
source code, which is very clearly not the algorithm he is simulating.
This means that when he tries to say that as in input it can't mean
to refer to that direct execution (because Turing Machines can't do
that) he is admitting defeat or that he has a bug in his code
defining DD.
His bug is in thinking that one path through the algorithm is all that
DD does. HHH halts the DD simulation when it thinks it's going to
recurse for ever, but never stops to think what DD might do if it /
doesn't recurse for ever - as in, for example, when its call to HHH
backs out of a potentially infinite recursion by pruning a branch of
the simulation and returning 0 to DD (the direct execution, that is).
It also means that DD must be an actual PROGRAM (which he will deny,
proving himself a liar) and thus to call HHH, HHH must be an actual
program too, and can't be that "infinite set of deciders" as you
can't call such a thing.
Well, we know what DD the program does when HHH the program does what
its author claims. HHH claims that DD never halts and yields 0, and DD
then halts, so HHH the program is not a decider for DD the program.
On 8/25/2025 1:28 AM, Richard Heathfield wrote:
On 25/08/2025 06:07, olcott wrote:
On 8/23/2025 11:37 PM, Richard Heathfield wrote:
<snip>
Then if he's reporting on his input (as seems only fitting),
he should be reporting on DD's behaviour, not the
simulation's behaviour. (Clearly, they differ.)
You keep failing to understand that the actual behavior
specified by the actual input is measured by DD correctly
simulated by HHH.
ITYM "incorrectly".
DD halts.
When HHH simulates DD, it reports that DD is non-halting.
Therefore, the simulation is wrong.
That the simulation is correct is a verified fact.
No one can possibly point to any specific line of
code was simulated incorrectly because every line
was simulated correctly is a verified fact.
Everyone moronically stupidly thinks that they can
simply ignore the verified fact that DD does call
HHH(DD) in recursive simulation.
I just empirically proved that DD correctly simulated
by HHH cannot possibly stop running by removing the
abort code and running DD() from main.
When I disable the abort code DD() executed from
main never stops running.
On 8/25/2025 10:02 AM, dbush wrote:
On 8/25/2025 10:59 AM, olcott wrote:
When I disable the abort codeYou change the input.
Changing the input is not allowed.
Unless the change cannot possibly have any effect on the
sequence of DD instructions correctly simulated by HHH.
You act like appending NOP instructions to the end
of DD changes the input in a consequential way.
Changing the input in an inconsequential way is allowed.
On 8/25/2025 1:28 AM, Richard Heathfield wrote:Again, not every line was simulated correctly; there are lines that
On 25/08/2025 06:07, olcott wrote:That the simulation is correct is a verified fact. No one can possibly
On 8/23/2025 11:37 PM, Richard Heathfield wrote:
Then if he's reporting on his input (as seems only fitting), he
should be reporting on DD's behaviour, not the simulation's
behaviour. (Clearly, they differ.)
You keep failing to understand that the actual behavior specified by
the actual input is measured by DD correctly simulated by HHH.
ITYM "incorrectly".
DD halts.
When HHH simulates DD, it reports that DD is non-halting.
Therefore, the simulation is wrong.
point to any specific line of code was simulated incorrectly because
every line was simulated correctly is a verified fact.
I just empirically proved that DD correctly simulated by HHH cannotlol „I proved that this finite loop is infinite by removing the break”
possibly stop running by removing the abort code and running DD() from
main.
On 8/25/2025 10:02 AM, dbush wrote:
On 8/25/2025 10:59 AM, olcott wrote:
On 8/25/2025 9:55 AM, dbush wrote:
You change the input.False. The last instruction that was simulated was simulatedWhen I disable the abort code
incorrectly because the simulation of that instruction wasn't
followed by the simulation of the following instruction in violation
of the x86 language.
Not that it matters anyway since HHH takes an execution trace as
input and is therefore DISQUALIFIED from being a halt decider /
termination analyzer.
Changing the input is not allowed.
Unless the change cannot possibly have any effect on the sequence of DD instructions correctly simulated by HHH.
You act like appending NOP instructions to the end of DD changes the
input in a consequential way. Changing the input in an inconsequential
way is allowed.
On 8/25/2025 10:52 AM, joes wrote:
Am Mon, 25 Aug 2025 10:31:54 -0500 schrieb olcott:
[...] Changing the input in an
inconsequential
way is allowed.
How is aborting or not „inconsequential”?
It does not change the sequence of instructions
of DD correctly simulated by HHH thus does not
change the halt status criteria:
On 8/25/2025 10:02 AM, dbush wrote:
Changing the input is not allowed.
Unless the change cannot possibly have any effect on the
sequence of DD instructions correctly simulated by HHH.
On 8/25/2025 12:01 PM, olcott wrote:
It does not change the sequence of instructionsDo you realize how ridiculous that sounds?
of replacing the code of HHH with an unconditional simulator
and subsequently running HHH(DD)
On 8/25/2025 12:01 PM, olcott wrote:
It does not change the sequence of instructionsDo you realize how ridiculous that sounds?
of replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD)
On 25/08/2025 17:15, dbush wrote:
On 8/25/2025 12:01 PM, olcott wrote:
It does not change the sequence of instructionsDo you realize how ridiculous that sounds?
of replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD)
But that is how PO operates.
On 2025-08-25, Mike Terry <[email protected]> wrote:
On 25/08/2025 17:15, dbush wrote:
On 8/25/2025 12:01 PM, olcott wrote:
It does not change the sequence of instructionsDo you realize how ridiculous that sounds?
of replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD)
But that is how PO operates.
PO has some cognitive problem affecting memory, probably dementia.
There are are instances in which he treats years-old rehashed objections
as if they were new findings.
Even if he accepted some argument, within a week he will have forgotten
that, like anterograde amnesia. (Like that Bill Cunningham troll in comp.lang.c; forever asking beginner stuff, never retaining knowledge.)
On 8/25/2025 12:35 PM, dbush wrote:
On 8/25/2025 1:32 PM, olcott wrote:
If people would quit gaslighting me on the behavior
of replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) I could move on to
my next point.
Obviously when you change the input like that you end up with something
that doesn't halt, but that's not what was asked about.
Changing the quoted words is what despicable lying bastards do.
On 8/25/2025 2:05 PM, Kaz Kylheku wrote:
On 2025-08-25, olcott <[email protected]> wrote:Many or most of your technical assessments of my work are correct.
On 8/25/2025 12:35 PM, dbush wrote:
On 8/25/2025 1:32 PM, olcott wrote:
If people would quit gaslighting me on the behavior of replacing the >>>>> code of HHH with an unconditional simulator and subsequently running >>>>> HHH(DD) I could move on to my next point.
Obviously when you change the input like that you end up with
something that doesn't halt, but that's not what was asked about.
Changing the quoted words is what despicable lying bastards do.
... when they are not busy changing the DD input case so that it
doesn't halt, and then insisting that the changed input case is the
input that the halting decision is about.
On 8/25/2025 11:22 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <[email protected]> wrote:
On 8/25/2025 10:02 AM, dbush wrote:
Changing the input is not allowed.
Unless the change cannot possibly have any effect on the
sequence of DD instructions correctly simulated by HHH.
When HHH is called, it burns a fuse which changes the behavior of a
subsequent HHH call. That subsqeuent HHH call is made by DD. Thus, DD
was changed from being terminating to a different procedure which is
non-terminating.
But the verdic of your top-level HHH(DD) call, which returns 0, must be
interpreted as being a verdict of the original DD which halted.
At the time the top-level HHH(DD) call takes place, just before the
function body of HHH begins executing, the fuse has not yet been burned,
and so DD is sill the original, halting DD. That's the one being
decided, not the modified DD.
** In short, changing the input is allowed, but your decider
** understood as being referenced to the original input.
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
On 8/26/2025 12:36 AM, Kaz Kylheku wrote:<snip>
On 2025-08-25, olcott <[email protected]> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
Again, this is obvious and uninteresting: so what?
The counter-example input finally has a halt status that is not
contradicted.
On 8/25/2025 11:50 AM, Mike Terry wrote:
On 25/08/2025 17:15, dbush wrote:
On 8/25/2025 12:01 PM, olcott wrote:
It does not change the sequence of instructionsDo you realize how ridiculous that sounds?
of replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD)
But that is how PO operates.
There is /no/ logic underlying what he says.
*That is counter-factual*
*That is counter-factual*
*That is counter-factual*
*That is counter-factual*
*That is counter-factual*
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
On 8/26/2025 12:36 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <[email protected]> wrote:
On 8/25/2025 11:22 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <[email protected]> wrote:
On 8/25/2025 10:02 AM, dbush wrote:
Changing the input is not allowed.
Unless the change cannot possibly have any effect on the
sequence of DD instructions correctly simulated by HHH.
When HHH is called, it burns a fuse which changes the behavior of a
subsequent HHH call. That subsqeuent HHH call is made by DD. Thus, DD >>>> was changed from being terminating to a different procedure which is
non-terminating.
But the verdic of your top-level HHH(DD) call, which returns 0, must be >>>> interpreted as being a verdict of the original DD which halted.
At the time the top-level HHH(DD) call takes place, just before the
function body of HHH begins executing, the fuse has not yet been
burned,
and so DD is sill the original, halting DD. That's the one being
decided, not the modified DD.
** In short, changing the input is allowed, but your decider
** understood as being referenced to the original input.
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
Again, this is obvious and uninteresting: so what?
The counter-example input finally has a halt status that is not
contradicted.
Everyone that directly contradicts me only does
this on the basis of directly contradicting
verified facts.
On 8/26/2025 12:36 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <[email protected]> wrote:The counter-example input finally has a halt status that is not
On 8/25/2025 11:22 AM, Kaz Kylheku wrote:
On 2025-08-25, olcott <[email protected]> wrote:
On 8/25/2025 10:02 AM, dbush wrote:
Changing the input is not allowed.
Unless the change cannot possibly have any effect on the
sequence of DD instructions correctly simulated by HHH.
When HHH is called, it burns a fuse which changes the behavior of a
subsequent HHH call. That subsqeuent HHH call is made by DD. Thus, DD >>>> was changed from being terminating to a different procedure which is
non-terminating.
But the verdic of your top-level HHH(DD) call, which returns 0, must be >>>> interpreted as being a verdict of the original DD which halted.
At the time the top-level HHH(DD) call takes place, just before the
function body of HHH begins executing, the fuse has not yet been burned, >>>> and so DD is sill the original, halting DD. That's the one being
decided, not the modified DD.
** In short, changing the input is allowed, but your decider
** understood as being referenced to the original input.
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
Again, this is obvious and uninteresting: so what?
contradicted.
On 8/26/2025 2:32 AM, Richard Heathfield wrote:
On 26/08/2025 06:48, olcott wrote:
On 8/26/2025 12:36 AM, Kaz Kylheku wrote:<snip>
On 2025-08-25, olcott <[email protected]> wrote:
DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.
Again, this is obvious and uninteresting: so what?
The counter-example input finally has a halt status that is not
contradicted.
Make sure you carefully overlook all the people who contradict you.
(And reality, which is the hardest contradictor of all.)
Everyone that directly contradicts me only does
this on the basis of directly contradicting
verified facts.
As soon as HHH(DD) correctly rejects DD as a
pure function of its input the HP proofs are
proven to not derive their conclusion.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 56:38:52 |
| Calls: | 12,117 |
| Files: | 15,010 |
| Messages: | 6,518,666 |