On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:and proves that this
On 9/10/2025 6:31 PM, Richard Heathfield wrote:
The simulation is correct as I have proven
by disabling the abort code. Are you ONLY
a liar or can you tell the truth?
When you disable the abort code, that changes the behavior
of HHH.
*would never stop running unless aborted* criteria is met:
Is met for a different, new DD that is now obviously non-halting,
and unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running
unless aborted; the altered DD now fits the description.)
It is a simple categorical analysis.
When nothing anywhere is changed besides the abort
code is disabled and this single change causes DD
On 11/09/2025 01:06, olcott wrote:
On 9/10/2025 6:53 PM, Richard Heathfield wrote:
On 11/09/2025 00:42, olcott wrote:
On 9/10/2025 6:31 PM, Richard Heathfield wrote:
On 11/09/2025 00:16, olcott wrote:
<snip>
Yes it seems that you are still a damned liar.
Insult = Evasion
You snipped the most important parts.
Oh really? Let's take a look, and we'll stop at the first lie?
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates
That's a lie. Your simulation gives the wrong answer, so it's not a >>>>> correct simulation.
So your "most important part" is deceitful bullshit.
The simulation is correct as I have proven
Bullshit.
$ cat plaindd.c
#include <stdio.h>
#define HHH(x) 0
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
DD();
printf("DD halted.\n");
return 0;
}
$ gcc -o plaindd plaindd.c
$ ./plaindd
DD halted.
$
That cannot be generalized to a universal
halt decider so it is useless.
Correct on both counts. About time you got something right.
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:and proves that this
On 9/10/2025 6:31 PM, Richard Heathfield wrote:
The simulation is correct as I have proven
by disabling the abort code. Are you ONLY
a liar or can you tell the truth?
When you disable the abort code, that changes the behavior
of HHH.
*would never stop running unless aborted* criteria is met:
Is met for a different, new DD that is now obviously non-halting,
and unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running
unless aborted; the altered DD now fits the description.)
It is a simple categorical analysis.
When nothing anywhere is changed besides the abort
code is disabled and this single change causes DD
to keep running then we know that DD specifies
non-halting behavior.
Technically we have a single independent variable
abort / no abort
and a single dependent variable
stop running / never stop running.
On 9/10/2025 7:14 PM, Richard Heathfield wrote:
On 11/09/2025 01:06, olcott wrote:
On 9/10/2025 6:53 PM, Richard Heathfield wrote:
$ ./plaindd
DD halted.
$
That cannot be generalized to a universal
halt decider so it is useless.
Correct on both counts. About time you got something right.
So it is useless on many different levels
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:56 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
It has never been the job of any halt
decider to report on the behavior of
any directly executed machine such as DD()
It has always been the job of every halt
decider to examine a finite string machine
description to determine the behavior that
this finite string specifies such as the
finite string of x86 machine code of DD.
The problem is that those supposedly different
DD are exactly the same.
Not at all they are NEVER the same.
You are so sure that I must be wrong
that you hardly pay any attention.
You never go in and debug your code.
DD simulated by HHH includes DD calling HHH(DD)
in recursive emulation that *is* non-halting.
The recursive emulation is instantiated only down to as many levels as
the number of PUSH instructions that your detector detects.
DD simulated by HHH1 does not include DD
calling HHH1(DD) in recursive emulation.
Since HHH1 isnt HHH, it may be possible for HHH1 to correctly
decide the <HHH, DD> diagonal case: i.e. for HHH1(DD) to
correctly return 1.
called in recursive emulation
DOES NOT EQUAL
not called in recursive emulation.
It absolutely does and is that way in your code.
(And even if it were not, the gold standard for determining
whether a procedure is halting or not is the "not called in
recursive emulation" case; that's what must be decided.)
Prove they are not equal.
Make sure the abort code is turned on so we have HHH(DD) == 0.
Write code to collect all the unfinished simuation objects into a linked list; i.e. whenever HHH bails out of the simulation loop and returns,
it pushes the simulation onto the list of unfinished simulations.
Then at the end of main() call a function which marches
through all the unfinished simulations and steps them.
You will see that the end of DD() is reached, contrary to your claim.
The only reason the recursive DD's do not reach their final RET
instruction is that their simulation was left incomplete.
Leaving a simulation incomplete does not render the simulation
sobject non-halting.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:and proves that this
On 9/10/2025 6:31 PM, Richard Heathfield wrote:
The simulation is correct as I have proven
by disabling the abort code. Are you ONLY
a liar or can you tell the truth?
When you disable the abort code, that changes the behavior
of HHH.
*would never stop running unless aborted* criteria is met:
Is met for a different, new DD that is now obviously non-halting,
and unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running
unless aborted; the altered DD now fits the description.)
It is a simple categorical analysis.
When nothing anywhere is changed besides the abort
code is disabled and this single change causes DD
to keep running then we know that DD specifies
non-halting behavior.
Any competent engineer knows that DD has been modified
to specify non-halting behavior.
On 9/10/2025 8:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:and proves that this
On 9/10/2025 6:31 PM, Richard Heathfield wrote:
The simulation is correct as I have proven
by disabling the abort code. Are you ONLY
a liar or can you tell the truth?
When you disable the abort code, that changes the behavior
of HHH.
*would never stop running unless aborted* criteria is met:
Is met for a different, new DD that is now obviously non-halting,
and unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running
unless aborted; the altered DD now fits the description.)
It is a simple categorical analysis.
When nothing anywhere is changed besides the abort
code is disabled and this single change causes DD
to keep running then we know that DD specifies
non-halting behavior.
Any competent engineer knows that DD has been modified
to specify non-halting behavior.
*counter-factual*
It has always been the fact that DD calls HHH(DD)
in recursive simulation that has been the source
of the non-halting behavior.
DD simulated by HHH1 reaches its final halt state.
DD simulated by HHH CANNOT POSSIBLY reach its final halt state.
The only reason the recursive DD's do not reach their final RET
instruction is that their simulation was left incomplete.
This has never been the case.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
Its isomorphic to completely simulating Infinite_Recursion().
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
When nothing anywhere is changed besides the abort code is disabled andWhen you disable the abort code, that changes the behavior of HHH.and proves that this *would never stop running unless aborted*
criteria is met:
Is met for a different, new DD that is now obviously non-halting, and
unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running unless
aborted; the altered DD now fits the description.)
this single change causes DD to keep running then we know that DD
specifies non-halting behavior.
On 9/10/2025 12:49 PM, wij wrote:
On Wed, 2025-09-10 at 11:33 -0500, olcott wrote:
On 9/10/2025 12:54 AM, Richard Heathfield wrote:
On 10/09/2025 04:33, olcott wrote:
I am just trying to get you to understand that
the correct answer is DOES NOT HALT. I have proven that
and five LLM systems all agree that I am correct.
No doubt about it. Oh, wait...
+-------------------------------------------+
HHH decides whether its input halts. What should it return?
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
+-------------------------------------------+
Good question — this is essentially a self-referential Halting Problem >>>> paradox. Let’s carefully analyze what happens with your function DD(). >>>>
<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.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
Q1: What time is it? Yes or no (or undecidabe if none fits).
Q2: Jack is a bachelor. Does Jack hit his wife? Yes or no (or
undecidable if none fits)
Likewise what value should a halt decider return
*WHEN AN ACTUAL INPUT DOES THE OPPOSITE OF WHATEVER IT SAYS?*
*NO SUCH ACTUAL INPUT HAS EVER EXISTED*
On 9/10/2025 2:46 AM, Mikko wrote:
On 2025-09-09 13:11:53 +0000, olcott said:
On 9/7/2025 3:46 AM, Mikko wrote:
On 2025-09-04 19:47:51 +0000, olcott said:
On 9/4/2025 12:17 PM, Mike Terry wrote:
On 04/09/2025 04:25, Kaz Kylheku wrote:Please do not attempt to bluster your way through
I think I can very nicely articulate the main thing that is leading >>>>>>> Peter astray.
He has come up with an idea to make a halting decider by modifying an >>>>>>> interpreter, outfitting with logic to recognize a certain recursive >>>>>>> pattern (the Abort Pattern). When it sees the pattern, it declares that >>>>>>> the input is non-halting.
Yes, I like your explanation below, mostly, but there is one major >>>>>> difference from how I would have tried to explain things. (See below) >>>>>>
Also, coming up detailed explanations for PO's mistakes will in no >>>>>> sense lead to PO /recognising/ those mistakes and abandonning his false >>>>>> claims. (I'm sure you realise that by now, and your words are for >>>>>> others here. PO's failure to understand explanations given to him is >>>>>> not due to poor wordings/omissions/lack of presentation skills on the >>>>>> part of those explaining. I'd say it's something in his brain wiring, >>>>>> but hey I'm not qualified to pronounce on such things!)
What's really going on this: the pattern is really indicating that there
is an infinite tower of nested interpretations being started.
In other words, there is an infinity being identified, but it is the >>>>>>> wrong one.
OK, here is where I would say differently.
The problem for me is that when PO's pattern matches, there is in fact >>>>>> / nothing actually infinite/ involved. You suggest it has identified >>>>>> an infinite tower of nested interpretations, but obviously that is not >>>>>> literally true - it has identified TWO levels of nested interpretations, >>>>>
this. If you don't know the x86 language then simply
say that.
Don't try and get away with saying that I am wrong
the basis that you have no idea what I am saying.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
How would DD emulated by some HHH according to
the semantics of the x86 language reach past its
own machine address: 0000216b?
I have asked this question many many times and no
one even made any attempt to answer this exact
question. All of the attempts CHANGED THE QUESTION
and then answered this CHANGED QUESTION.
The question is ambiguous because "some HHH" means existential
quantification over an undefined set
Its not an undefined set. Membership in the set is
determined by these criteria. Some HHH emulates zero
to infinity of the x86 instructions of DD according
to the semantics of the x86 language. This base HHH
is not allowed to do more or less than this. There
may be an infinite number of different implementations
for HHH to emulate 7 instructions of DD.
These criteria permit an implementation that returns some number
of steps but doesn't care what happens in the simulation and
always returns 1.
No in this simplified case there is no return value.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 8:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:and proves that this
On 9/10/2025 6:31 PM, Richard Heathfield wrote:
The simulation is correct as I have proven
by disabling the abort code. Are you ONLY
a liar or can you tell the truth?
When you disable the abort code, that changes the behavior
of HHH.
*would never stop running unless aborted* criteria is met:
Is met for a different, new DD that is now obviously non-halting,
and unrelated to the halting DD that arises from HHH(DD) returning 0. >>>>>
(Any Turing Machine that is non-halting never stops running
unless aborted; the altered DD now fits the description.)
It is a simple categorical analysis.
When nothing anywhere is changed besides the abort
code is disabled and this single change causes DD
to keep running then we know that DD specifies
non-halting behavior.
Any competent engineer knows that DD has been modified
to specify non-halting behavior.
*counter-factual*
It has always been the fact that DD calls HHH(DD)
in recursive simulation that has been the source
of the non-halting behavior.
Do you not agree that changing the definition of HHH
changes DD, since DD is built on HHH?
(I mean regardless of your belief that recursive simulation
always brings in non-halting behavior.)
Even if you believe that DD is always non-halting due to recursive termination, surely you at least have to recognize that you're
making a different DD when you tinker with HHH, no?
Am Wed, 10 Sep 2025 19:52:20 -0500 schrieb olcott:
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
When nothing anywhere is changed besides the abort code is disabled andWhen you disable the abort code, that changes the behavior of HHH.and proves that this *would never stop running unless aborted*
criteria is met:
Is met for a different, new DD that is now obviously non-halting, and
unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running unless
aborted; the altered DD now fits the description.)
this single change causes DD to keep running then we know that DD
specifies non-halting behavior.
That is two changes:
one in the simulator and one in the input,
because DD calls HHH. But when you run the original DD, which
calls the aborting HHH, in a non-aborting simulator, it will halt!
The input to HHH specifies aborted recursive simulation.
On 9/11/2025 2:50 AM, joes wrote:
Am Wed, 10 Sep 2025 19:52:20 -0500 schrieb olcott:
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
When nothing anywhere is changed besides the abort code is disabledWhen you disable the abort code, that changes the behavior of HHH. >>>>>>and proves that this *would never stop running unless aborted*
criteria is met:
Is met for a different, new DD that is now obviously non-halting, and
unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running unless
aborted; the altered DD now fits the description.)
and this single change causes DD to keep running then we know that DD
specifies non-halting behavior.
That is two changes:
Only one block of code in the u32 Decide_Halting_HH() function is enabled/disabled by this #define ENABLE_ABORT_CODE 1
one in the simulator and one in the input,
because DD calls HHH. But when you run the original DD, which calls the
aborting HHH, in a non-aborting simulator, it will halt!
The input to HHH specifies aborted recursive simulation.
Am Thu, 11 Sep 2025 10:43:55 -0500 schrieb olcott:
On 9/11/2025 2:50 AM, joes wrote:
Am Wed, 10 Sep 2025 19:52:20 -0500 schrieb olcott:
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
When nothing anywhere is changed besides the abort code is disabledWhen you disable the abort code, that changes the behavior of HHH. >>>>>>>and proves that this *would never stop running unless aborted*
criteria is met:
Is met for a different, new DD that is now obviously non-halting, and >>>>> unrelated to the halting DD that arises from HHH(DD) returning 0.
(Any Turing Machine that is non-halting never stops running unless
aborted; the altered DD now fits the description.)
and this single change causes DD to keep running then we know that DD
specifies non-halting behavior.
That is two changes:
Only one block of code in the u32 Decide_Halting_HH() function is
enabled/disabled by this #define ENABLE_ABORT_CODE 1
Yes, read on:
one in the simulator and one in the input,
because DD calls HHH. But when you run the original DD, which calls the
aborting HHH, in a non-aborting simulator, it will halt!
The input to HHH specifies aborted recursive simulation.
You also change this block in the input.
On 11/09/2025 01:58, olcott wrote:
On 9/10/2025 7:14 PM, Richard Heathfield wrote:
On 11/09/2025 01:06, olcott wrote:
On 9/10/2025 6:53 PM, Richard Heathfield wrote:
<snip>
So it is useless on many different levels$ ./plaindd
DD halted.
$
That cannot be generalized to a universal
halt decider so it is useless.
Correct on both counts. About time you got something right.
And yet, it halts.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
DD simulated by HHH1 reaches its final halt state.
DD simulated by HHH CANNOT POSSIBLY reach its final halt state.
You will have your ass handed to you when someone takes your own code
and demonstrates that the simulation of DD abandoned by HHH is actually
an instruction-for-instruction identical to the natively executed DD and similarly headed toward termination, if that abandoned simulation is
picked up and continued.
It will look better if you do it yourself. Then, rather than being taken
by surprise, you can take your time to straighten out your talking
points, and lick your tail smooth before arranging it neatly
between your legs, and take a few days to get on your stationary bike
and train you backwards pedaling technique.
One single independent variable with two values:
[abort] and [do not abort] is changed.
The effects of this single change are measured by
one single dependent variable with two values:
[stops running] and [never stops running].
On 9/10/2025 10:35 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 8:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 6:57 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:and proves that this
On 9/10/2025 6:31 PM, Richard Heathfield wrote:
The simulation is correct as I have proven
by disabling the abort code. Are you ONLY
a liar or can you tell the truth?
When you disable the abort code, that changes the behavior
of HHH.
*would never stop running unless aborted* criteria is met:
Is met for a different, new DD that is now obviously non-halting,
and unrelated to the halting DD that arises from HHH(DD) returning 0. >>>>>>
(Any Turing Machine that is non-halting never stops running
unless aborted; the altered DD now fits the description.)
It is a simple categorical analysis.
When nothing anywhere is changed besides the abort
code is disabled and this single change causes DD
to keep running then we know that DD specifies
non-halting behavior.
Any competent engineer knows that DD has been modified
to specify non-halting behavior.
*counter-factual*
It has always been the fact that DD calls HHH(DD)
in recursive simulation that has been the source
of the non-halting behavior.
Do you not agree that changing the definition of HHH
changes DD, since DD is built on HHH?
We have one independent variable with two values:
abort / do not abort
We have one corresponding dependent variable with two values:
stop running / never stop running
All of these rest about what you say about this only
serves to distract your attention away from the above
simple analysis.
(I mean regardless of your belief that recursive simulation
always brings in non-halting behavior.)
It is not a mere belief that infinite recursion is
non-terminating. It is not a mere belief that recursive
simulation is isomorphic to infinite recursion.
Even if you believe that DD is always non-halting due to recursive
termination, surely you at least have to recognize that you're
making a different DD when you tinker with HHH, no?
An irrelevant distraction.
On 11/09/2025 06:40, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
DD simulated by HHH1 reaches its final halt state.
DD simulated by HHH CANNOT POSSIBLY reach its final halt state.
You will have your ass handed to you when someone takes your own code
and demonstrates that the simulation of DD abandoned by HHH is actually
an instruction-for-instruction identical to the natively executed DD and
similarly headed toward termination, if that abandoned simulation is
picked up and continued.
It will look better if you do it yourself. Then, rather than being taken
by surprise, you can take your time to straighten out your talking
points, and lick your tail smooth before arranging it neatly
between your legs, and take a few days to get on your stationary bike
and train you backwards pedaling technique.
I'm afraid such demonstrations have no impact on PO whatsoever! You
could say he has had his ass handed to him, but he just carries on regardless.
There is always some nonsense sequence of illogical words
that he will come out with making him look a total idiot, but he doesn't mind. He even carries on posting claims which were totally debunked, as though the ass-handing never happened.
Well, perhaps that could be said to demonstrate to all and sundry that arguing with PO is quite pointless - but posters here don't seem to be bothered by the ass-handing either! As long as PO continues posting the same claims over and over, people here will keep responding the same objections, so PO is happy and nothing changes.
Example: I pointed out to PO that two emulations of (say) DD by
different emulating code will match instruction for instruction right up
to the point that an emulation is abandoned.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
One single independent variable with two values:
[abort] and [do not abort] is changed.
The effects of this single change are measured by
one single dependent variable with two values:
[stops running] and [never stops running].
You are flatly incorrect. At least two dependent variables change
when you alter the definition of HHH:
Independent: HHH(DD) fails to return HHH(DD) -> 0
Dependent 1: DD() simulation never stops DD simulation aborted
Dependent 2: DD() is non-terminating DD is terminating
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,070 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 161:05:16 |
| Calls: | 13,734 |
| Calls today: | 2 |
| Files: | 186,966 |
| D/L today: |
843 files (303M bytes) |
| Messages: | 2,418,725 |